В этой статье нападающие узнают, что coerce можно осуществлять не только с 445/tcp порта, а защитники обнаружат, как можно надежно запретить принуждение к аутентификации.
Содержание
0.0 Intro
1.0 Техники принуждения к аутентификации
1.1 Принуждение к аутентификации -> SMB (NTLM)
1.2 Принуждение к аутентификации -> SMB (Kerberos)
1.3 Принуждение к аутентификации -> HTTP (NTLM)
2.0 Плохие примеры защиты
2.1 Закрываем 445/tcp порт
2.2 Обходим закрытый 445/tcp порт
2.3 Закрываем 139/tcp порт
2.4 Обходим закрытый 445/tcp и 139/tcp порты
2.5 Закрываем 135/tcp порт
2.6 Обходим закрытый 445/tcp, 139/tcp и 135/tcp порты
2.7 Отключение spooler
2.8 Обходим отключенный spooler
3.0 ЗАЩИТА (true way)
3.1 NETSH RPC filter
3.2 Тестирование защиты
Intro
Принуждение к аутентификации, или coerce в англоязычных источниках, – это особенность Windows-систем, которая сейчас достаточно активно используется в целом ряде атак на инфраструктуру Active Directory. Так с её помощью реализуются атаки:
ADCS ESC8 (уязвимость)
Kerberos Delegation abuse (мисконфиг)
LDAP abuse (мисконфиг)
разнообразные ACL abuse (мисконфиг)
наличие учеток компьютеров в локальных админах явно или через группы (мисконфиг)
и многое другое.
Все эти страшные слова часто приводят сразу к захвату контроллеров домена, а вместе с ними почти всей внутренней инфраструктуры…
Принуждение к аутентификации кроется в ряде RPC-функций, которые удаленно может вызвать любой пользователь (не администратор). В среде Active Directory каждая доменная учетка является пользователем по отношению к любому компу. В итоге все хосты находятся во взаимодоверительных отношениях и вызвать подобные RPC-функции вправе любой и на любом узле. Поведение же данных функций заключается в попытке обращения к сетевому диску по протоколу SMB либо HTTP с использованием WebDAV. А всякое подобное обращение происходит с использованием сквозной аутентификации и бессознательной отправки хэша пароля в виде NetNTLM либо же Kerberos-билета. При этом аутентификация осуществляется всегда под учетной записью компьютера . Далее хэш может быть повторно использован в атаке перенаправления (relay) и обходе аутентификации, либо происходит получение TGT-билета, в зависимости от реализуемой атаки. Тема relay-атак достаточно обширна и не входит в рамки данной статьи, более подробно о них можно почитать в Интернете, например, тут.
Если коротко, то благодаря технике принуждения к аутентификации мы вполне легитимно можем попросить любой комп аутентифицироваться на любом другом компе. Более того, мы можем попросить любой комп аутентифицироваться на нашем компе и перенаправить его аутентификацию на третий комп.
И вся беда в том, что компания Microsoft отказалась признавать данную «особенность» как уязвимость. А для атакующего такие трюки открывают немалые перспективы.
1.0 Техники принуждения к аутентификации
На данный момент существует 4 различных техники принуждения к аутентификации:
Протокол | SMB-пайпы | SMB-интерфейсы | Функции | Эксплойт |
MS_RPRN | \pipe\spoolss | 12345678-1234-ABCD-EF00-0123456789AB | opnum=1 RpcOpenPrinter(*pPrinterName, *pDatatype, pDevModeContainer, AccessRequired) | printerbug |
MS_EFSR | \PIPE\lsarpc, \PIPE\samr, \PIPE\lsass, \PIPE\netlogon, \PIPE\efsrpc | c681d488-d850-11d0-8c52-00c04fd90f7e, df1941c5-fe89-4e79-bf10-463657acf44d | opnum=0 - EfsRpcOpenFileRaw(*fileName, Flag), … | petitpotam |
MS_DFSNM | \PIPE\netdfs | 4fc742e0-4a10-11cf-8273-00aa004ae673 | opnum=13 NetrDfsRemoveStdRoot(*ServerName, *RootShare, ApiFlags), … | dfscoerce |
MS_FSRVP | \PIPE\FssagentRpc | a8e0653c-2744-4389-a61d-7373df8b2292 | opnum=8 IsPathSupported(*ShareName), opnum=9 IsPathShadowCopied(*ShareName), …. | shadowcoerce |
Каждая из представленных RPC-функций принимает в одном из параметров полный путь вида «\\IP\Share\path\to\something», позволяющий указать удаленный узел (UNC), куда будет произведено обратное подключение. Реально же перечень RPC-функций, принимающих UNC-путь, шире, чем задействовано в эксплойтах, но их упоминание все равно можно увидеть в коде.
В зависимости, от того, в каком виде задается цель для обратного подключения возможны 3 различных поведения.
1.1 Принуждение к аутентификации -> SMB (NTLM)
Если адрес обратного подключения задан в виде IP, то подключение будет производиться на сетевой диск по протоколу SMB, с использованием NTLM:
Аутентификация на SMB – это, как правило, либо доступ к сетевым дискам, либо сразу компрометация системы, т.к. при наличии должных прав атакующий сможет запускать службы по MSRPC, который работает под SMB.
1.2 Принуждение к аутентификации -> SMB (Kerberos)
Если адрес обратного подключения указан в форме полного доменного имени (FQDN), то подключение произойдет также на сетевой диск по протоколу SMB, но уже с использованием протокола аутентификации Kerberos:
Данная аутентификация позволит захватить из трафика TGT-билет от хоста, аутентифицирующегося на узле с неограниченным делегированием. Это практически равносильно получению пароля от учетной записи.
1.3 Принуждение к аутентификации -> HTTP (NTLM)
Вся работа по MSRPC происходит через пайпы и полный список всех пайпов часто можно взять уже по SMB, с "как бы" сетевого диска IPC$:
Наличие пайпа "DAV RPC" означает запущенную службу WebClient, благодаря которой проводник Windows начинает работать с вебом, как с папками. Но это удобство кроет большую опасность, т.к. теперь атакующий может заставить аутентифицироваться такой узел уже с использованием HTTP. Чтобы обратное подключение происходило по протоколу HTTP, его адрес должен быть указан в форме сокращенного доменного имени (без суффикса) как на скрине:
Аутентификация с HTTP может быть перенаправлена практически куда угодно, где поддерживается NTLM, в частности, на LDAP, где злоумышленник при наличии прав сможет сделать достаточно многое. Но это уже совсем другая история (см. ldap abuse, например, https://www.thehacker.recipes/ad/movement/ntlm/relay). А вот на HTTP аутентификация для её байпаса перенаправлялась как раз в ADCS ESC8.
Теперь посмотрим, как можно защищать конечные рабочие станции и серверы от принуждения к аутентификации.
2.0 Плохие примеры защиты
Давайте посмотрим, насколько надежны популярные рекомендации по защите от принудительной аутентификации.
2.1 Закрываем 445/tcp порт
Достаточно частой рекомендацией является блокировка 445/tcp порта как источника разнообразных бед. Но тем не менее данный порт может быть реально нужен по причине тех же сетевых дисков, и закрывать его как-то не совсем правильно.
Проверим, насколько это надежное решение:
На стороне атакующего:
Да, атака не сработала.
2.2 Обходим закрытый 445/tcp порт
Но часто RPC можно использовать на 139/tcp порту (SMB over NetBIOS). Для этого мы должны обратиться к цели не по IP-адресу, а по NetBIOS-имени:
В результате принимаем аутентификацию от хоста:
Сетевой трафик наглядно демонстрирует обход использования 445/tcp-порта:
Видим, что 139/tcp порт тоже может быть SMB.
2.3 Закрываем 139/tcp порт
Закроем по аналогии и 139/tcp порт:
Теперь закрыты оба порта 445/tcp и 139/tcp, предоставляющие MSRPC.
2.4 Обходим закрытые 445/tcp и 139/tcp порты
Даже если вы решили все-таки закрыть 139 и 445 порты, то DCERPC всё так же в распоряжении атакующего:
Многие RPC-функции доступны разными транспортами – как по MSRPC (445/tcp), так и по DCERPC (135/tcp, 4915x/tcp, ...):
С endpoint mapper (135/tcp) мы можем узнать номер динамического TCP-порта, где доступна нужная нам RPC-функция.
2.5 Закрываем 135/tcp порт
Закроем и 135/tcp порт:
Теперь закрыты 445/tcp, 139/tcp и 135/tcp.
2.6 Обходим закрытые 445/tcp, 139/tcp и 135/tcp порты
С блокировкой DCERPC не так все просто, т.к. он использует динамический пул TCP-портов. Закрытие 135/tcp порта ненадежная мера, т.к. перечень RPC-интерфейсов атакующий сможет получить с динамического пула портов, предварительно просканировав его с помощью nmap, а затем опросив каждый из найденных на наличие нужного UUID:
Теперь вызываем RPC-функцию по DCERPC:
На стороне атакующего снова принимаем аутентификацию:
В дампе трафика видно, что ни 135, ни 139, ни тем более 445 порты не были задействованы. Использован только динамический DCERPC порт, который на каждой машине может быть разным.
Выходит, выборочная блокировка портов – решение очень ненадежное.
2.7 Отключение spooler
Ещё одной старой рекомендацией является тупо отключение spooler:
2.8 Обходим отключенный spooler
Тут все просто. Как мы знаем printerbug далеко не единственный способ для coerce:
Аутентификация вновь успешно запрошена:
3.0 ЗАЩИТА (true way)
Встроенный в Windows фаервол, он же брандмауэр, обладает также некоторыми функциями application фаервола, и он как раз умеет фильтровать RPC.
Если мы взглянем на таблицу с опасными RPC-функциями, то заметим, что объединяет их как раз общий UUID.
3.1 NETSH RPC filter
Основываясь на рекомендации Benjamin Delpy всё, что требуется, это методично ввести данные команды для каждого RPC-интерфейса:
И так далее для интерфейсов:
· 12345678-1234-ABCD-EF00-0123456789AB
· c681d488-d850-11d0-8c52-00c04fd90f7e
· df1941c5-fe89-4e79-bf10-463657acf44d
· 4fc742e0-4a10-11cf-8273-00aa004ae673
· a8e0653c-2744-4389-a61d-7373df8b2292
3.2 Тестирование защиты
А теперь проверим доступность всех 64 функций на заблокированном интерфейсе, одну из которых использует printerbug.
На MSRPC до и после включения фильтрации имеем:
В первом случае имеем rpc_x_bad_stub_data это ОК, т.к. были указаны некорректные аргументы функций, а во втором, ожидаемо, rpc_s_access_denied.
Для DCERPC аналогично доступ к функциям на интерфейсе до и после включения фильтрации:
Аналогично можно проверить доступность интерфейсов для petitpotam, dfscoerce и shadowcoerce.
И вполне закономерно, что сами эксплойты также не сработают:
И так далее для dfscoerce и shadowcoerce.
Ни один из способов принуждения к аутентификации теперь не работает. Защиту можно считать надежной.
Запретив coerce, вы повысите уровень безопасности серверов и рабочих станций во внутренней инфраструктуре своей компании, сильно осложнив жизнь потенциальным злоумышленникам.
