Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
В этой статье я расскажу, как недостатки конфигурации сервера STUN позволили проникнуть во внутреннюю сеть, обойти средства защиты и проэксплуатировать Log4Shell, как удалось захватить виртуальную инфраструктуру с помощью генерации сессии для SAML-аутентификации, продвинуться по сети и получить доменного администратора с помощью классической техники pass the hash.
Все описанное мы проделали в рамках пентеста крупной ИТ‑компании. Нашей целью было оценить возможность проникновения во внутреннюю сеть из внешней и дать рекомендации, как устранить уязвимости.
Первым делом, как обычно, сканируем открытые сервисы. Сама цепочка эксплуатации началась с веб‑приложения 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-туннеля и воспользоваться напрямую этой виртуальной машиной для доступа ко внутренним ресурсам.
Источник: xakep.ru