В этой статье я расскажу, как недостатки конфигурации сервера STUN позволили проникнуть во внутреннюю сеть, обойти средства защиты и проэксплуатировать Log4Shell, как удалось захватить виртуальную инфраструктуру с помощью генерации сессии для SAML-аутентификации, продвинуться по сети и получить доменного администратора с помощью классической техники pass the hash.
Все описанное мы проделали в рамках пентеста крупной ИТ‑компании. Нашей целью было оценить возможность проникновения во внутреннюю сеть из внешней и дать рекомендации, как устранить уязвимости.
Сервис позволяет подключиться к мероприятию по цифровому идентификатору. Путем перебора ID мероприятия мы получили доступ к тестовой комнате 3333. После этого приложение получает учетные данные STUN (логин — ivcs, пароль — ivcs) и подключается к серверу STUN.
Протокол STUN позволяет устанавливать соединение между двумя узлами, находящимися за NAT, и активно используется при установлении соединений в WebRTC. На этом этапе также можно получить внутреннюю адресацию через прослушивание STUN-трафика в Wireshark.
В нашем случае сервер не проверяет, что адрес, по которому нужно подключиться, находится в локальной сети. Таким образом злоумышленник может получить доступ ко внутренним ресурсам, например используя утилиту Stunner.
Если ты обнаружил неправильно сконфигурированный STUN-сервер, Stunner поможет построить SOCKS-прокси, который перенаправляет весь трафик через протокол TURN во внутреннюю сеть.
Для этого нужно просто выполнить команду
Таким образом удается получить доступ к внутренней сети 10.1.1.0/24.
Воспользовавшись новыми знаниями, мы подключились к LDAP, где нас ждал еще один пароль (причем в открытом виде) в поле description.
Учетная запись из LDAP оказалась действительной, и мы получили административный доступ к серверу А. Кроме того, по адресу vcenter.company.local найден сервер vCenter, содержащий уязвимость Log4Shell. Она‑то и даст нам возможность выполнять код на сервере.
Для эксплуатации необходимо, чтобы целевой сервер не имел доступа к интернету и подключался к внешнему LDAP. Поэтому для эксплуатации используем полученный ранее сервер А.
Для генерации сессии через SAML-аутентификацию можно воспользоваться утилитой vcenter_saml_login:
С полученной сессией нам удалось проникнуть на vCenter и захватить контроль над виртуальной инфраструктурой.
Внутри vCenter мы нашли виртуальную машину express c пройденной аутентификацией и доступом в интернет.
Теперь можно отказаться от STUN-туннеля и воспользоваться напрямую этой виртуальной машиной для доступа ко внутренним ресурсам.
Далее мы нашли уязвимый к Log4Shell сервер VMware Horizon на внешнем периметре. На этом сервере тоже не было доступа в интернет, и для эксплуатации было необходимо подключение к внешнему серверу LDAP. Выяснилось, что в сети используется СЗИ, которое обнаруживает попытку эксплуатации и обрывает соединение до LDAP-сервера. Со временем стало понятно, что СЗИ детектирует лишь значение java.lang.Runtime.getRuntime, поэтому мы обфусцировали полезную нагрузку, а для эксплуатации использовали сервер express.
На сервере VMware Horizon была возможность перехватывать пароли пользователей в открытом виде, прослушивая порт 8009 (Connection Server — AJP13):
Дальше мы изучили права учетной записи USER1@internal.RU и обнаружили, что пользователь состоит в группе. Предположим, она называется SUPPORT ENGINEERS@internal.RU. У нее есть право ReadLAPSPassword, позволяющее получить информацию о паролях локального администратора на компьютерах пользователей.
На компьютере
Используя полученные права локального администратора, мы сделали дамп памяти процесса lsass на компьютере zz, в результате чего удалось получить пароль администратора домена в открытом виде с помощью утилит procdump и mimikatz.
Затем мы аутентифицировались на доменном контроллере DC01 с правами доменного администратора, пользователь pentester был добавлен в группу Domain Admins для подтверждения целей тестирования.
Во внутренней сети защитные средства тоже блокировали вредоносный трафик, но, обойдя СЗИ и проэксплуатировав Log4Shell, мы получили доступ к гипервизору и захватили виртуальную инфраструктуру, сделали дамп памяти, получили доменную учетную запись, повысили свои привилегии и стали администратором домена.
Можно сделать вывод, что уровень злоумышленника, необходимый для захвата ИТ‑инфраструктуры, должен быть достаточно высоким. Заказчик увидел пробелы в своем процессе патч‑менеджмента и промашки администраторов — они хранили пароли в открытом виде и использовали одинаковые пароли на разных сервисах.
Чтобы повысить защищенность и не допустить подобной атаки, мы рекомендуем следующие шаги.
автор Александр Герасимов aka @a-gerasimov
Все описанное мы проделали в рамках пентеста крупной ИТ‑компании. Нашей целью было оценить возможность проникновения во внутреннюю сеть из внешней и дать рекомендации, как устранить уязвимости.
РАЗВЕДКА
Первым делом, как обычно, сканируем открытые сервисы. Сама цепочка эксплуатации началась с веб‑приложения IvaConnect — платформы для видео‑конференц‑связи.
Сервис позволяет подключиться к мероприятию по цифровому идентификатору. Путем перебора ID мероприятия мы получили доступ к тестовой комнате 3333. После этого приложение получает учетные данные STUN (логин — ivcs, пароль — ivcs) и подключается к серверу STUN.
Протокол STUN позволяет устанавливать соединение между двумя узлами, находящимися за NAT, и активно используется при установлении соединений в WebRTC. На этом этапе также можно получить внутреннюю адресацию через прослушивание STUN-трафика в Wireshark.
В нашем случае сервер не проверяет, что адрес, по которому нужно подключиться, находится в локальной сети. Таким образом злоумышленник может получить доступ ко внутренним ресурсам, например используя утилиту Stunner.
Если ты обнаружил неправильно сконфигурированный STUN-сервер, Stunner поможет построить SOCKS-прокси, который перенаправляет весь трафик через протокол TURN во внутреннюю сеть.
Для этого нужно просто выполнить команду
Код:
./stunner socks -s [IP]:[PORT] -u [USER] -p [PASSWORD]Таким образом удается получить доступ к внутренней сети 10.1.1.0/24.
ПЕРВОНАЧАЛЬНЫЙ ДОСТУП
Во время анализа внутренней сети мы обнаружили сервер PostgreSQL, использующий такие же учетные данные, как и сервер STUN. Внутри базы мы нашли таблицу videoconference.lpad, в которой была запись для подключения к серверу LDAP.
Воспользовавшись новыми знаниями, мы подключились к LDAP, где нас ждал еще один пароль (причем в открытом виде) в поле description.
Учетная запись из LDAP оказалась действительной, и мы получили административный доступ к серверу А. Кроме того, по адресу vcenter.company.local найден сервер vCenter, содержащий уязвимость Log4Shell. Она‑то и даст нам возможность выполнять код на сервере.
Для эксплуатации необходимо, чтобы целевой сервер не имел доступа к интернету и подключался к внешнему LDAP. Поэтому для эксплуатации используем полученный ранее сервер А.
ЗАКРЕПЛЕНИЕ В СИСТЕМЕ
В файловой системе сервера vCenter можно найти файл data.mdb, он содержит в себе сертификаты, которые используются для подписи запросов при SAML-аутентификации любого пользователя, включая администратора.Для генерации сессии через SAML-аутентификацию можно воспользоваться утилитой vcenter_saml_login:
Код:
python3 vcenter_saml_login.py -p [PATH TO MDB] -t [HOST]С полученной сессией нам удалось проникнуть на vCenter и захватить контроль над виртуальной инфраструктурой.
Внутри vCenter мы нашли виртуальную машину express c пройденной аутентификацией и доступом в интернет.
Теперь можно отказаться от STUN-туннеля и воспользоваться напрямую этой виртуальной машиной для доступа ко внутренним ресурсам.
Далее мы нашли уязвимый к Log4Shell сервер VMware Horizon на внешнем периметре. На этом сервере тоже не было доступа в интернет, и для эксплуатации было необходимо подключение к внешнему серверу LDAP. Выяснилось, что в сети используется СЗИ, которое обнаруживает попытку эксплуатации и обрывает соединение до LDAP-сервера. Со временем стало понятно, что СЗИ детектирует лишь значение java.lang.Runtime.getRuntime, поэтому мы обфусцировали полезную нагрузку, а для эксплуатации использовали сервер express.
На сервере VMware Horizon была возможность перехватывать пароли пользователей в открытом виде, прослушивая порт 8009 (Connection Server — AJP13):
Код:
tcpdump -X -s 0 'tcp port 8009 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)ПРОДВИЖЕНИЕ ПО СЕТИ
С сервера horizon.company.ru мы произвели опрос доменного контроллера и получили информацию о пользователях, компьютерах, сессиях. Затем через procdump сделали дамп памяти процесса lsass, содержащего NTLM-хеши учетной записи инженера поддержки, назовем его USER1@internal.RU.
Дальше мы изучили права учетной записи USER1@internal.RU и обнаружили, что пользователь состоит в группе. Предположим, она называется SUPPORT ENGINEERS@internal.RU. У нее есть право ReadLAPSPassword, позволяющее получить информацию о паролях локального администратора на компьютерах пользователей.
ПОВЫШЕНИЕ ПРИВИЛЕГИЙ
Первом делом мы использовали технику pass the hash и запросили данные у контроллера домена. Техника, если ты не в курсе, заключается в том, что можно использовать NT-хеш вместо пароля, чтобы пройти аутентификацию.
На компьютере
NSurname.internal.RU обнаружилась установленная сессия администратора домена ADMINISTRATOR@internal.RU.
Используя полученные права локального администратора, мы сделали дамп памяти процесса lsass на компьютере zz, в результате чего удалось получить пароль администратора домена в открытом виде с помощью утилит procdump и mimikatz.
Затем мы аутентифицировались на доменном контроллере DC01 с правами доменного администратора, пользователь pentester был добавлен в группу Domain Admins для подтверждения целей тестирования.
ВЫВОДЫ И РЕКОМЕНДАЦИИ
Резюмируя, можно сказать, что на внешней инфраструктуре отсутствовали уязвимости, а средства защиты блокировали все векторы атак. Но некорректно сконфигурированный сервер STUN все‑таки позволил попасть во внутреннюю сеть.Во внутренней сети защитные средства тоже блокировали вредоносный трафик, но, обойдя СЗИ и проэксплуатировав Log4Shell, мы получили доступ к гипервизору и захватили виртуальную инфраструктуру, сделали дамп памяти, получили доменную учетную запись, повысили свои привилегии и стали администратором домена.
Можно сделать вывод, что уровень злоумышленника, необходимый для захвата ИТ‑инфраструктуры, должен быть достаточно высоким. Заказчик увидел пробелы в своем процессе патч‑менеджмента и промашки администраторов — они хранили пароли в открытом виде и использовали одинаковые пароли на разных сервисах.
Чтобы повысить защищенность и не допустить подобной атаки, мы рекомендуем следующие шаги.
- Необходимо настроить STUN-сервер таким образом, чтобы он отклонял запросы на подключение к зарезервированным диапазонам IP-адресов.
- Регулярно обновлять программное обеспечение.
- Внедрить парольную политику и не допускать хранения паролей в открытом виде.
- Внедрить защиту конечных устройств на серверы.
автор Александр Герасимов aka @a-gerasimov