«Плохие парни работают просто»: пентестеры разбирают реальные кейсы

[wrangler65]

В 2024 году мы — команда практического анализа защищенности «Инфосистемы Джет» — выполнили 130 проектов и выяснили, что в среднем достаточно 10 часов, чтобы вывести крупные суммы со счетов, остановить производство или слить критичную информацию. В работе мы используем сложные методы, но из-за низкой защищенности организаций часто хватает базовых техник

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

и общедоступного ПО. Наши наблюдения подтверждаются исследованиями кибератак

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

: в 83% случаев злоумышленники добивались успеха за счет «простых» методов — фишинг, эксплуатация уязвимостей по умолчанию или слабые пароли. State of art атаки с поиском 0-day — это скорее исключение. Обычно компании взламывают куда более прозаичными способами.

В этой статье мы разберем реальные кейсы из нашей практики, покажем, какие уязвимости не устранялись годами, и объясним, почему настройки по умолчанию и стандартные пароли — это хорошо для нас то, что делать не надо.

Отсутствие настройки групповых политик и небезопасное хранение паролей. Хищение денежных средств через «1С: Зарплата и управление персоналом»​

К нам обратилась микрофинансовая организация. Необходимо было проверить возможность хищения денежных средств со счетов этой организации. Работы проводились методом «черного ящика

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

», с моделированием «внешнего нарушителя».

Шаги​

1. Для начала мы просканировали беспроводной эфир и выбрали «жертвой» сеть заказчика с наибольшим числом клиентов. С помощью общедоступного программного обеспечения (ПО) Eaphammer создали поддельную точку доступа с таким же названием. В результате перехватили учетные данные сотрудника заказчика, включая хешированное значение пароля (T1016.002, T1557.002).
2. Далее мы восстановили пароль из хеша и смогли подключиться к сети заказчика с полученными учетными данными. Таким образом реализовали атаку «злой двойник
   
   

   Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

   
   
   » (T1110.002).
3. От имени скомпрометированного пользователя провели разведку ИТ-инфраструктуры заказчика: собрали информацию о домене, групповых политиках, сети и т.д. (T1615).
4. Создали доменную УЗ устройства. Из-за недостатков в настройке групповых политик каждая УЗ устройства имела привилегию GenericWrite и могла изменять DEFAULT DOMAIN POLICY (T1136.001).
5. Используя доступ к групповой политике DEFAULT DOMAIN POLICY, мы создали пользовательскую УЗ и добавили ее в локальную группу «Администраторы». Так получили административный доступ к контроллеру домена (T1484.001).
6. С помощью собранной на третьем шаге информации определили УЗ сотрудников из бухгалтерии, в том числе УЗ главного бухгалтера. Мы нашли его активную сессию на одном из компьютеров и удаленно подключились к нему в нерабочее время. В рабочих папках обнаружили текстовый файл с паролями для различных внутренних систем, в том числе пароль для 1С:ЗУП (T1087.002, T1021.004, T1552.001).
7. Далее выполнили аутентификацию под УЗ главного бухгалтера на сервере 1С:ЗУП. В итоге получили возможность осуществлять платежи (создавать начисления, платежные поручения, редактировать номера счетов зачисления и пр.) (T1078, T1657).

Затруднительным этапом был незаметный вывод денежных средств без прохождения внутренних согласований и проверок банков. Мы нашли четыре возможности это сделать:

• изменение номера счета зачисления существующего сотрудника;
• создание нового начисления существующему сотруднику;
• оформление переработки существующему сотруднику;
• создание платежного поручения созданному нами сотруднику.

Выводы​

Мы достигли поставленной цели и показали возможность хищения денежных средств. Однако реализация описанной атаки привела бы не только к потере денег, но и к утечке УЗ и персональных данных сотрудников.

Атака была бы невозможна, если бы заказчик:

• ввел дополнительную защиту Wi-Fi (настроил проверку подлинности RADIUS-сервера Wi-Fi на клиентских устройствах, реализовал аутентификацию клиентских устройств по сертификатам);
• безопасно настроил групповые политики домена;
• ограничил сетевые права доступа к финансовым системам;
• организовал защищенное хранение паролей.

Доступ к персональным данным сотрудников из внешней сети​

Следующая организация поставила цель скомпрометировать персональные данные, хранящиеся в ее системах. Работы проводились методом «черного ящика».

Шаги​

