New whitepaper

Запилил вторую пдфку, про smb hijacking.

прямой линк - http://intercepter.nerf.ru/SMB_Hijacking.Kerberos_is_defeated.pdf

Ответ на вопросы №1 (немного с юмором)

Периодически меня спрашивают, почему отечественная программа и вдруг на английском. Хочу еще раз дать ответ приведя короткий диалог. Ни в коем случае не в обиду автору письма, человек хотел как лучше.


Добрый день.

Суть обращения: Вычитав и одного блога про вашу программу "intercepter". И про ваше отношения к платному совту и.т.д
Конечно порадовало, что хороший продукт вы не соберетесь делать платным.
Но возник небольшой казус. Хотелось бы ее русифицировать.

Может возможно выпуск следующего обновления - в котором будет конфиг с меню и всем командами программы.
А этот конфиг мы бы уже самостоятельно русифицировали
-
Добрый день. Русской версии и конфига с надписями не будет. В этом нет никакого смысла, там используется сугубо технический английский, не требующий перевода, а требующий понимания самого понятия с технической точки зрения. ARP Poison - как вы это переведете на русский ? Никак.
-
ARP Poison - отправка ARP запроса.
или отправить широковещательный запрос с поиском участников сети :) - не маленький перевод :)
Зато понятный
Вашу точку зрения я понял. Все равно большое спс за продукт.
-
Вы только что подтвердили мои слова. Перевод фразы вам ничего не дал, суть совершенно иная, не имеющая отношения к арп запросам и поиску участников.


Вот так. Анлийский в интерфейсе это толком и не английский, а набор терминов, прямой перевод которых бессмысленен.  Как бы вы перевели "kerberos downgrade" - опущение цербера?!

SMB Hijacking. Kerberos не помеха

Про SMBRelay (или если быть точным NTLM-Relay) написано и сказано довольно много. Совершенно нет желания вспоминать подробности данной атаки. Напомню только то, что суть атаки сводится к манипуляциям с аутентификационными данными пользователя, которые затем могут быть перенаправлены на другой ресурс.
Такое перенаправление позволяет аутентифицироваться и получить доступ к третьему ресурсу, что обычно выливается в загрузку файла с его последующим запуском.

Процесс развития релеинга уже давно стоит на месте. И верно, чего казалось бы там улучшать, все ясно и понятно. Чуть больше года назад в Intercepter'е появилась возможность осуществлять перенаправление NTLMv2. Спустя 3 месяца подобный функционал появился и в Metasploit'е, а затем отдельно взятые энтузиасты стали накидывать свои наработки. Вот он, логический предел. Сам SMBRelay уже практически не применяется, гораздо удобнее в этом плане осуществлять NTLM-Relay через другие протоколы, в частности HTTP. К тому же жизнь SMBRelay'ю в доменных сетях осложняет «непобедимый» Kerberos, зачастую именуемый лекарством от SMBRelay. Своим исследованием я хотел бы разрушить этот миф и представить совершенно новый подход к проведению атаки на протокол SMB.
Стоит заметить, что это уже будет не совсем SMBRelay, назовем данную технику SMB Hijacking.

Начнем из далека…

В новой версии интерцептера появился NTLM-Response граббер, встроенный в WPAD MiTM.
Для удобства использования было решено сделать возможность вызывать John the Ripper с перехваченным хешем, чтобы быстро проверить, установлен ли пустой или легкий пароль. После чего все хеши которые перехватывает снифер и которые поддаются брутфорсу через JTR были приведены в соотвествующий формат.

