VMware vCenter
Многие корпоративные системы живут в виртуальных средах. Это дешевле и удобнее. И круче! Лидером в области обеспечения этих самых сред является небезызвестная компания VMware. Собственно, эти ребята имеют крутой гипервизор и, что также немаловажно, кучу всякого ПО для удобного развертывания, управления и контроля. Все это делает решения от VMware гибкими, масштабируемыми и в конечном счете эффективными. Для удобного администрирования ребята разработали серверное ПО, в котором консолидируется вся административная часть инфраструктуры, — VMware vCenter. То есть имеется у вас, к примеру, 10 железных машин с VMware ESX(i). На них в общей сложности у вас бегает 50 виртуальных машин. Админить этот виртуальный зоопарк было бы неудобно, если бы не было центральной системы управления vCenter. Помимо прочего, благодаря vCenter возможны разного рода хитрости, вроде прозрачной миграции виртуальных образов в случае отказа одного из ESX работать. Короче, мегаудобная и важная штука. На этом реклама закончена. Основная суть: если хакер взломает vCenter — вся сеть в его руках.
Прорываем оборону
Известный исследователь Клаудио Крисконе не раз сталкивался с «Центром», а потому знает, как его ломать. Вот и я на одном из пентестов столкнулся с этим самым ПО и решил воспользоваться мудростью Клаудио, чтобы запывнить там все. Идея Клаудио была проста: наш друг нашел уязвимость в менеджере обновлений vCenter’а. Уязвимость была даже не по вине программистов VMware. Дело в том, что веб-интерфейс этого менеджера (висит на TCP-порту 9084) использует в качестве веб-сервера Jetty и уязвимость нашлась именно там. Уязвимость классическая — выход за границы каталога:
http://target:9084/vci/download/health.xml/%3f/../../../../../../FILE.EXT
Все просто: читаем любые файлы, на которые у учетной записи хватает прав. Но Клаудио задался вопросом: какой же файл читать? В общем, покопался он в файловой системе и нашел чудесный файл журналирования доступа, в котором хранился код сессии (см. скрин).
Что представляет собой этот код? Дело в том, что vSphere-клиент работает с vCenter по протоколу SOAP, то есть манипулирует обычным HTTPS-трафиком, в теле которого XML-структура с данными, командами и так далее. При этом после аутентификации администратора ему прописывается код SOAP-сессии, и впоследствии этот код проверяется как cookie c PHPSESSIONID, типа аналог :). Очевидно, что, похитив этот код, мы можем подсунуть его в свой SOAP-запрос и vCenter будет думать, что мы уже аутентифицировались как какой-то там админ (если сессия еще жива). То есть Клаудио предлагает через уязвимость в Jetty-веб-сервере прочитать лог с этими SOAP-кодами.
http://target:9084/vci/download/health.xml/%3f/../../../../../../ProgramData\VMware\VMware VirtualCenter\Logs\vpxd-profiler-6.log
Затем подставлять коды в запросы от vSphere. Для этого он даже разработал свой прокси-сервер, который на лету подменяет код сессии в пакетах от vSphere, и включил этот прокси в состав своего add-on’а к Metasploit’у — VASTO. Данный модуль был выпущен в 2010 году и презентован на конференции Black Hat 2010. Несмотря на то что тулза аж двухлетней давности, некоторые ее модули актуальны и работоспособны и сейчас (не говоря уже о том, что далеко не всегда администраторы обновляют свои виртуальные среды, поэтому вполне можно встреть старый vCenter, на котором баги еще не закрыты).
Содержимое злосчастного файла
Таким вот образом наш итальянский друг из компании Google предлагает наказывать vCenter. Но беда в том, что все эти уязвимости к моменту моего пентеста устарели, на тот момент (весна - лето 2011) нам пришлось иметь дело с последней версией ПО, а это значит, что и Jetty был патченным-перепатченным.
Слайд Клаудио с конференции Black Hat ;-)
В одну и ту же воронку снаряд дважды не попадает?
Весьма разочарованный (халявы не получилось), я стал думать, что делать. Вообще, любой пентестер в такой ситуации просто пройдет мимо и напишет в отчете, что на данном ресурсе уязвимостей нет. Но, как обычно, почувствовав возмущения в Силе, я не доверился всем этим патчам. Что-то заставило меня продолжить издеваться над Jetty, комбинируя варианты эксплойта для выхода за пределы каталога. И через 15 минут я получил результат. Уже в другом месте того же менеджера обновления опять была уязвимость:
http://target:9084/vci/download/.\..\..\..\..\..\..\..\..\FILE.EXT
Это уже что-то, ведь опять можно идти читать файл с SOAP-кодами!
Уже кое-что!
Но опять нас ждало разочарование — коды сессий больше в этом чудесном файле не содержатся. Можно только отметить отличную работу программистов из VMware, которые подмели логи и сделали нам бяку. Что ж, поищем сами, что еще в файловой системе может нам пригодиться… Самое первое, что приходит в голову, — это найти и спереть секретный ключ для SSL. С ним мы смогли бы перехватывать SSL-трафик и расшифровывать его (whireshark позволяет делать это без проблем). Сам ключ можно найти так:
http://target:9084/vci/downloads/.\..\..\..\..\..\..\..\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\rui.key
Соответственно, если мы организуем MITM-атаку с помощью ARP-SPOOFING, то мы сможем перехватывать трафик между сервером и административной рабочей станцией. Кстати, IP-адреса администраторов и их логины по-прежнему можно узнать из файла профайлера. Конечно, мы можем подменить SSL-сертификат (cain умеет делать это без проблем), и тогда мы расшифруем трафик без хищения ключа, но в этом случае администратор увидит предупреждение о неверном SSL-сертификате. А если мы похитили ключ — администратор ничего не увидит, поскольку сертификат будет верным. То есть такая атака более хитрая и скрытная.
Попытка найти свое счастье…
VMware vCenter Orchestrator
А ведь на сервере с vCenter есть еще одна чудесная вещь, которая идет бесплатным довеском и устанавливается по желанию, — это «Оркестратор». Еще один интерфейс управления, в этот раз самим «Центром». Это целый «фреймворк» для разработки и автоматизации различных процессов в виртуальной инфраструктуре. Крутая штука. Изучая файловую систему, я наткнулся на следующий файл:
http://target:9084/vci/download/.\..\..\..\..\..\..\..\..\Program files\VMware\Infrastructure\Orchestrator\configuration\jetty\etc\passwd.properties
В нем содержится некий MD5-хеш. Очевидно, что там запрятан пароль от административной учетной записи в этот самый «Оркестратор». Что тут можно сказать? Использовать MD5 без соли — это небезопасно. Вот и сейчас мы очень быстро получили пароль.
Используя полученный пароль, мы вошли в систему через веб-интерфейс «Оркестратора». Удобно, мило, симпатичный дизайн, но нам нужно больше. Поковырявшись, мы заметили, что для управления виртуальной инфраструктурой используется тот же vCenter-сервер, а значит, «Оркестратор» должен уметь в нем аутентифицироваться и в настройках лежит пароль.
HTML-код страницы, где указывается пароль, меня очень порадовал — пароль там отображался в открытом виде, как есть, хотя визуально, в браузере, он прятался за звездочками.
Кроме того, я нашел там пароли от почтового аккаунта, от доменных учетных записей и от прочих вещей, которыми «Оркестратор» должен уметь пользоваться. Прямо менеджер паролей для хакера :). Понятно, что вся система была успешно взломана, причем не только виртуальная, но и контроллер домена, а значит, всё, что там было.
Админская учетка от vCenter наша!
Moarrrrrr!
Казалось бы, всё, но есть еще одна деталь. Ты мог обратить внимание, что «Оркестратор» хранит пароли в открытом виде, а не в виде хеша. Можно поискать, где именно он их хранит на диске. Покопавшись немного, я нашел это место:
http://target:9084/vci/download/.\..\..\..\..\..\..\..\..\Program Files\VMware\Infrastructure\Orchestrator\app-server\server\vmo\conf\plugins\VC.xml
Пароль был все-таки чем-то зашифрован. Однако, судя по формату закодированной строки, это шифрование обратимо. Более того, похожие пароли выглядят в зашифрованном виде очень похоже.
<virtual-infrastructure-hosts>
<virtual-infrastructure-host xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="VirtualCenterHost">
<enabled>true</enabled>
<url>https://new-virtual-center-host:443/sdk</url>
<administrator-username>vmware</administrator-username>
<administrator-password>000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef </administrator-password>
<pattern>%u</pattern>
</virtual-infrastructure-host>
</virtual-infrastructure-hosts>
Еще интересный файл — C:\Program Files\VMware\Infrastructure\Orchestrator\app-server\server\vmo\conf\vmo.propirties. Тут таким же способом закодирован пароль от СУБД. Осталось разобрать суть метода кодирования и понять, верна наша догадка или нет. Тут в дело вступает мой друг и коллега, а по совместительству еще и игрок CTF-команды LeetMore — Александр Миноженко. Для него такие задачки как два пальца… 
С одного взгляда он определил, что первые два байта описывают длину всего пароля, а далее идет кодированное представление. Саша просто декомпилировал Java-класс «Оркестратора», отвечающий за сохранение пароля, и разобрал алгоритм кодирования. Суть проста: берем длину пароля, затем кодируем в хекс каждый байт пароля, добавляя к нему номер позиции байта (начиная с нуля). Таким образом, закодированный «Password01.» выглядит как:
000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef
Саша написал декодер (на Руби):
pass = "000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef"
len = (pass[0..2]).to_i
enc_pass = pass[3..-1].scan(/.{2}/)
dec_pass = (0...len).collect do |i|
byte = enc_pass[i].to_i(16)
byte -= i
byte.chr
end
puts "Password: # {dec_pass.join()}"
Таким образом, атака сводится к использованию нашего 0-дэя для чтения файла и второго — для раскодирования паролей из считанных файлов. И опять получаем полный доступ к vCenter. За несколько секунд, ведь уже готов соответствующий модуль для Metasploit.
Финал
Как видишь, 0-дэи бывают простыми, но очень опасными. Конечно, провести атаку было бы намного сложнее, если бы администраторы фильтровали доступ с помощью файрвола, ограничив доступ к административным портам. Но до этого додумываются далеко не всегда. Защита виртуальной инфраструктуры — дело не одной минуты.
