При исследовании всех компонентов и конфигураций, связанных со службами сертификации Windows Active Directory (ADCS), после «глубокого погружения» в группу « Издатели сертификатов » я решил взглянуть на группу « Доступ к службе сертификации DCOM ».
Эта группа является встроенной локальной группой безопасности и заполняется специальной группой идентификации NT AUTHORITY\Authenticaterd Users , которая представляет каждую учетную запись пользователя домена, которая может успешно войти в домен, когда сервер берет на себя роль центра сертификации ( CA) путем установки роли служб сертификации Active Directory (ADCS).
«Доступ к DCOM» несколько интригует; это вызывает потенциальные уязвимости и эксплуатацию
Но давайте начнем с самого начала. Какова цель этой группы? MS говорит: « Членам этой группы разрешено подключаться к центрам сертификации на предприятии ».
Проще говоря, эта группа может регистрировать сертификаты через DCOM. Таким образом, логично, что все прошедшие проверку подлинности пользователи и компьютеры имеют доступ к конкретному приложению.
Каждый раз, когда пользователь или компьютер регистрирует или автоматически регистрирует сертификат, он связывается с интерфейсами DCOM приложения запроса CertSrv , которые предоставляются через протокол MS-WCCE , протокол регистрации сертификатов клиента Windows.
Существует также определенный набор интерфейсов для протокола удаленного администрирования служб сертификации, описанный в MS-CSRA .
Я не буду углубляться в особенности этих интерфейсов. Возможно, есть интересные интерфейсы, которые стоит изучить и использовать, но сейчас мое внимание было сосредоточено на разрешениях активации этого сервера DCOM.
Инструмент DCOMCNFG предоставляет нам много полезной информации.
На уровне компьютера группа доступа DCOM службы сертификатов «ограничена» разрешениями на локальный и удаленный запуск:
Это не означает, что эта группа может активировать все объекты DCOM, мы должны смотреть на конкретное приложение, в нашем случае запрос CertSrv:
Каждый может удаленно активировать этот сервер DCOM. Честно говоря, я ожидал найти здесь группу доступа DCOM службы сертификатов вместо «Все», учитывая, что эта группа ограничена разрешениями на локальный запуск и локальную активацию:
Возможно, также оцениваются какие-то комбинированные разрешения и вложенное членство.
Есть еще один интересный аспект: насколько я заметил, группа доступа к службе сертификатов DCOM является одной из немногих групп, наряду с пользователями распределенного COM и пользователями журнала производительности , которым предоставлены разрешения на удаленную активацию .
Давайте также посмотрим на идентичность:
Это приложение DCOM олицетворяет учетную запись SYSTEM, которая нам и нужна, поскольку она представляет собой локальный идентификатор с наивысшим уровнем привилегий.
Итак, у нас есть работающий привилегированный сервер DCOM, который может быть активирован удаленно любым прошедшим проверку подлинности пользователем домена. Кажется, это склонно к нашим любимым *картофельным подвигам, вам не кажется?
Таким образом, большинство этих эксплойтов основаны на злоупотреблении службой активации DCOM, работающей в контексте с высокими привилегиями, путем демаршаллинга объекта IStorage и отражения аутентификации NTLM обратно в локальную конечную точку TCP RPC для достижения локального повышения привилегий.
Существуют также варианты этой атаки, которые включают передачу аутентификации пользователя или компьютера NTLM (и Kerberos) на удаленную конечную точку с использованием таких протоколов, как LDAP, HTTP или SMB, что в конечном итоге позволяет повысить привилегии до администратора домена. И это то, что мы с @splinter_code сделали в нашем RemotePotato0 .
Но этот сценарий отличается: как пользователь домена с низким уровнем привилегий, мы хотим активировать удаленное приложение DCOM, работающее в контексте с высокими привилегиями, и заставить его пройти аутентификацию на удаленном прослушивателе, работающем на нашей машине, чтобы мы могли захватить и передать это аутентификация на другом сервисе.
Мы (надеемся) получим аутентификацию самого удаленного компьютера, когда приложение DCOM работает в контексте системы или сетевой службы.
Звучит здорово! l Итак, какие конкретные шаги нам следует предпринять для реализации этого?
Ну, это гораздо проще, чем я думал изначально
Начиная с оригинального JuicyPotato, я внес некоторые незначительные изменения:
И да, это сработало.
Сбрасывая сообщения NTLM, полученные на нашем сервере сокетов, мы видим, что получаем сообщение аутентификации типа 3 от удаленного сервера CA (SRV1-MYLAB):
Сетевой захват показывает, что удаленная активация, запрошенная нашим пользователем с низким уровнем привилегий, прошла успешно:
Последним шагом является перенаправление аутентификации NTLM на внешний ретранслятор, например ntlmrelayx , что позволяет выполнять аутентификацию другой службе, например самому компьютеру CA.
И последнее, но не менее важное: поскольку у нас есть аутентификация клиента RPC, мы должны инкапсулировать и пересылать сообщения аутентификации, используя протокол, уже реализованный и поддерживаемый в ntlmrelayx, например HTTP.
Держу пари, что теперь возникает роковой вопрос:
Хорошо, обычные пользователи домена могут удаленно выполнить аутентификацию сервера ADCS, перехватить сообщения аутентификации и ретранслировать их, но действительно ли это полезно?
Что ж, учитывая существование других непропатченных методов принудительной аутентификации контроллера домена, таких как DFSCoerce , я бы сказал, что его полезность может быть ограничена.
Ситуация еще больше усложняется тем, что единственными протоколами, которые можно ретранслировать из-за недавно введенного MS в DCOM ужесточения безопасности , на данный момент являются HTTP и SMB (если подпись не требуется).
В своей лаборатории я тестировал ретранслятор на конечной точке HTTP /CertSrv веб-сервера регистрации CA, работающего на другом компьютере (догадайтесь, почему?… вы не можете ретранслировать обратно на тот же компьютер по сети). Не имея никаких средств защиты NTLM, я запросил сертификат компьютера для сервера CA.
Схема атаки показана ниже:
С помощью этого сертификата я мог затем войти на сервер ADCS в контексте с высокими привилегиями. Например, я мог бы создать резервную копию закрытого ключа центра сертификации, что в конечном итоге позволит подделывать сертификаты от имени любого пользователя.
Вы можете избавиться от перенаправления socat, используя наш код JuicyPotatoNG , и внедрить поддельный Oxid Resolver, как мы это сделали в RemotePotato0 , с дополнительным бонусом: вы также можете управлять SPN и выполнять ретрансляцию Kerberos … но я оставлю это. тебе
Исходный код: https://github.com/decoder-it/ADCSCoercePotato/
Эта возможность ограничена только группой доступа DCOM службы сертификатов , которая заполняется только при запуске службы ADCS. Однако могут существовать устаревшие приложения DCOM, которые предоставляют удаленную активацию каждому.
Представьте себе приложения DCOM, работающие в контексте «Интерактивного пользователя» с удаленной активацией, доступной обычным пользователям. Благодаря реализации кросс-сессии вы также можете получить аутентификацию вошедшего в систему пользователя.
Еще одна веская причина избегать установки ненужных служб на контроллере домена, включая службу ADCS!
Эта группа является встроенной локальной группой безопасности и заполняется специальной группой идентификации NT AUTHORITY\Authenticaterd Users , которая представляет каждую учетную запись пользователя домена, которая может успешно войти в домен, когда сервер берет на себя роль центра сертификации ( CA) путем установки роли служб сертификации Active Directory (ADCS).
«Доступ к DCOM» несколько интригует; это вызывает потенциальные уязвимости и эксплуатацию
Но давайте начнем с самого начала. Какова цель этой группы? MS говорит: « Членам этой группы разрешено подключаться к центрам сертификации на предприятии ».
Проще говоря, эта группа может регистрировать сертификаты через DCOM. Таким образом, логично, что все прошедшие проверку подлинности пользователи и компьютеры имеют доступ к конкретному приложению.
Каждый раз, когда пользователь или компьютер регистрирует или автоматически регистрирует сертификат, он связывается с интерфейсами DCOM приложения запроса CertSrv , которые предоставляются через протокол MS-WCCE , протокол регистрации сертификатов клиента Windows.
Существует также определенный набор интерфейсов для протокола удаленного администрирования служб сертификации, описанный в MS-CSRA .
Я не буду углубляться в особенности этих интерфейсов. Возможно, есть интересные интерфейсы, которые стоит изучить и использовать, но сейчас мое внимание было сосредоточено на разрешениях активации этого сервера DCOM.
Инструмент DCOMCNFG предоставляет нам много полезной информации.
На уровне компьютера группа доступа DCOM службы сертификатов «ограничена» разрешениями на локальный и удаленный запуск:
Это не означает, что эта группа может активировать все объекты DCOM, мы должны смотреть на конкретное приложение, в нашем случае запрос CertSrv:
Каждый может удаленно активировать этот сервер DCOM. Честно говоря, я ожидал найти здесь группу доступа DCOM службы сертификатов вместо «Все», учитывая, что эта группа ограничена разрешениями на локальный запуск и локальную активацию:
Возможно, также оцениваются какие-то комбинированные разрешения и вложенное членство.
Есть еще один интересный аспект: насколько я заметил, группа доступа к службе сертификатов DCOM является одной из немногих групп, наряду с пользователями распределенного COM и пользователями журнала производительности , которым предоставлены разрешения на удаленную активацию .
Давайте также посмотрим на идентичность:
Это приложение DCOM олицетворяет учетную запись SYSTEM, которая нам и нужна, поскольку она представляет собой локальный идентификатор с наивысшим уровнем привилегий.
Итак, у нас есть работающий привилегированный сервер DCOM, который может быть активирован удаленно любым прошедшим проверку подлинности пользователем домена. Кажется, это склонно к нашим любимым *картофельным подвигам, вам не кажется?
Таким образом, большинство этих эксплойтов основаны на злоупотреблении службой активации DCOM, работающей в контексте с высокими привилегиями, путем демаршаллинга объекта IStorage и отражения аутентификации NTLM обратно в локальную конечную точку TCP RPC для достижения локального повышения привилегий.
Существуют также варианты этой атаки, которые включают передачу аутентификации пользователя или компьютера NTLM (и Kerberos) на удаленную конечную точку с использованием таких протоколов, как LDAP, HTTP или SMB, что в конечном итоге позволяет повысить привилегии до администратора домена. И это то, что мы с @splinter_code сделали в нашем RemotePotato0 .
Но этот сценарий отличается: как пользователь домена с низким уровнем привилегий, мы хотим активировать удаленное приложение DCOM, работающее в контексте с высокими привилегиями, и заставить его пройти аутентификацию на удаленном прослушивателе, работающем на нашей машине, чтобы мы могли захватить и передать это аутентификация на другом сервисе.
Мы (надеемся) получим аутентификацию самого удаленного компьютера, когда приложение DCOM работает в контексте системы или сетевой службы.
Звучит здорово! l Итак, какие конкретные шаги нам следует предпринять для реализации этого?
Ну, это гораздо проще, чем я думал изначально
Начиная с оригинального JuicyPotato, я внес некоторые незначительные изменения:
- Настройте перенаправитель (socat) на машине Linux на порту 135, чтобы перенаправить весь трафик на нашей машине злоумышленника на выделенный порт (например: 9999). Вы наверняка знаете, что мы больше не можем указать собственный порт для Oxid Resolution .
- В коде JuicyPotato:
- Инициализируем структуру COSERVERINFO и указываем IP-адрес удаленного сервера, на котором мы хотим активировать объект DCOM (сервер ADCS).
- Инициализируйте COAUTHIDENTITY и заполните атрибуты имени пользователя, пароля и домена.
- Присвойте COAUTHIDENTITY структуре COSERVERINFO.
- В IStorageTrigger::Marshallfinterface укажите IP-адрес перенаправителя.
- В CoGetInstanceFromIStorage() передайте структуру COSERVERINFO:
И да, это сработало.
Сетевой захват показывает, что удаленная активация, запрошенная нашим пользователем с низким уровнем привилегий, прошла успешно:
Последним шагом является перенаправление аутентификации NTLM на внешний ретранслятор, например ntlmrelayx , что позволяет выполнять аутентификацию другой службе, например самому компьютеру CA.
И последнее, но не менее важное: поскольку у нас есть аутентификация клиента RPC, мы должны инкапсулировать и пересылать сообщения аутентификации, используя протокол, уже реализованный и поддерживаемый в ntlmrelayx, например HTTP.
Держу пари, что теперь возникает роковой вопрос:
Хорошо, обычные пользователи домена могут удаленно выполнить аутентификацию сервера ADCS, перехватить сообщения аутентификации и ретранслировать их, но действительно ли это полезно?
Что ж, учитывая существование других непропатченных методов принудительной аутентификации контроллера домена, таких как DFSCoerce , я бы сказал, что его полезность может быть ограничена.
Ситуация еще больше усложняется тем, что единственными протоколами, которые можно ретранслировать из-за недавно введенного MS в DCOM ужесточения безопасности , на данный момент являются HTTP и SMB (если подпись не требуется).
В своей лаборатории я тестировал ретранслятор на конечной точке HTTP /CertSrv веб-сервера регистрации CA, работающего на другом компьютере (догадайтесь, почему?… вы не можете ретранслировать обратно на тот же компьютер по сети). Не имея никаких средств защиты NTLM, я запросил сертификат компьютера для сервера CA.
Схема атаки показана ниже:
С помощью этого сертификата я мог затем войти на сервер ADCS в контексте с высокими привилегиями. Например, я мог бы создать резервную копию закрытого ключа центра сертификации, что в конечном итоге позволит подделывать сертификаты от имени любого пользователя.
POC
Я переписал некоторые части нашего старого JuicyPotato, чтобы адаптировать его к новому сценарию. Это быстрое и грязное решение, хотя и ограниченное, но этого было более чем достаточно для достижения моей цели.
Вы можете избавиться от перенаправления socat, используя наш код JuicyPotatoNG , и внедрить поддельный Oxid Resolver, как мы это сделали в RemotePotato0 , с дополнительным бонусом: вы также можете управлять SPN и выполнять ретрансляцию Kerberos … но я оставлю это. тебе
Исходный код: https://github.com/decoder-it/ADCSCoercePotato/
ВЫВОДЫ
Хотя описанный мною метод принудительной аутентификации, возможно, и не является новаторским, он предлагает интересные альтернативные способы принудительной аутентификации удаленного сервера путем злоупотребления разрешением на удаленную активацию, предоставленным обычным пользователям домена.Эта возможность ограничена только группой доступа DCOM службы сертификатов , которая заполняется только при запуске службы ADCS. Однако могут существовать устаревшие приложения DCOM, которые предоставляют удаленную активацию каждому.
Представьте себе приложения DCOM, работающие в контексте «Интерактивного пользователя» с удаленной активацией, доступной обычным пользователям. Благодаря реализации кросс-сессии вы также можете получить аутентификацию вошедшего в систему пользователя.
Еще одна веская причина избегать установки ненужных служб на контроллере домена, включая службу ADCS!