Два варианта

vsphere-thinapp1

Но что дальше? Да, мы аутентифицированы. А точнее, аутентифицированы куки, которые нам сервер назначил при подключении. Но мы же не можем выполнять операции! Дальше есть два варианта. Первый — воспользоваться модулем vmware_session_ ridder, который входит в комплект VASTO (vasto.nibblesec.org). Этот модуль — прокси для vSphere Client. Если указать vSphere Client подключиться к этому модулю (он открывает порт), а в качестве входных параметров этому модулю — аутентифицированные куки и адрес vCenter-сервера, то vmware_session_ridder будет проксировать запросы от vSphere Client и подменять на лету значения куки. Таким образом, с его помощью мы сможем получить стандартный доступ к vCenter. Очень круто. Минусы у этого варианта в том, что, во-первых, из-за проксирования vSphere Client работает прилично медленней, а во-вторых, в том, что нельзя полностью автоматизировать процесс (в смысле по-простому нельзя). То есть, поставив «ловушку» первым модулем, мы будем ждать, когда админ на нее зайдет. Но, как только он зайдет и сервер аутентифицирует наши куки, у нас будет не очень много времени (время жизни сессии вроде десять минут), чтобы скопировать их из одного модуля в другой и запустить vSphere Client.
Именно из-за этих минусов я включил в модуль возможность добавлять любого доменного пользователя в админы vCenter. По сути, это один SOAP-запрос с именем юзера, которому надо выставить админские права. После этого можно входить обычным vSphere Client. Конечно, минус тут в том, что надо иметь учетку хотя бы от одного доменного юзера.
Практика. Запускаем NTLM Relay:
1. скинуть VASTO и мой модуль в auxiliary/server/в MSF;
2. useauxitiary/server/vmauth_ntlmrelay;
3. set RHOST 192.168.0.1 ЦР-адрес vCenter);
U. set SRVPORT 80 (порт, на котором будет поднят веб-сервер для запроса NTLM-аутентификации);
5. set URIPATH / (URL, для запроса NTLM-аутентификации);
6. set USERNAMEcorp/hackertHMH пользователя, которому будут — даны права Administrator. Опционально;
7. run.
Ждем админа. Когда все будет успешно сделано, нам отобразятся куки vmware__soap_session, они же SOAPID. Далее:
1. use use auxiliary/server/vmware_session_rider;
2. set RHOST 192.168.0.1 (IPaflpecvCenter);
3. set SRVPORT 9999 (локальный порт, на котором прокси будет ждать подключения vSphere Client);
U. set SOAPID vmware_soap_session (вставляем куки из предыдущего модуля);
5. run;
6. 3anycKaeMvSphereClient;
•xocT:localhost:9999;
•пароль и логин — bypassme.
Стоит отметить, что мой модуль vmauth_ntlmrelay еще нужно подретушировать, хотя функции свои он уже выполняет. К сожалению, не уверен, войдет ли он в официальную поставку MSF, или, как VASTO, надо будет качать ручками. Хотя возможно, он и станет частью VASTO, так как переговоры с Клаудио уже движутся.
Если же говорить об «исправлении» этой баги, то ждать этого нам не приходится. Перед публикацией материала я как раз связался с VMware, но единственное, что они смогли сделать, — развести руками и сказать, что это бага Microsoft и исправить никак не могут. Но пообещали составить список рекомендаций для клиентов банка. Microsoft же исправлять ситуацию точно никак не будет, а будет перетягивать на более совершенные технологии. Однако с учетом обратной совместимости NTLM relay можно будет активно использовать еще лет 10…
Вот и все. Надеюсь, было интересно. Кстати, если хочешь что-нибудь поресерчить или думаешь стать пентестером, но не знаешь как и что — напиши мне, и я постараюсь тебе помочь. Удачи!