В прошлый раз мы рассказывали о том, как взлом сайта может привести к компрометации корпоративной переписки через контроль содержимого трафика.
В этой статье будет намного более захватывающе и интереснее. Прямо как в детективном романе. Мы расскажем, как злоумышленник с навыками Конкурентной Разведки (OSINT) может попасть в локальную сеть.
Этап первый. Разведка.
Начиналось все как обычно. Мы проводили проверку внешнего периметра сети заказчика на возможность проникновения. Кто же знал, что самое интересное будет уже на самом первом этапе тестирования - Разведке.
Традиционно, target - условное обозначение нашего заказчика. Приступаем к сбору информации. Что у нас имеется? Юридическое лицо (Назовем ОАО «Target») и сайт - target.ru.
Очень часто крупные и не очень предприятия берут на практику студентов, те в свою очередь пишут отчеты. Если практика преддипломная - пишут дипломный проект на основе полученного опыта. Вот и в данном случае поиск по юридическому лицу в поисковике вывел нас на дипломный проект 2010 года.
Изучив его дипломный проект мы увидели, что ОАО «Target» ранее принадлежало доменное имя «trgt.ru». Начали собирать информацию о домене trgt.ru и увидели, что домен был снят с регистрации год назад.
Часто имя домена AD внутри компании совпадает с внешним доменным именем почты или сайта. Вы могли убедиться в этом в предыдущей статье. Поскольку домен trgt.ru был зарегистрирован раньше, чем target.ru - было предположено, что у Заказчика в AD использовалось, а, возможно, сейчас используется, доменное имя trgt.ru.
И... Бинго. Мы без проблем зарегистрировали домен trgt.ru и, настроив веб сеПеренорвер на нашей VDS, начали ожидать поступающих запросов.
Этап Второй. Просмотр логов и установка Responder
Клиенты таргета не заставили себя долго ждать. Буквально через 5 минут посыпались логи с запросами вида: /wpad.dat. Напомним, что wpad.dat это файл для получения конфига для прокси.
Разворачиваем Responder на VDS. Инструмент для пентеста виндовой локалки Responder имеет модуль для работы с протоколом WPAD (параметр -w).
После запуска ждем некоторое время, пока «наши» клиенты начнут получать конфиги wpad. При обращении за wpad.dat, виндовый клиент предоставляет для аутентификации свой NTLMv2 хеш, который включает в себя имя пользователя и хешированый пароль. Результат не заставил себя долго ждать. Мы получили логин внутреннего пользователя AD и его NTLMv2 хеш. Далее его можно попытаться сбрутить.
Этап четвертый. Брутфорс полученных хешей и подключение к VPN
Можно использовать любой инструмент для брута. Мы использовали john.
Получен пароль пользователя - 123 (о, да, и не говорите). Далее удалось захватить еще несколько аккаунтов. Пароли не сильно отличались стойкостью. Ниже еще пример работы Responder.
На одном из субдоменов target.ru находился вход в Cisco ASA VPN. Причем вход можно было осуществить через AD (обычная практика).
Попробовали использовать полученные креды (несколько штук) и они успешно подошли. Нам удалось получить доступ до внутренней сети предприятия.
Также можно подцепиться через клиент Cisco Any Connect.
Дальше уже можно развлекаться с внутренней сеткой :)
Конечно, если бы на VPN шлюзе стояла двухфакторка, то такого вектора можно было избежать.
Итоги
C первого взгляда невероятный, но такой критичный мисконфиг, можно было бы с легкостью предотвратить. Shadow IT послужило первоочередной причиной. Конечно, это произошло из-за отсутствия регламента по выводу из эксплуатации доменного имени организации.
Второй фактор - это слабая парольная политика или, скорее, её полное отсутствие. Слабые пароли достаточно легко поддаются полному перебору или перебору по словарю.
Третий фактор - отсутствие мультифакторной аутентификации. Использование лишь одного фактора небезопасно и совсем не подходит для таких критичных узлов, как VPN. С внедрением второго фактора можно значительно уменьшить существующие риски с точки зрения внешнего нарушителя.