1. Мы собрали информацию о заказчике в открытых источниках и обнаружили веб-портал. Проанализировав утечки, нашли учетные данные сотрудника заказчика и с их помощью аутентифицировались на этом веб-портале. Тип утечки свидетельствовал о том, что у сотрудника на его личном или корпоративном компьютере, с которого совершался доступ к веб-порталу, был установлен стиллер
   
   

   Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

   
   
   (T1593.002, T1078.003).
2. Веб-портал оказался системой обучения сотрудников. На одной из страниц системы была возможность оставлять комментарии с прикрепленными файлами, при этом проверка этих файлов осуществлялась некорректно. В результате в качестве файла мы загрузили PHP-шелл и получили доступ к контейнеру Kubernetes (T1505.003).
3. В переменных окружения контейнера мы обнаружили информацию для подключения к базе данных MySQL (порт, логин и пароль). Для получения доступа к базе данных на странице веб-портала загрузили новый файл с кодом приложения Adminer для управления базами данных через браузер. Таким образом мы получили доступ к базе данных MySQL (T1613, T1552.007, T1105).
4. Как мы выяснили, база данных MySQL содержала незашифрованные персональные данные всех сотрудников заказчика. Мы достигли поставленной цели (T1530).

Выводы​

Полученный доступ позволил бы злоумышленнику развивать атаку внутри инфраструктуры без использования фишинга или привлечения внимания персонала. Мы передали данные о найденной уязвимости и предоставили рекомендации по ее устранению. Заказчик завел внутренний инцидент и исправил уязвимость.

Реализация атаки стала возможной из-за:

• наличия учетных данных сотрудника в открытых источниках утечек;
• наличия опции загрузки вредоносных файлов в открытом веб-портале;
• недостаточной защищенности контейнера Kubernetes и возможности исполнения системных команд;
• наличия в переменных окружения конфиденциальных данных для подключения к базе данных MySQL.

Удаление резервных копий. Доступ к изолированной сети и случайные находки​

Для следующего заказчика — строительной компании — нам предстояло выполнить проверку доступа к серверам резервного копирования, расположенным в изолированном сегменте сети с отдельным доменом Active Directory (далее — домен Б). Работы проводились методом «черного ящика», имитировался внешний посетитель, подключивший свой компьютер в информационную розетку на территории заказчика.

Шаги​

1. Мы сгенерировали список с адресами электронной почты сотрудников заказчика из сочетания популярных имен и наименования домена. Далее проверили наличие этих УЗ через внешний почтовый сервер и на существующие почтовые адреса выполнили фишинговую рассылку со ссылкой на фальшивую страницу, имитирующую единую форму авторизации заказчика. В результате в 10% из дошедших писем сотрудники перешли по ссылке, а в 7% — ввели свои учетные данные. Никто не сообщил об инциденте в службу поддержки (T1589.002, T1608.005, T1566.002, T1056.002).
2. С полученной УЗ мы подключились к информационной розетке в офисе заказчика и собрали информацию о пользователях, группах, привилегиях и используемом центре сертификации (ЦС). Анализ доступных шаблонов сертификатов показал уязвимость — любой доменный пользователь мог выпустить сертификат на имя администратора домена. Выпустив такой сертификат, мы получили права доменного администратора и скомпрометировали домен А (Т1615, Т1649).
3. Чтобы попасть из домена А в целевой домен среды резервного копирования Б, необходимо было найти пользователей, обладающих УЗ в обоих доменах. При анализе собранной информации мы нашли группу «отдел резервного копирования», в которую входили администраторы домена А (T1087.002).
4. Используя информацию о сессиях пользователей на устройствах, мы выявили рабочий компьютер одного из администраторов домена А. Чтобы обойти защиту антивирусного средства Kaspersky Security Center (KSC) на хосте администратора домена, мы сначала аутентифицировались в KSC и отключили защиту. После по RDP подключились на сам хост и расшифровали пароли, сохраненные в браузере Google Chrome (T1021.001, T1562.001, T1555.003).
5. Среди извлеченных оказались учетные данные к системе виртуализации изолированного сегмента. Так мы получили полный контроль над виртуальными машинами домена Б, включая его контроллер домена в изолированном сегменте (T1078, Т1565.001).

В ходе наблюдения за администратором домена А мы поймали момент с открытой базой паролей в KeePass

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

на его рабочем компьютере. В результате мы получили доступ к множеству других внутренних информационных систем с правами администратора, в том числе к Confluence, где хранились схемы и документация по резервному копированию (T1555.005, T1213.002).

Выводы​

