Привет, друзья! В современном мире технологий и сложных систем даже мельчайшая ошибка может стать зерном, из которого вырастет настоящая буря. Самой критической брешью в безопасности, как нередко это бывает, оказывается человеческий фактор. И даже наличие передовых средств защиты, и армии студентов, мониторящих вашу сеть 24/7, не является гарантией того, что выстроенная вами оборона нерушима. Ведь как часто мы пренебрегаем незначительными деталями, не задумываясь о потенциальных катастрофах. И вот ты уже сидишь с бутылкой крепкого напитка, с проплешиной от вырванных волос и бормочешь себе под нос: “Да как так-то”
Поделюсь сегодня с вами кусочком работы по одному из любопытных кейсов. Как вы наверное уже догадались на повестке дня рубрика “Нам было лень — мы создавали шедевры”.
Договора были подписаны. Адреса согласованы. И да начнется веселье.
В процессе тестирования мной была обнаружена форма входа в сетевой шлюз безопасности Fortigate. После непродолжительной попытки подбора пароля, стало понятно, что неверные попытки ввода блокируются.
Однако, немного поигравшись с запросами я обнаружил возможность обойти систему блокировки путем установки времени между запросами в 60 секунд. Отмечу, что изменение временных параметров представляет собой довольно распространенную практику, помогающую успешно избежать блокировки.
Были подготовлены списки с паролями и логинами для проведения брутфорс-атаки. Для подбора логинов я использовал кастомный список, состоящий из наиболее популярных фамилий и инициалов к ним. А для подбора паролей — популярные списки, такие как Rockyou, Xato, а также кастомный список, состоящий из 1000 русских слов на латинице с различными модификациями.
PS: В конце концов был найден доменный пользователь. Только тссссс, я вам ничего не говорил.
Ну а пока я сам об этом не знаю, и продолжаю свое исследование.
Мною был найден сервер, на котором располагался apache. В процессе перебора директорий мое внимание привлекла директория «test».
Именно в таких забытых директориях нередко можно обнаружить что-то интересное. Этот раз не стал исключением. Передо мной появился логотип “1С: Предприятие”. Приятным сюрпризом для меня стало не только то, что по данному url находилась 1С, но и то, что сработал автоматический вход.
Путешествия по вкладкам, я обнаружил раздел “ЭДО”. В нем были найдены заполненные поля логина и пароля к сервисам “СБИС” и “ДИАДОК”. Однако через web-интерфейс доступ к паролям получить не удалось. Здесь магия кроется внутри. Если сбросить подключение через web-интерфейс и перехватить запрос с помощью burp, то через api можно увидеть логин и пароль в открытом виде.
А далее дело за малым. Заходим в сервисы под найденными учетными записями и делаем контент для отчета. Стоит понимать, что при реальной атаке злоумышленника в этот момент произошла бы утечка персональных данных и иной конфиденциальной информации, что могло бы повлечь за собой большие финансовые и репутационные риски.
На этом тестирование могло бы быть закончено. Однако, мы профессионалы, поэтому помним, что если в 1С включено интерактивное открытие внешних отчетов и обработок, то есть возможность подгрузить сценарий в формате epf. Такой сценарий позволит получить консоль запросов, через которую можно выполнить произвольный код в операционной системе сервера. Такой epf-файлик можно найти на просторах интернета или написать самому. Ну а POC для выполнения CMDI через консоль запросов будет выглядеть следующим образом:
Прокидываем shell и попадаем внутрь. Здесь я как раз узнаю о том, что в результате брутфорс-атаки на Fortigate был найден доменный пользователь. Это значит, что на данный момент у нас есть 2 точки входа в корпоративную сеть заказчика.
Итак, давайте теперь отойдем немного подальше и взглянем на всю картину целиком. Проанализируем, что же было не так у заказчика, и что привело его к таким печальным последствиям.
Первое, о чем здесь можно говорить — это то, что панель управления сетевого шлюза безопасности Fortigate, уязвимая к брутфорс-атакам, находится в публичном доступе. Я бы рекомендовал убрать ее из публичного доступа или предоставлять доступ к ней только с определенных IP-адресов.
Вторая проблема — слабая парольная политика или ее полное отсутствие — то, что уже стало классикой в своем роде, и то с чем специалист по тестированию на проникновение сталкивается в девяносто процентов случаев. Здесь необходимо внедрить строгую парольную политику, которая включает в себя минимальную длину пароля от 10 символов, символы в нижнем и верхнем регистре, цифры и спец символы.
Следующее, на что я обратил бы ваше внимание — это то, что dev- среда находится на том же сервере, что и prod. Их крайне важно разграничивать. Также необходимо будет убрать 1С из публичного доступа. Я бы рекомендовал предоставлять доступ только через vpn-канал. Важно следить за тем, чтобы в настройках 1С был выключен автоматический вход в систему. В нашем случае также необходимо будет проверить всех пользователей, которые зарегистрированы в 1С и провести большую работу внутри сети для того, чтобы убедиться, что никто не проник в корпоративную сеть.
Помните, друзья, что при проектировании своих информационных систем необходимо учитывать любые детали, даже если вам они кажутся незначительными. Крайне важно иметь четкий и подробный план действий по организации информационной безопасности компании. Это поможет вам увидеть картину целиком, оценить фронт работ и понять, что было сделано, а что еще только предстоит. Будьте бдительны и внимательны к деталям. А я продолжу оставаться на страже вашей кибер-безопасности!