Эта статья написана по мотивам очень удачного пентеста, который пару лет назад провели специалисты Group-IB: случилась история, претендующая на экранизацию в Болливуде. Сейчас, наверное, последует реакция читателя: «О, очередная пиар-статья, опять эти рисуются, какие они хорошие, еще не забудьте купить пентест». Ну с одной стороны, так и есть. Однако есть еще ряд мотивов, почему появилась эта статья. Хотелось показать, чем именно занимаются пентестеры, насколько эта работа может быть интересной и нетривиальной, какие забавные обстоятельства могут складываться на проектах и самое главное — показать живой материал с реальными примерами.
Чтобы восстановить баланс скромности в мире, через некоторое время напишем про пентест, который не пошел. Покажем, как хорошо поставленные процессы у компании могут защитить от целого спектра атак, даже хорошо подготовленных, просто потому что эти процессы есть и реально работают.
У заказчика из этой статьи тоже все в целом было отлично, по крайней мере лучше, чем у 95% рынка в РФ по нашим ощущениям, но был ряд мелких нюансов, которые сложились в длинную цепочку событий, что и привело сначала к длинному отчету по работам, а потом к этой статье.
Итак, запасаемся попкорном, и добро пожаловать в детектив. Слово — Павлу Супрунюку, техническому руководителю направления “Аудит и Консалтинг” Group-IB.
Часть 1. Почкин доктор
2018 год. Есть заказчик — высокотехнологичная ИТ-компания, сама обслуживает множество клиентов. Хочет получить ответ на вопрос: можно ли без каких-либо изначальных знаний и доступов, работая через интернет, получить права администратора домена Active Directory? Никакая социальная инженерия не интересует (эх, а зря), мешать работам специально не собираются, но могут случайно — перезалить странно работающий сервер, например. Дополнительная задача — выявить как можно больше других векторов атак в отношении внешнего периметра. Компания регулярно проводит подобные тестирования, и вот подошел срок нового теста. Условия почти типичные, адекватные, понятные. Приступаем.
Имеется название заказчика — пусть будет «Company», с основным сайтом www.company.ru. Конечно, называется заказчик по-другому, но в данной статье все будет обезличено.
Провожу сетевую разведку — выясняю, какие адреса и домены числятся за заказчиком, рисую схему сети, как распределяются сервисы по этим адресам. Получаю результат: более 4000 живых IP-адресов. Просматриваю домены в этих сетях: к счастью, подавляющее большинство — сети, предназначенные для клиентов заказчика, и они нас формально не интересуют. Заказчик считает так же.
Остается одна сеть на 256 адресов, для которой к этому моменту уже имеется понимание распределения доменов и поддоменов по IP-адресам, есть информация про просканированным портам, значит — можно глазами смотреть сервисы на предмет интересных. Параллельно запускаются всевозможные сканеры по доступным IP-адресам и отдельно — по веб-сайтам.
Сервисов находится очень много. Обычно это радость для пентестера и предвкушение быстрой победы, так как чем больше сервисов, тем больше поле для атаки и тем проще найти артефакт. Беглый просмотр веб-сайтов показал, что большинство из них — это веб-интерфейсы известных продуктов крупных мировых компаний, которые всем видом говорят, что они вам не рады. Просят логин-пароль, с порога трясут полем для ввода второго фактора, просят клиентский сертификат TLS или посылают подальше в Microsoft ADFS. Некоторые просто недоступны из интернета. К некоторым явно нужно иметь специальный платный клиент за три зарплаты либо знать точный URL на вход. Опустим еще неделю постепенного приунывания в процессе попыток «пробить» софт по версиям на предмет известных уязвимостей, поиска скрытого контента в веб-путях и утекших учеток со сторонних сервисов типа LinkedIn, попыток подбора паролей по ним, а также раскопок уязвимостей в самописанных веб-сайтах — кстати, по статистике это самый перспективный вектор внешней атаки на сегодняшний день. Сразу отмечу то киношное ружье, которое впоследствии выстрелило.
Итак, нашлось два сайта, выбивающиеся из сотни сервисов. В этих сайтах было общее: если не заниматься дотошной сетевой разведкой по доменам, а «в лоб» искать открытые порты или травить сканер уязвимостей по известному диапазону IP, то эти сайты уйдут от проверки, их просто не будет видно без знания DNS-имени. Возможно, их так и пропустили ранее, по крайней мере, и наши автоматические инструменты проблем в них не нашли, даже если их натравливали прямо на ресурс.
Кстати, о том, что в целом нашли ранее запущенные сканеры. Напомню: для некоторых людей «пентест» равносильно «автоматизированному сканированию». А сканеры на этом проекте ничего не сказали. Ну, максимум показали Medium-уязвимости (3 из 5 по уровню опасности): на каком-то сервисе плохой сертификат TLS или устаревшие алгоритмы шифрования, а на большинстве сайтов Clickjacking. Но на этом к цели не приедешь. Возможно, сканеры были бы тут более полезны, но напомню: заказчик сам в состоянии закупить такие программы и проверить ими себя, и, судя по унылым результатам, уже проверил.
Вернемся к «аномальным» сайтам. Первый — что-то типа местной Wiki по нестандартному адресу, но в этой статье пусть будет wiki.company[.]ru. Она также сходу просила логин и пароль, но уже через NTLM в браузере. Для пользователя такое выглядит как аскетичное окно с просьбой ввести логин и пароль. И это плохая практика.
Небольшая ремарочка. NTLM в веб-сайтах на периметре плоха по ряду причин. Первая причина — раскрывается имя домена Active Directory. В нашем примере оно тоже оказалось company.ru, как и «внешнее» DNS-имя. Зная это, можно качественно подготовить что-нибудь вредоносное, чтобы оно исполнилось только на доменной машине организации, а не в какой-нибудь песочнице. Второе — аутентификация идет напрямую через контроллер домена по NTLM (сюрприз, да?), со всеми особенностями политик «внутренней» сети, включая блокировки учеток от превышения числа попыток ввода пароля. Если злоумышленник узнает логины, он будет перебирать к ним пароли. Если настроена блокировка учеток от неправильного ввода паролей — она сработает, и учетка будет заблокирована. Третье — к такой аутентификации невозможно добавить второй фактор. Если кто из читателей все же знает как — сообщите, пожалуйста, реально интересно. Четвертое — уязвимость к pass-the-hash-атакам. ADFS придумали в том числе и для защиты от вот этого всего.
Есть одно нехорошее свойство у продуктов Microsoft: даже если вы специально не публиковали такой NTLM, он окажется в установке по умолчанию в OWA и Lync, как минимум.
Кстати, автор этой статьи однажды таким же способом случайно заблокировал примерно 1000 учеток работников одного крупного банка буквально за один час и имел потом несколько бледный вид. ИТ-службы банка тоже были бледными, но все закончилось хорошо и адекватно, нас даже похвалили, что мы первыми нашли эту проблему и спровоцировали быстрое и решительное исправление.
Второй сайт имел адрес «явно-какая-то-фамилия.company.ru». Нашелся через Google, примерно так на 10-й странице. Дизайн начала-середины двухтысячных, и с главной страницы смотрел солидный человек, примерно вот так:
Тут взял кадр из «Собачьего сердца», но поверьте, там было отдаленно-похоже, даже цветовое оформление в схожих тонах. Пусть сайт зовется preobrazhensky.company.ru.
Это был персональный сайт… уролога. Стало интересно, что делает сайт уролога на поддомене высокотехнологичной компании. Беглое копание в Google показало, что этот доктор был соучредителем одного из юридических лиц нашего заказчика и даже внес около 1000 рублей уставного капитала. Вероятно, сайт был создан много лет назад, а серверные ресурсы заказчика были использованы как . Сайт давно потерял актуальность, но зачем-то был оставлен работающим на долгое время.
С точки зрения уязвимостей сам веб-сайт был безопасен. Забегая вперед, скажу, что он представлял из себя набор статики — простые html-страницы со вставками иллюстраций в виде почек и мочевых пузырей. «Ломать» такой сайт бесполезно.
А вот веб-сервер под ним был более интересным. Судя по заголовку HTTP Server, там был IIS 6.0, а значит, применялся Windows 2003 как операционная система. Сканер ранее выявил, что этот конкретный веб-сайт уролога, в отличие от других виртуальных хостов на этом же веб-сервере, отвечал на команду PROPFIND, то есть там работал WebDAV. Кстати, сканер выдал данную информацию с пометкой Info (на языке отчетов сканеров это низшая опасность) — такие вещи обычно просто пропускаются. В сочетании это давало интересный эффект, который удалось выявить только после очередного копания в Google: редкая уязвимость переполнения буфера, связанная с набором Shadow Brokers, а именно CVE-2017-7269, которая уже имела готовый эксплоит. Иначе говоря, будет беда, если у вас Windows 2003 и на IIS запущен WebDAV. Хотя работающий в продакшене Windows 2003 в 2018 году — это уже сама по себе беда.
Эксплойт оказался в Metasploit и тут же был опробован с нагрузкой, которая посылала DNS-запрос на подконтрольный сервис — традиционно используется Burp Collaborator для отлова DNS-запросов. К удивлению, сработало с первого раза: был получен отстук в DNS. Далее была попытка создать бекконнект через 80 порт (то есть сетевое соединение от сервера к атакующему, с доступом к cmd.exe на хосте-жертве), но тут случилось фиаско. Соединение не пришло, а после третьей попытки эксплуатации сайт вместе со всеми занимательными картинками пропал насовсем.
Обычно после этого следует письмо в стиле «заказчик, проснись, мы все уронили». Но нам ответили, что сайт никакого отношения к бизнес-процессам не имеет и работает там вообще непонятно зачем, как и весь сервер, и что можно использовать этот ресурс как нам угодно.
Примерно через сутки сайт внезапно заработал сам. Соорудив стенд из WebDAV на IIS 6.0, я нашел, что по умолчанию стоит настройка на перезапуск рабочих процессов IIS каждые 30 часов. То есть при выходе управления из шелл-кода завершался рабочий процесс IIS, затем он пару раз перезапускался сам и далее уходил отдыхать на 30 часов.
Так как первый раз бекконект на tcp не удался, я списал эту проблему на закрытый порт. То есть предположил наличие некоторого межсетевого экрана, который не пропускал исходящие соединения наружу. Начал запускать шелл-коды, которые перебирают множество tcp- и udp-портов, эффекта не было. Не работали нагрузки обратного соединения через http(s) из Metasploit — meterpreter/reverse_http(s). Внезапно соединение на тот же 80 порт установилось, но тут же оборвалось. Списал это на действие пока еще воображаемой IPS, которой не нравился трафик meterpreter. В свете того, что соединение чистого tcp на 80 порт не прошло, а http — прошло, заключил, в системе была как-то настроена http-прокси.
Пробовал даже meterpreter через DNS (спасибо d00kie за труды, спасло много проектов), вспоминая самый первый успех, но он не отработал даже на стенде — шелл-код был слишком объемный для этой уязвимости.
В реальности это выглядело так: 3-4 попытки атак в течение 5 минут, затем ожидание на 30 часов. И так три недели подряд. Я даже заводил напоминание, чтобы не терять время. Дополнительно наблюдалась разница в поведении тестовой и боевой сред: для этой уязвимости было два похожих эксплойта, один из состава Metasploit, второй с просторов интернета, переделанный от версии Shadow Brokers. Так вот, на боевом отрабатывал только Metasploit, на стенде — только второй, что еще больше усложняло отладку и ломало .
В конце концов эффективным себя показал шелл-код, который качал с заданного сервера по http exe-файл и запускал его на целевой системе. Шелл-код был достаточно маленький, чтобы пролезть по размеру, ну и он хотя бы работал. Раз трафик TCP серверу вообще не нравился и http(s) инспектировался на предмет наличия meterpreter, я решил, что наиболее быстрый способ — скачать через этот шелл-код exe-файл, который содержал DNS-meterpreter.
Тут опять возникла проблема: при скачивании exe-файла и, как показали попытки, неважно какого, скачивание обрывалось. Опять какому-то устройству защиты между моим сервером и урологом не нравился трафик http с exe внутри. «Быстрым» решением показалось изменить шелл-код так, чтобы он обфусцировал трафик http налету, чтобы вместо exe передавались абстрактные двоичные данные. Наконец-то атака прошла успешно, через тонкий DNS-канал поступило управление:
Сразу выяснилось, что у меня самые простые права рабочего процесса IIS, которые позволяют делать ничего. Вот так это выглядело на консоли Metasploit:
Всякие пентест-методологии настоятельно говорят о том, что нужно повышать права при получении доступа. Обычно я это не делаю локально, так как самый первый доступ рассматривается просто как точка сетевого входа, а скомпрометировать другую машину в этой же сети обычно проще и быстрее, чем повышать привилегии на имеющемся хосте. Но здесь не тот случай, так как канал DNS очень узкий и он не даст разгуляться трафику.
Предполагая, что этот сервер с Windows 2003 не ремонтировали от знаменитой уязвимости MS17-010, туннелирую трафик на порт 445/TCP через DNS-туннель meterpreter на localhost (да, так тоже можно) и пытаюсь запустить через уязвимость ранее закаченный exe. Атака срабатывает, мне приходит второе соединение, но уже с правами SYSTEM.
Интересно то, что сервер все же пытались защитить от MS17-010 — у него были отключены уязвимые сетевые службы на внешнем интерфейсе. Это действительно защищает от атак через сеть, но атака «изнутри» на localhost сработала, так как нельзя просто взять и быстро выключить SMB на localhost.
Далее выясняются новые интересные детали:
- Имея права SYSTEM, можно без проблем установить бекконнект через TCP. Очевидно, запрет на прямой TCP — исключительно проблема ограниченного пользователя IIS. Спойлер: трафик пользователя IIS как-то был завернут в локальный ISA Proxy в обе стороны. Как именно это работает, не воспроизводил.
- Я в некой «DMZ» (и это не домен Active Directory, а WORKGROUP) — звучит логично. Но вместо ожидаемого частного («серого») IP-адреса у меня вполне себе «белый», точно такой же, что я атаковал ранее. Значит, компания настолько старая для мира адресации IPv4, что может позволить себе держать зону DMZ на 128 «белых» адресов без NAT по схеме, как рисовали в пособиях по Cisco образца 2005 года.
Так как сервер старый, гарантированно заработал Mimikatz прямо из памяти:
Получаю пароль локального администратора, туннелирую трафик RDP через TCP и захожу в уютный рабочий стол. Так как с сервером можно было делать все, что угодно, — удаляю антивирус, нахожу, что сервер доступен из интернета только по портам TCP 80 и 443, причем 443 не был занят. Поднимаю на 443 сервер OpenVPN, добавляю функции NAT для моего VPN-трафика и получаю прямой доступ в сеть DMZ в неограниченном виде через свой OpenVPN. Примечательно, что ISA, имея некоторые неотключаемые функции IPS, блокировала мой же трафик со сканированием портов, за что ее пришлось заменить на более простой и сговорчивый RRAS. Так что пентестерам еще иногда приходится администрировать всякое.
Внимательный читатель спросит: «А что второй сайт — wiki с NTLM-аутентификацией, про которую столько написано?» Об этом далее.
Часть 2. Вы все еще не шифруете? Тогда мы идем к вам уже тут
Итак, есть доступ в сетевой сегмент DMZ. Нужно идти к администратору домена. Первое же, что приходит в голову, — автоматизированно проверить на безопасность сервисы внутри сегмента DMZ, тем более что их теперь открылось для исследования гораздо больше. Типичная картина при тесте на проникновение: внешний периметр защищен лучше, чем внутренние сервисы, и при получении любого доступа внутрь большой инфраструктуры добыть расширенные права в домене гораздо проще только за счет того, что этот домен начинает быть доступным для инструментария, а во-вторых, в инфраструктуре на несколько тысяч хостов всегда найдется пара критических проблем.
Заряжаю сканеры по DMZ через OpenVPN-тоннель, жду. Открываю отчет — опять ничего серьезного, видимо кто-то прошелся таким же способом до меня. Следующее действие — исследование того, как обмениваются информацией хосты внутри сети DMZ. Для этого для начала запускается обычный Wireshark с прослушкой широковещательных запросов, в первую очередь ARP. ARP-пакеты коллекционировались целые сутки. Выясняется, что в этом сегменте применяется несколько шлюзов. Это пригодится далее. Склеивая данные по запросам-ответам ARP и данные сканирования портов, нашел выходные точки пользовательского трафика изнутри локальной сети в дополнение к тем сервисам, о которых ранее было известно, типа web и почты.
Так как на текущий момент у меня не было никакого доступа в другие системы и не было ни одной учетки для корпоративных сервисов, было решено выудить хоть какую-нибудь учетку из трафика при помощи ARP Spoofing.
На сервере уролога был запущен Cain&Abel. С учетом выявленных потоков трафика были выбраны наиболее перспективные пары для атаки «человек посередине», далее путем краткросрочного запуска на 5-10 минут, с таймером на перезагрузку сервера на случай «зависания», был получен некоторый сетевой трафик. Как в анекдоте, было две новости:
- Хорошая: учетных данных наловилось очень много и атака в целом работала.
- Плохая: все учетные данные были от клиентов самого заказчика. Оказывая услуги по поддержке, специалисты заказчика подключались к сервисам клиентов, у которых не всегда было настроено шифрование трафика.
В итоге я разжился множеством бесполезных в контексте проекта учетных данных, но однозначно интересных в качестве демонстрации опасности атаки. Пограничные роутеры крупных компаний с telnet, проброшенные отладочные http-порты на внутренние CRM со всеми данными, прямой доступ на RDP от Windows XP в локальной сети и прочее мракобесие. Получился этакий Supply Chain Compromise согласно матрице MITRE.
Также нашел забавную возможность собирать письма из трафика, примерно вот так. Это пример готового письма, которое шло от нашего заказчика на порт SMTP его клиента, опять же, без шифрования. Некий Андрей просит своего тезку заново выслать документацию, и она выкладывается на облачный диск с логином, паролем и ссылкой в одном ответном письме:
Это еще одно напоминание о том, что нужно шифровать все сервисы. Неизвестно, кто и когда прочитает и применит конкретно ваши данные — провайдер, системный администратор другой фирмы или вот такой пентестер. Молчу о том, что просто перехватить нешифрованный трафик может много кто.
Несмотря на кажущийся успех, к цели это не приблизило. Можно было, конечно, долго сидеть и выуживать ценную информацию, но не факт, что она бы там появилась, да и сама атака очень рискованная в плане целостности работы сети.
После очередного копания в сервисах в голову пришла интересная идея. Есть такая утилита, называется Responder (легко найти примеры применения по этому имени), которая путем «отравления» широковещательных запросов провоцирует на себя подключения по множеству протоколов типа SMB, HTTP, LDAP и т.д. разными способами, затем каждого подключившегося просит аутентифицироваться и подстраивает это так, что аутентификация проходит через NTLM и в прозрачном для жертвы режиме. Чаще всего атакующий таким образом собирает NetNTLMv2-хендшейки и из них по словарю быстро восстанавливает доменные пароли пользователей. Тут хотелось что-то подобное, но пользователи сидели «за стеночкой», а точнее, были отделены межсетевым экраном, а в WEB выходили через кластер прокси Blue Coat.
Помните, я уточнял, что имя домена Active Directory совпадало с «внешним» доменом, то есть было company.ru? Так вот, Windows, точнее Internet Explorer (и Edge, и Chrome), позволяют пользователю прозрачно аутентифицироваться в HTTP через NTLM, если посчитают, что сайт находится в некоторой «Intranet Zone». Один из признаков «Intranet» — обращение по «серому» IP-адресу или по короткому DNS-имени, то есть без точек. Так как в распоряжении был сервер с «белым» IP и DNS-именем preobrazhensky.company.ru, а доменные машины обычно получают суффикс Active Directory домена через DHCP для упрощенного ввода имен, то им достаточно было написать в адресной строке URL preobrazhensky, чтобы они нашли верный путь до скомпрометированного сервера уролога, не забывая, что это теперь называется «Intranet». То есть заодно отдав мне NTLM-handshake пользователя без его ведома. Осталось заставить клиентские браузеры подумать о срочной необходимости обращаться на этот сервер.
На помощь пришла замечательная утилита Intercepter-NG (спасибо Intercepter). Она позволяла менять трафик на ходу и прекрасно работала на Windows 2003. Там даже был отдельный функционал по модификации только JavaScript-файлов в потоке трафика. Планировался этакий массовый Cross-Site Scripting.
Прокси Blue Coat, через которые пользователи выходили в глобальный WEB, периодически занимались кешированием статического контента. Путем перехвата трафика было видно, что они трудятся круглосуточно, бесконечно запрашивая часто используемую статику для ускорения показа контента в пиковые часы. К тому же у BlueCoat был специфичный User-Agent, что однозначно отличало его от живого пользователя.
Был подготовлен Javascript, который при помощи Intercepter-NG ночью целый час внедрялся на каждый ответ с JS-файлами для Blue Coat. Скрипт делал следующее:
- Определял по User-Agent текущий браузер. Если это был Internet Explorer, Edge или Chrome — работал дальше.
- Ждал, пока сформируется DOM страницы.
- Вставлял в DOM невидимую картинку с атрибутом src вида preobrazhensky:8080/NNNNNNN.png, где NNN — произвольные цифры, чтобы BlueCoat не закешировал.
- Выставлял глобальную переменную-флаг, что инъекция была произведена и больше не нужно вставлять картинки.
Браузер пытался подгрузить эту картинку, на порту 8080 скомпрометированного сервера его ожидал TCP-туннель до моего ноутбука, где был запущен тот самый Responder, требующий от браузера входа по NTLM.
Судя по логам Responder, утром люди пришли на работу, включили свои рабочие станции, затем массово и незаметно для себя начали посещать сервер уролога, не забывая «сливать» NTLM-хендшейки. Хендшейки сыпались целый день и явно накопили материал для заведомо успешной атаки по восстановлению паролей. Примерно вот так выглядели логи Responder:
Массовые тайные посещения сервера уролога пользователями
Вы, наверное, уже заметили, что эта вся история строится по принципу «все было хорошо, но тут ждал облом, далее случилось превозмогание, а затем все пришло к успеху». Так вот, тут ждал облом. Из полутысячи уникальных хендшейков не было раскрыто ни одного. И это с учетом того, что даже на ноутбуке с дохлым процессором эти NTLMv2-хендшейки перебираются со скоростью несколько сотен миллионов попыток за секунду.
Пришлось вооружаться техниками мутаций паролей, видеокартой, словарем потолще и ждать. Через продолжительное время раскрылось несколько учеток с паролями вида «Q11111111….1111111q», что говорит о том, что всех пользователей когда-то заставили придумать очень длинный пароль с разным регистром символов, который предполагался быть еще и сложным. Но матерого пользователя просто так не проведешь, и он вот таким образом облегчил себе запоминание. Всего учеток вскрылось около 5 штук, и только одна из них обладала какими-то ценными правами на сервисах.
Часть 3. Роскомнадзор наносит ответный удар
Итак, были получены первые доменные учетки. Если вы к этому моменту не уснули от длинного чтения — вы, наверное, вспомните, что я упоминал сервис, который не требовал второго фактора аутентификации: это wiki c NTLM-аутентификацией. Разумеется, туда первым делом был совершен вход. Копание во внутренней базе знаний быстро принесло результаты:
- У компании есть WiFi-сеть с аутентификацией по доменным учеткам с доступом в локальную сеть. С текущим набором данных это уже рабочий вектор атаки, но нужно идти в офис ногами и где-то размещаться на территории офиса заказчика.
- Нашлась инструкция, согласно которой был сервис, позволявший… самостоятельно зарегистрировать устройство «второго фактора» аутентификации, если пользователь находится внутри локальной сети и уверенно помнит свои доменные логин и пароль. В данном случае «внутри» и «снаружи» определялось путем доступности порта этого сервиса для пользователя. Порт не был доступен из интернета, но вполне себе был доступен через DMZ.
Разумеется, к скомпрометированной учетке был тут же добавлен «второй фактор» в виде приложения на моем телефоне. Там была программа, которая может либо громко послать на телефон push-запрос с кнопками «одобрить»/«не одобрить» действие, либо молча показать код OTP на экране для дальнейшего самостоятельного ввода. Причем первый способ предполагался инструкцией единственно правильным, но не работал, в отличие от способа с OTP.
С поломанным «вторым фактором» удалось зайти в почту Outlook Web Access и на удаленный доступ в Citrix Netscaler Gateway. В Outlook на почте ждал сюрприз:
На этом редком кадре вы можете заметить, как Роскомнадзор помогает пентестерам
Это были первые месяцы после знаменитой «веерной» блокировки Telegram, когда неумолимо исчезали из доступа целые сети на тысячи адресов. Стало понятно, почему сразу не сработал push и почему моя «жертва» не забила тревогу оттого, что ее учеткой начали пользоваться в откровенно нерабочее время.
Кто знаком с Citrix Netscaler, тот представляет, что его обычно внедряют таким образом, чтобы можно было донести до пользователя только картинку-интерфейс, стараясь не давать ему в руки инструментов для запуска сторонних приложений и передачи данных, всячески ограничивая действия через стандартные оболочки управления. Моей «жертве» по роду деятельности досталась только 1С:
Немного погуляв по интерфейсу 1С, нашел, что там есть внешние модули обработки. Их можно подгружать с интерфейса, и они будут исполняться на клиенте или сервере, в зависимости от прав и настроек.
Попросил друзей-программистов 1С создать такую обработку, которая бы принимала строку и исполняла ее. На языке 1С запуск процесса выглядит примерно так (взято с просторов интернета). Согласитесь же, синтаксис языка 1С поражает русскоязычного человека своей непосредственностью?
Обработка прекрасно исполнилась, получилось то, что пентестеры называют «шеллом» — через нее был запущен Internet Explorer.
Ранее в почте был найден адрес системы, которая позволяет заказывать пропуска на территорию. Я заказал пропуск на случай, если придется использовать вектор атаки через WiFi.
В интернетах поговаривают, что в офисе заказчика был еще вкусный бесплатный общепит, но я предпочел все же развивать атаку через удаленку, так спокойнее.
На сервере приложений с Citrix был активирован AppLocker, но его удалось обойти. Был подгружен и запущен все тот же Meterpreter через DNS, так как http(s)-версии подключаться не хотели, а внутренний адрес прокси я тогда не знал. Кстати, с этого момента внешний пентест по сути окончательно перешел во внутренний.
Часть 4. Админские права у юзеров — это плохо, п-нятненько?
Первое дело пентестера при получении контроля над сессией доменного пользователя — это собрать всю информацию о правах в домене. Есть такая утилита BloodHound, которая автоматически позволяет выгрузить через протокол LDAP с контроллера домена информацию о пользователях, компьютерах, группах безопасности, а через SMB — информацию о том, какой пользователь где недавно совершал вход и кто где локальный администратор.
Типичная техника захвата прав администратора домена упрощенно выглядит как цикл монотонных действий:
- Идем на доменные компьютеры, где есть права локального администратора, исходя из уже захваченных доменных учеток.
- Запускаем Mimikatz и получаем кешированные пароли, билеты Kerberos и хеши NTLM доменных учеток, которые недавно совершали вход в эту систему. Либо снимаем образ памяти процесса lsass.exe и делаем то же самое на своей стороне. Это хорошо работает с Windows моложе 2012R2/Windows 8.1 с настройками по умолчанию.
- Определяем, где скомпрометированные учетки имеют права локального администратора. Повторяем первый пункт. На каком-то этапе получаем права администратора всего домена.
«КонецЦикла;», как написали бы тут программисты 1С.
Так вот, наш пользователь оказался локальным администратором всего на одном хосте с Windows 7, в имени которого было слово «VDI», или «Virtual Desktop Infrastructure», личные виртуальные машины. Вероятно, проектировщик сервиса VDI подразумевал, что раз VDI — личная операционная система пользователя, пусть тогда пользователь меняет программное окружение, как угодно, все равно хост можно «перезалить». Я тоже подумал, что в целом идея хорошая, зашел на этот личный хост VDI и свил себе там гнездо:
- установил туда OpenVPN-клиент, который делал туннель через интернет до моего сервера. Клиент пришлось заставить проходить через те самые Blue Coat с доменной аутентификацией, но OpenVPN справился, что называется, «из коробки».
- Установил на VDI OpenSSH. Ну правда, что это за Windows 7 без SSH?
Вот так это выглядело живьем. Напоминаю, что это все приходится делать через Citrix и 1С:
Одна из техник по продвижению доступа на соседние компьютеры — проверка паролей локальных администраторов на совпадение. Тут сразу ждала удача: хеш NTLM локального администратора по умолчанию (который внезапно звался Administrator) подходил через атаку pass-the-hash к соседним VDI-хостам, которых было несколько сотен. Само собой, атака тут же прошлась по ним.
Тут администраторы VDI выстрелили себе в ногу дважды:
- Первый раз, когда не ввели машины VDI под действие LAPS, по сути сохранив одинаковый пароль локального администратора из образа, который массово разворачивали на VDI.
- Администратор по умолчанию — единственная локальная учетка, которая уязвима к pass-the-hash атакам. Даже при одинаковом пароле можно было бы избежать массовой компрометации, сделав вторую учетку локального администратора со сложным случайным паролем, а дефолтного — заблокировать.
Зачем служба SSH на той Windows? Очень просто: теперь OpenSSH-сервер не только предоставлял удобную интерактивную командную оболочку без помех работе пользователя, но и socks5-прокси на VDI. Через этот socks я подключался по SMB и собирал со всех этих сотен машин VDI кешированные учетки, затем искал по ним в графах BloodHound путь до доменного администратора. Имея в распоряжении сотни хостов, я нашел такой путь довольно быстро. Права администратора домена были получены.
Вот картинка с просторов интернета, показывающая подобный поиск. Связи показывают, кто где администратор и кто куда вошел.
Кстати, помните условие со старта проекта — «не применять социальную инженерию». Так вот, предлагаю поразмышлять, насколько бы срезался бы весь этот Болливуд со спецэффектами, если все-таки можно было бы применить банальный фишинг. Но лично мне было очень интересно все это делать. Надеюсь, вам интересно было это читать. Конечно, не каждый проект выглядит вот так интригующе, но работа в целом очень головоломная и не дает застаиваться.
Наверное, у кого-то возникнет вопрос: а как защититься? Даже в этой статье описано много техник, про многие из них администраторы Windows даже не знают. Однако предлагаю посмотреть на них с позиции избитых принципов и мер информационной безопасности:
- не применять устаревшее программное обеспечение (помните Windows 2003 в начале?)
- не держать включенными ненужные системы (зачем был сайт уролога?)
- проверять пароли пользователей на прочность самостоятельно (иначе это сделают
солдаты…пентестеры) - не иметь одинаковых паролей к разным аккаунтам (компрометация VDI)
- и другое
Конечно, реализовать это очень тяжело, но в следующей статье мы покажем на практике, что это вполне возможно.
Автор: EditorGIB