В архиве семплов Wireshark'а нашелся лог с авторизацией Kerberos, из которого Cain смог вытащить хеш и методом перебора подобрать пароль.
Брутфорс возможен благодаря тому, что в запросе AS-REQ на сервер аутентификации передается шифрованый паролем пользователя timestamp, часть которого заранее известна. Обработчик Kerberos аутентификации был добавлен и протестирован на живом контроллере домена (Windows 2008 R2). К удивлению хеш не перехватился. Все дело в том, что в Windows 2008 добавились новые алгоритмы шифрования и вместо ранее применяемого rc4-hmac, теперь по-умолчанию используется aes256-cts-hmac-sha1-96. Выдергивается этот хеш из пакета точно так же как и rc4-hmac, вот только появилась другая проблема.
На данный момент нет переборщиков способных восстановить пароль из timestamp'а зашифрованного aes'ом. В мейллисте john'a один товарищ написал патч для JTR, но судя по отзывам он еще сыроват и самое главное процесс перебора в сотни раз медленней чем перебор rc4.

Так в интерцептере появилась опция по даунгрейду алгоритма шифрования, с aes до rc4. К сожалению начиная с Vista des шифрование было отключено и минимально возможным является именно rc4, поэтому смысла даунгрейдить еще ниже не было.


Даунгрейд осуществляется простой заменой возможных методов в исходящем пакете жертвы.

Именно здесь возник интерес к керберосу. Изучение материала показало, что существует теоретическая возможность replay атак тикетов кербероса, но никаких реальных примеров и реализаций не было найдено.

Во время раздумий и анализа трафика возник совершенно странный вопрос: а зачем нам вообще что-то re(p)lay'ить ?! Да не зачем!

Что из себя представляет сеанс SMB?

1. Host_A соединяется с Host_B
2. Выбирается протокол сеанса
3. Выбирается способ авторизации
4. Набор команд…

ЗАЧЕМ НАМ РЕЛЕИТЬ АВТОРИЗАЦИЮ ЖЕРТВЫ ЕСЛИ ОНА САМА ПРЕКРАСНО АВТОРИЗУЕТСЯ НА НУЖНОМ РЕСУРСЕ?!

Нам всего лишь нужно встать посередине и проксировать соединение, дождаться пока Host_A авторизуется на Host_B, а затем взять контроль над сессией в свои руки!
Мы уже авторизованы и можем внедрить свой код в SMB сеанс. Нас совершенно не интересует каким способом авторизовывался клиент, будь то NTLM или Kerberos!
Сам сеанс никак не шифруется, а SMB Signing на рядовых клиентах в 99% случаев не используется.
Помимо бОльших возможностей, эта техника гораздо элегантнее чем SMBRelay, с нас снимается необходимость реализовывать самостоятельно мудреный процесс SMB авторизации.
Достаточно реализовать минимальный набор команд, которые позволят загрузить файл и выполнить его запуск.

Весь этот функционал появился в новой версии Intercepter-NG и протестирован в реальных условиях с самыми последними версиями Windows 2008 и Windows 7/8.

Какие же сложности и особенности имеются в реализации данной атаки.
Начиная с Vista стал использоваться новый протокол SMB2. Основным отличием от старой версии является упрощенный набор команд и увеличение производительности.
Для нас важным является соблюсти два правила. Во первых, каждый SMB сеанс имеет свой Session ID, а во вторых в заголовке SMB2 имеется поле Command Sequence Number,
т.е. порядковый номер команды. Для внедрения команд необходимо указывать идентификатор сессии и инкрементировать счетчик команд.

Т.к. в Intercepter существующий SMBRelay основан на чужом коде, использующем старый формат SMB, то было принято решение не лепить костыли и с нуля реализовать основной набор команд SMB2.

Логика внедрения в сессию следующая:

1. Встать посередине между атакуемым и третьим хостом
2. Дождаться команды SessionSetup Response с положительным ответом
3. Получить Session ID и текущий номер команды
4. Скопировать файл на административную шару (admin$)
5. Создать службу, которая запустит наш файл
6. Запустить службу
7. cmd.exe

Пятый и шестой пункты возможны лишь потому, что Microsoft позволяет передавать RPC запросы поверх SMB.



Вот собственно и все. Техника прекрасно работает в среднестатистическом домене. Зачастую имеется некий софт, который в автоматическом режиме производит какие-то операции на клиентских компьютерах через SMB под учетной записью имеющей административный доступ. Или непосредственно администратор может стать целью атаки.

