1. Введение
Во время очередного пентест-проекта на внешнем периметре Заказчика была обнаружена широко известная в узких кругах пентестеров инфраструктурная служба Outlook Web Access (OWA). OWA примечательна тем, что это WEB-интерфейс почтового сервера Microsoft Exchange. Скорее всего, вы слышали, как минимум о нескольких громких уязвимостях OWA. С 2020 года существует подробный ресерч от коллег из PT SWARM на тему безопасности MS Exchange WEB-интерфейсов, а новые атаки появляются с завидной частотой. В одном из подкастов я слышал, что в OWA имеется огромный архитектурный баг, который является драйвером целого семейства подобных уязвимостей.
Атак достаточно, но есть еще и очень приятная “фича” в OWA – перечисление существующих пользователей в зависимости от времени ответов сервера. После формирования списка однозначно существующих учетных записей можно провести атаку типа Password Spray (англ. Распыление паролей) и с небольшим шансом подобрать пароль типа «P@ssw0rd!» среди пары сотен пользователей.
Многим пентестерам это известно, но мне удалось найти ультимативный способ проведения этой атаки за счет избыточности русских фамилий (sic!). Сперва рассмотрим проблематику.
2. Проблематика
Техника перечисления существующих пользователей по ответам сервера стара как мир. В рекомендациях по противодействию (ссылка) от OWASP четко и конкретно написано: “Гарантировать, чтобы приложение возвращало согласованные общие (обезличенные) сообщения об ошибке в ответ на введение недопустимого имени учетной записи, пароля или других учетных данных в процессе входа в систему”.
Но у Microsoft своё видение. Как же в общем виде выглядит процесс проведения атаки по перечислению существующих пользователей? Достаточно тривиально. Если исследуемое приложение имеет указанный выше недостаток, то достаточно загрузить в словарь стандартные имена пользователей (admin, user, buhgalter, moderator, и т.п.) и провести атаку перебора, фильтруя ответы по ключевым словам.
В частном же случае управление доступом в OWA организуется централизованно через службу активного каталога (Active Directory) при помощи LDAP (Lightweight Directory Access Protocol). При использовании службы каталогов каждому сотруднику организации создается учетная запись в домене Active Directory, которая может использоваться для доступа к файловым хранилищам, удаленному подключению к VPN, корпоративному прокси-серверу, внутренним сервисам, беспроводной сети и, конечно, корпоративной почте. Аналогичная система управления доступом работает во внутреннем периметре, но уже при дополнительной поддержке протокола Kerberos.
Удобно, но есть свои нюансы. Поскольку имя корпоративной почты привязано к пользователю в домене Active Directory, то задача по перечислению учетных записей через интерфейс OWA сводится к поиску существующих почтовых ящиков в домене Заказчика. OSINT TIME!
Хорошо, как проводить базовый OSINT тоже понятно. Используем Google Dorks, рыскаем по соцсетям, пытаемся найти что-то в утечках, тендерах, используем автоматизированные инструменты, государственные сервисы. В результате получаем список из N почтовых адресов. Можем его обогатить существующими словарями стандартных имен учетных записей (как упоминали выше). Часть из N почтовых адресов могут быть не привязаны к домену Active Directory - как итог, список существующих учетных записей может получиться достаточно скудным.
Как же мы можем увеличить число найденных учетных записей и усилить наши шансы на подбор пароля в результате Password Spray атаки? Мне в голову пришло изящное решение.
3. Решение проблемы
Как выглядит ваша корпоративная почта или корпоративный аккаунт в Active Directory?
Ivanov@contoso.com
IvanovA@contoso.com
Ivanov.a@contoros.com
IvanovAB@contoso.com
IvanovIvan@contoso.com
IvanovIvanIvanovich@contoso.com
Если вариант из первой тройки, то у меня для вас плохие новости. Именно первый я и увидел на проекте в ходе проведения разведки, а второй и третий часто встречались на других. Что же здесь не так, спросите вы? А трюк в том, чтобы найти словарик русских фамилий и использовать их для перечисления почтовых аккаунтов. Количество фамилий ограничено статистически и их явно меньше, чем всех комбинаций из латинских букв. Изначальный словарик я взял отсюда.
А дальше дело техники и чудес скриптинга (sed/python). Можно добавлять буквы алфавита к фамилиям и каждый раз получать ультимативный словарь.
4. Немного статистики и примеров
Конечно, можно проводить полный перебор имен, но эффективнее будет взглянуть на таблицу распределения частоты употребления и прогонять эти буквы в первые очередь. Выглядит примерно так:
Получается так, что буквы «О», «Е», «А», «И» наиболее часто употребляются и с ними можно начать перечисление имен и фамилий по словарю.
5. Демонстрация работы
На скриншоте пример работы инструмента MailSniper для перечисления почт через OWA. Найдены 4 логина, 3 из них состоят просто из фамилии. Дальнейшая работа заключалась в переборе почт по словарям с именами. Всего удалось собрать около 40 почт.
Также приведу пример перечисления пользователей при внутреннем тестировании. Здесь при помощи утилиты kerbrute были получены 252 существующих логина по аналогичной схеме со словарями имен и фамилий. В сумме же удалось перечислить около 450 логинов.
И, кстати, аналогичным образом можно провести атаку типа ASREP-Roasting. Если звезды сойдутся и у перечисленной ранее учетной записи будет отключена предварительная аутентификация Kerberos, то
в ответ присылается KRB_AS_REP сообщение, содержащее сессионный ключ, зашифрованный с использованием секрета указанного пользователя. Таким образом можно попытаться подобрать пароль оффлайн по словарю.
Более подробно про атаки на Kerberos можно почитать в этом замечательном цикле статей.
Итак, получили списки существующих логинов на внешнем или внутреннем периметре. Теперь можем развернуть наш комбайн по распылению паролей (конечно, учитываем парольную политику и пробуем одну попытку в некоторое время). Можно пробовать такие пароли:
Qq123456, Aa123456, Aa123456!@#;
P@ssw0rd;
Summer2023.
Вы можете заявить, мол, это же простецкие пароли и в большинстве случаев никто их не использует и будете совершенно правы. Но здесь работают законы теории вероятности – чем больше попыток (почтовых адресов), тем выше суммарная вероятность подобрать даже такой простой пароль. Хочется вспомнить теорию надежности систем: «Надежность системы всегда будет меньше надежности наименее надежного элемента, включенного последовательно». Это правило прекрасно работает и в мире информационной безопасности. Именно так, скомпрометировав хотя бы одну доменную учетную запись, злоумышленник значительно расширяет свои возможности. Исходя из практики, для успешного распыления паролей стоит собрать хотя бы 50+ учетных записей, но чем больше, тем выше вероятность.
Ниже скриншоты с демонстрацией распыления паролей с помощью инструмента NetExec:
С помощью утилиты ruler подобраны пароли к десятку доменных записей через интерфейс OWA.
6. Заключение
Приведенная в этой небольшой статье техника работает безотказно. Наибольший эффект виден во внутренней сети за счет скорости работы протокола Kerberos и хорошей связности. Прекрасно работает и на внешнем периметре, где процесс авторизации подвязан к службе активного каталога через LDAP (например, OWA).
Методология перечисления пользователей известна, но с применением словарей с именами и фамилиями эффективность значительно возрастает. Повышается шанс пробиться с внешнего периметра или скомпрометировать доменную учетную запись исследуемого внутри периметра.
Я сделал форк репозитория с фамилиями и немного обогатил существующий список. Дальнейшая работа будет заключаться в увеличении словаря фамилий.
Подписывайтесь на телеграм-канал кооператива RADCOP. Мы публикуем множество интересных видео и рассказываем о том, как развивается наш ИБ-стартап:
t.me/radcop_online
А также мой личный блог PathSecure:
t.me/pathsecure
