Впервые с smbrelay я столкнулся в середине 2000х годов и знакомство оказалось неудачным. На тот момент существовало всего несколько эксплоитов, которые даже в то время работали абы как. И это не смотря на то, что сама уязвимость протокола выявлена еще в конце 90х годов. Не получив нужного результата весь интерес совершенно пропал.
Но вот буквально пару недель назад появилось желание исследовать вопрос еще раз. Оказалось, что по большому счету ситуация не изменилась, но появились новые эксплоиты, работоспособность которых и захотелось проверить.
Для тех кто слабо знаком с уязвимостью SMB напомним ее суть. Заставив жертву зайти на smb ресурс злоумышленника, атакующий может совершить перенаправление аутентификационных данных на саму же жертву, тем самым получив доступ к диску и через службу межпроцессного взаимодействия выполнить любой код.
Стоит отметить, что столь серьезная уязвимость в первозданном виде просуществовала до конца 2008 года, ровно до тех пор, пока не появился вменяемо работающий эксплоит.
Патч запретил принимать входящее соединение с тем же челенджем, который уже используется при исходящем подключении. Т.е. релеинг жертвы самой на себя был прикрыт.
Но никакой патч не запретит нам перенаправить авторизацию на некий третий ресурс, к которому у атакуемой жертвы имеется доступ.
В smbrelay3 от Tarasco Security появился набор расширенных методов эксплуатации данной уязвимости. Помимо классической схемы smb->smb, добавились способы перенаправления аутентификации с таких сервисов как HTTPIMAPPOP3SMTP. Все они поддерживают авторизацию через 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 поддерживают только IEChrome, поэтому провести атаку на FireFoxOpera не получится.
Видео-демонстрацию можно посмотреть ниже.
Итог. SMBRelay является актуальной проблемой даже сейчас и в руках злоумышленника может стать серьезным орудием для проникновения в локальной сети.
Для предотвращения атак на клиентских компьютерах следует включить SMB Signing через соответствующие ключи реестра «EnableSecuritySignature, RequireSecuritySignature».
Информация представлена в ознакомительных целях. Автор не несет ответственности за любой возможный вред, причиненный материалами данной статьи.
Автор: Intercepter