Керберос нам не помеха. Кстати Kerberos в SMB используется только если обращение к компьютеру производится по имени, а если обращаться на шару через IP то применяется только NTLM. При атаке клиентов домена, атакующему вовсе не обязательно самому быть членом домена.
Использовать SMB Hijacking можно и в обычной рабочей группе, при условии соблюдения требований: наличие административного доступа у атакуемого и доступные административные ресурсы IPC$\ADMIN$.
Помимо пассивного перехвата SMB сессий, Intercepter так же инжектит ссылку на SMB ресурс в web трафик атакуемого, что значительно ускоряет процесс получения доступа.

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

Демо-видео по проведению SMB Hijacking ниже.



Помимо Kerberos Downgrade и SMB Hijacking в новой версии Intercepter'а произошли следующие изменения.

Во встроенный прокси-сервер WPAD MiTM'а интегрирован NTLM-Response граббер. Полученные хеши можно подвергнуть перебору.
Теперь для ряда перехватываемых хешей доступен запуск брутфорса прямо из программы, для этого необходимо предварительно скачать JTR (с патчем jumbo) и положить его в папку с Intercepter'ом.
В Smart Scan добавлен новый метод OS фингерпринтинга, дающий более точный результат.
Появился SYN сканнер портов, whitelist мак адресов для DHCP MiTM, поддержка IDN (национальных доменных имен) и еще множество улучшений и исправлений.

SMB Hijacking используется по-умолчанию, если необходимо провести старый SMBRelay, то нужно переключить соответствующую галку в экспертном режиме.

Задать вопросы можно на форуме или по почте.

Информация представлена в ознакомительных целях. Автор не несет ответственности за любой возможный вред, причиненный материалами данной статьи.

MiTM атака на SSH

В новой версии Intercepter-NG появилась возможность провести полноценную атаку на SSH-2 протокол. 

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

Это единственный подозрительный момент который возникает при проведении атаки.

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

И далеко не всегда атакуемый пользователь является администратором ssh сервера, для него смена ключей и предупреждения не имеют никакого значения.

Встроенный в Intercepter ssh сервер поддерживает 2 механизма аутентификации: password и keyboard-interactive.

Во время сеанса связи пользователь может запускать псевдографические приложения (например mc), все будет работать корректно. Так же Intercepter следит за сообщением WINDOW_CHANGE и при ресайзе окна терминала вся графика будет перерисована под новый размер.

Атака рассчитана только на терминальный сеанс, SFTP не поддерживается. Если жертва все-таки запустит SFTP сессию, то будет перехвачена авторизация, но затем соединение будет разорвано и сессия отметится особым образом. При повторном соединении Intercepter пропустит эту сессию напрямую, позволив жертве нормально установить SFTP сеанс с оригинальным сервером.

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

Видео демонстрация атаки

Информация представлена в ознакомительных целях. Автор не несет ответственности за любой возможный вред, причиненный материалами данной статьи.

Принудительный разрыв HTTP сессий при MiTM

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

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

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

Логика работы следующая. После начала атаки мониторятся куки передаваемые от клиента к серверу и обратно.
Куки от сервера заносятся в белый список, как только что установленные. При встрече куков от клиента, которых нет в белом списке, происходит отправка HTTP ответа, в котором все переданные куки обнуляются следующим образом:

Set-Cookie: %cookiename%=; path=/; domain=%domain%; Expires=Thu, 01 Jan-2000 00:00:01 GMT

При удачном раскладе (разные ресурсы и браузеры по-разному могут осуществлять работу с cookies) произойдет перенаправление на страницу авторизации. Сброшенные куки заносятся в белый список и в дальнейшем спокойно пропускаются, т.е. после повторного захода на ресурс никаих разрывов больше не происходит.

Идея заимствована из утилиты sslstrip, иных упоминаний и реализаций обнаружено не было.

Описанный «убийца кукисов» появился в Intercepter-NG 0.9.5, демонстрация работы представлена на следующем видео.