Мы показали возможность привилегированного доступа к серверам резервного копирования. Полученный доступ открыл возможность менять настройки резервного копирования или удалять важные данные. Причем изолированный сегмент не стал преградой.

Реализация атаки стала возможной из-за:

• низкой осведомленности сотрудников о правилах ИБ;
• использования уязвимых шаблонов сертификатов;
• небезопасных настроек политик в антивирусном средстве KSC;
• хранения пользователями своих учетных данных в браузере.

Компрометация платежной системы. Достижение цели через смежные системы​

Пентесты могут быть ориентированы не только на всю ИТ-инфраструктуру, но и на конкретную систему. Так, для одного из банков было необходимо выявить уязвимости в платежной системе, связанной с рядом других систем. Пентест проводился с моделированием потенциального нарушителя «гость», при котором заказчик предоставил доступ на территорию организации с возможностью подключения к сети.

Шаги​

1. После подключения к сети мы получили сетевые параметры УЗ пользователя домена. Первичная разведка не выявила уязвимости целевой системы Ц, но дала информацию о ее связях со смежными. Поэтому было предложено расширить анализ и включить в работы найденные смежные системы (T1078.001, T1016.001).
2. Для одной из смежных систем С для аутентификации использовалась система WSO2 Identity Server (WSO2 IS). Мы просканировали ее и обнаружили уязвимость в устаревшей версии ПО WSO2 – CVE-2022-29464. Эта уязвимость позволяет удаленно выполнить код через загрузку файла
   
   

   Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

   
   
   . В итоге эксплуатации уязвимости с помощью вредоносного скрипта Java Server Pages Shell был получен доступ на сервер WSO2 IS (T1595.002, T1190, T1059.004).
3. Далее с использованием доступа к серверу был получен административный доступ к веб-панели управления WSO2 IS. С помощью полученного доступа cоздали дублирующую УЗ администратора целевой информационной системы Ц (T1136.001).
4. С помощью этой УЗ удалось пройти аутентификацию и получить доступ с правами администратора в целевой системе Ц (Т1078.004).

Выводы​

Полностью изолированные системы встречаются редко, каждая система внутри корпоративной сети так или иначе взаимодействует с другими. Поэтому компрометация смежных систем может привести к взлому ключевых компонентов. Дополнительно из системы С мы получили больше конфиденциальных данных, чем могли бы получить из системы Ц.

Атака стала возможной благодаря:

• раскрытию технической информации о связях систем;
• отсутствию обновлений системы WSO2 IS;
• использованию одинаковых учетных данных в смежной и целевой системах.

Общие рекомендации​

Несмотря на улучшение средств защиты информации и общее развитие информационной безопасности, пентесты показывают, что популярные техники и общедоступное ПО остаются эффективными для достижения целей злоумышленников.

Составили топ частых недостатков за 2024 год, которые встречали на проектах.

Отсутствие обновлений и как следствие — устаревшие протоколы:

• Net-NTLMv1, LLMNR, NetBIOS, mDNS (множественные уязвимости);
• MS-EFSRPC (уязвимость PetitPotam);
• SMBv1 (уязвимость Eternal Blue CVE-2017-0144);
• CIFS (уязвимость NULL Session CVE-1999-0519);
• незащищенный RDP (уязвимость Bluekeep CVE-2019-0708);
• отсутствие контроля использования IPv6 (уязвимость CVE-2011-1652).

Недостаточная защита аутентификации технических и пользовательских УЗ:

• использование словарных, слабых или одинаковых паролей;
• отсутствие защиты от перебора учетных данных;
• применение учетных данных по умолчанию

Ошибки в настройке Active Directory и сертификатов:

• доступность административных интерфейсов из сети Интернет;
• возможность подмены SAM-Account-Name и эскалации привилегий (CVE-2021-42278 и CVE-2021-42287);
• уязвимости центра сертификации (возможность реализации атак ESC1, ESC2, ESC8 и др.);
• отсутствие ограничений на добавление новых устройств в домен.

Раскрытие информации и недостатки веб-безопасности:

• перечисление пользователей и внутренних IP-адресов, облегчающее разведку;
• наличие уязвимостей в веб-приложениях (XSS, SSRF, устаревшие версии Apache);
• отсутствие аутентификации в API (Swagger, Redis) и IoT-устройствах (камеры Hikvision, принтеры Kyocera).

Чтобы обнаружить и устранить перечисленные уязвимости, необходимо проводить регулярные аудиты, сканирования и пентесты, ведь основной риск для компаний не в нехватке технологий, а в недоработках процессов и недостаточном контроле.

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.