Помимо cookie killer'a в новой версии появился DNS спуфинг, ARP «клетка» для изоляции одних хостов от других,
поддержка нового формата Wireshark — pcapng и т.д. Дополнительная информация на сайте проекта.

Актуальность атаки SMBRelay в современных Windows сетях

Впервые с smbrelay я столкнулся в середине 2000х годов и знакомство оказалось неудачным. На тот момент существовало всего несколько эксплоитов, которые даже в то время работали абы как. И это не смотря на то, что сама уязвимость протокола выявлена еще в конце 90х годов. Не получив нужного результата весь интерес совершенно пропал.

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

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

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

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

В smbrelay3 от Tarasco Security появился набор расширенных методов эксплуатации данной уязвимости. Помимо классической схемы smb->smb, добавились способы перенаправления аутентификации с таких сервисов как HTTP\IMAP\POP3\SMTP. Все они поддерживают авторизацию через NTLM.

На непатченой Windows XP SP3 удалось без проблем запустить cmd.exe даже при перенаправлении жертвы на саму себя (фикс MS08-068 вышел позже).
Перенаправление авторизации с XP на Windows 2003 так же прошло успешно (при наличии соответствующего доступа).
Но Windows XP это уже часть прошлого, а меня интересовала эксплуатация smbrelay в современных сетях, где в качестве клиентских ОС используется Windows 7.

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

Первой проблемой стало то, что в Windows 7 по-умолчанию «LAN Manager authentication level» установлен в «Send NTLMv2 response only». И так вышло, что все существующие реализации smbrelay (включая smbrelay3 и соответствующий модуль в Metasploit) не поддерживают релеинг NTLMv2 авторизации. Очевидно, раньше в этом не было необходимости, а позже никто не удосужился добавить эту поддержку.

Внеся необходимые изменения в исходный код smbrelay3, NTLMv2 был успешно зарелеен с Windows 7 на Windows XP. Но вылез следующий нюанс.
В Windows 7, с его обновленным IE, поменялось значение понятия Intranet. Раньше было все просто, если в рабочей группе сетевое имя вида 'some_host' резольвится в IP адрес локального сегмента, то стало быть он находится в Intranet и с ним можно автоматически провести авторизацию, используя данные активной сессии. В свойствах IE семерки имеется опция, установленная по-умолчанию, 'Automaticaly detect intranet network', так вот, в таком режиме обнаружения сети Intranet, привычная рабочая группа к внутренней доверенной сети больше не относится и является недоверенной зоной, а посему никакой автоматической авторизации не произойдет. Зато будучи в домене, Windows 7 с радостью предоставит все нужные данные любому компьютеру из локальной сети.

Таким образом, при включенной опции обнаружения Intranet, Win7 в рабочей группе не подвержена атаке smbrelay, но станет уязвимой в домене.

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

Обязательным условием для успешного применения атаки является наличие доступа к административным ресурсам IPC$ и ADMIN$, без них не будет возможности удаленно выполнить код, хотя возможность «шариться» по другим ресурсам (C$...) сохраняется.

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

Результатом исследования стала реализация стабильного модуля для проведения атаки smbrelay в составе Intercepter-NG. Для избежания трудностей, связанных с работающей на 445 порту службой Server, атака проводится по направлению HTTP->SMB. Т.е. при входящем соединении браузеру будет предложена NTLM авторизация, которая в дальнейшем будет перенаправлена или на тот же самый хост или на какой-то другой.

Основной проблемой в проведении атаки всегда являлась задача по заманиванию жертвы на наш ресурс, в основном это делалось либо отсылкой электронного письма, или выкладыванием файла со злонамеренной ссылкой на общий ресурс, реже за счет использования ettercap и подмене веб трафика.
В нашем случае выбран последний вариант, как наиболее быстрый и эффективный. Выбирается цель, затем проводится Arp Poison и в веб трафик инжектится ссылка, при запросе которой будет проведена smbrelay атака. Весь процесс автоматизирован и никакого вмешательства не требуется. Для стабильного и тихого инжекта выбран метод замены, а не добавления, поэтому замене подвергаются «ненужные» участки HTML кода, такие как <!DOCTYPE...>, <meta name=«keywords»...> и <meta name=«description»...>. Большинство сайтов содержат хотя бы один из них, поэтому долго ожидать не придется.

Дополнительно отметим, что автоматическую авторизацию через NTLM поддерживают только IE\Chrome, поэтому провести атаку на FireFox\Opera не получится.

Видео-демонстрацию можно посмотреть ниже.

Итог. SMBRelay является актуальной проблемой даже сейчас и в руках злоумышленника может стать серьезным орудием для проникновения в локальной сети.
Для предотвращения атак на клиентских компьютерах следует включить SMB Signing через соответствующие ключи реестра «EnableSecuritySignature, RequireSecuritySignature».

Информация представлена в ознакомительных целях. Автор не несет ответственности за любой возможный вред, причиненный материалами данной статьи.

Update: Совсем забыл уточнить, если при попытке перенаправить авторизацию одно из условий не было выполнено (отсутствует административный ресурс или непосредственно доступ аккаунта к ресурсу), то в любом случае у нас остается NTLMSSP хеш и челендж атакуемого пользователя, который поддается брутфорсу.

Перехват WEB трафика через протокол WPAD при помощи Intercepter-NG

WPAD — WebProxy Auto-Discovery. Протокол автоматического получения настроек прокси в локальной сети, поддерживается практически всеми веб-браузерами и рядом других приложений.

В кратце суть его работы такова: если клиент использует DHCP для получения IP адреса, то и за урлом с настройкой прокси он обращается к своему DHCP серверу. Если DHCP не настроен на выдачу WPAD конфигурации или в сети не используется DHCP как таковой, то клиент пробует разрешить сетевое имя вида wpad.localdomain используя DNS. Если такое имя не найдено, то делается последняя попытка поиска имени 'WPAD' через NetBios. Если имя не найдено, клиент пробует соединиться напрямую, но если кто-то в сети сказал что он имеет имя 'WPAD', то клиент соединяется по 80 порту на IP ответившего хоста и затем пытается загрузить файл wpad.dat, в котором должны находиться настройки прокси.

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

1. Необходимо зарегистрировать в сети имя 'WPAD'.
2. Необходимо запустить веб-сервер и создать файл wpad.dat.
3. Необходимо запустить прокси-сервер.

Если на Unix это проделывается достаточно быстро, то на Windows выполнение подобных операций требует больше времени и усилий. Дополнительно возникает проблема с переименованием в сети. Довольно подозрительно будет выглядеть компьютер с именем 'WPAD' в сетевом окружении, а если захочется применить инструмент вроде nbtool для того чтобы cкрытно отвечать на запросы имени 'WPAD', то придется остановить netbios ns службу Windows для освобождения 137 udp порта и соответственно отключиться от сети.

Тем не менее, имеется большое количество потенциальных жертв в любой сети, потому что по умолчанию Internet Explorer (а соответственно и Chrome) пытаются автоматически получить настройки прокси средствами WPAD.

В Intercepter-NG проведение атаки на WPAD полностью автоматизировано и проходит за несколько секунд.

Благодаря использованию WinPcap нет нужды прослушивать сокеты или переименовывать собственное netbios имя. Указывать конкретных жертв не требуется, выдача конфигурации происходит всем запросившим.

На выбор можно вручную указать прокси сервер, который будет выдаваться клиентам или использовать встроенный socks. В последнем случае для перехвата трафика кроме самого Intercepter-NG больше ничего не требуется.


Демонстрация работы представлена на следующих видео роликах.

О чем этот блог

Данный блог был создан с одной основной целью - централизованное хранение любого материала связанного с проектом Intercepter-NG.

Помимо своих личных статей вероятно буду выкладывать линки и на сторонние ресурсы, так или иначе упоминающие цептер.

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