Безопасность виртуальных системы – сейчас модный тренд, поэтому обойти стороной этот вопрос нельзя. Сегодня мы буде ломать самое сердце инфраструктуры VMware – сервер vCenter. При этом использовать будем 0-day уязвимости, чтобы жизнь медом не казалась. Ломать будем олдскульными методами, никак не связанными с виртуальными технологиями: тренд, конечно, модный, а вот баги все такие же банальные.
PS: Как водится у ответственных уайт-хатов, все описанные тут баги должны быть уже закрыты, были они 0-деями на момент взлома, то есть в 2011 году. Данный текст был опубликован в журнале Хакер № 7/12 (162), а также являлся основой для докладов на CONFidence 2012, PHD 2012 и Defcon 20.
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
Слайд Клаудио с конференции БлэкХат ;-)
Все просто: читаем любые файлы, на которые у учетной записи, из-под которой запущен vCenter, хватает прав. Но вот вопрос, который задал Клаудио – как же файл читать-то? В общем, покопался он в файловой системе и нашел чудесный файл журналирования доступа, в котором хранился код сессии (см. скриншот слайда).
Содержимое злосчастного файла ;-)
Что такое этот код? Дело в том, что vSphere-клиент работает с vCenter по протоколу SOAP, то есть это обычный HTTPS-трафик, в теле которого – XML-структура с данными, командами и т. д. При этом после аутентификации администратора ему прописывается код SOAP-сессии, и впоследствии этот код проверяется как cookie c PHPSESSIONID, типа аналог 8) Очевидно, что, похитив этот код, мы можем подсунуть его в свой SOAP-запрос, и vCenter будет думать, что мы уже аутентифицировались как некий админ (если сессия еще жива). То есть Клаудио предлагает через уязвимость в веб-сервере Jetty прочитать лог с этими SOAP-кодами.
http://target:9084/vci/download/health.xml/%3f/../../../../../../ProgramDataVMwareVMware VirtualCenterLogsvpxd-profiler-6.log
Затем следует подставлять эти коды в запросы от vSphere. Для этого он даже разработал прокси-сервер, который на лету подменяет код сессии в пакетах от vSphere, и включил этот прокси в состав своего add-on’а к Metasploit – VASTO. Кроме того, в этом аддоне есть множество других фишек, но сейчас об этом не будем.
Таким вот образом наш итальянский друг из компании Google предлагает наказывать vCenter. Но беда была в том, что все эти баги к моменту моего пен-теста (весна-лето 2011) устарели: нам пришлось иметь дело с последней версией ПО, а это значит, что и Jetty был патченым-перепатченным.
В одну и ту же воронку снаряд дважды не попадает?
Испытывая разочарование (халявы не получилось), я начал думать, что делать. Вообще любой пен-тестер в такой ситуации просто пройдет мимо и напишет в отчете, что на данном ресурсе уязвимостей нет. Но, как обычно, почувствовав возмущения в Силе, я не доверился этим вашим патчам. Что-то заставило меня продолжить издеваться над Jetty, комбинируя варианты эксплойта для выхода за пределы каталога. И через 15 минут я получил результат. Уже в другом месте того же менеджера обновления опять была уязвимость:
http://target:9084/vci/download/.................FILE.EXT
Это уже что-то, ведь можно идти читать файл с SOAP-кодами!
Попытка найти свое счастье…
Но опять нас ждало разочарование – коды сессий больше в этом чудесном файле не содержатся. Можно только отметить отличную работу программистов из VMware, которые подмели логи и сделали нам бяку. Что ж, поищем сами, что еще может быть на файловой системе, что нам пригодится… Самое первое, что приходит в голову – это выполнить хищение секретного ключа для SSL. Тогда с этим ключом мы можем перехватывать SSL-трафик и расшифровывать его (wireshark позволяет делать это без проблем). Сам ключ можно найти так:
http://target:9084/vci/downloads/...............Documents and SettingsAll UsersApplication DataVMwareVMware VirtualCenterSSLrui.key
Соответственно, если мы организуем атаку «человек посередине» с помощью ARP SPOOFING, то мы сможем перехватывать трафик между сервером и административной рабочей станцией. Кстати, IP-адреса администраторов и их логины по-прежнему можно узнать из файла профайлера. Конечно, мы можем подменить SSL-сертификат (cain умеет делать это без проблем) и расшифровать трафик без хищения ключа, но тогда администратор увидит предупреждение о неверном SSL-сертификате. В случае если мы похитили ключ – администратор ничего не увидит, так как сертификат будет верным. То есть такая атака более хитрая и скрытная…
Предупреждение о поддельном сертифкате!
VMware vCenter Orchestrator
А ведь на сервере с vCenter есть еще одна чудесная вещь, которая идет бесплатным довеском и устанавливается по желанию – это «Оркестратор». Еще один интерфейс управления, в этот раз самим «Центром». Для чего это надо? А это не менее крутая штука. Она используется для управления жизненным циклом ЦОД. Это целый фреймворк для разработки и автоматизации различных процессов в виртуальной инфраструктуре. Короче, это круто и все тут. Изучая файловую систему, я наткнулся на следующий файл:
http://target:9084/vci/download/.................Program filesVMwareInfrastructureOrchestratorconfigurationjettyetcpasswd.properties
Уже кое-что!
Вот именно так мы получаем некий MD5-хэш. Очевидно, что там запрятан пароль от административной учетной записи в этот самый «Оркестратор». Что тут можно сказать? Использование MD5 без соли – это не секурно. Вот и в данном контексте мы очень быстро получили пароль (на скриншоте захешированный пароль по умолчанию, кстати, так что администраторы тоже могут быть причиной проблем). Используя полученный пароль, мы вошли в систему через веб-интерфейс. Удобно, мило, симпатичный дизайн, но нам нужно больше. Поковырявшись в веб-интерфейсе, мы заметили, что для управления виртуальной инфраструктурой используется тот же vCenter Server, а значит, «Оркестратор» должен уметь аутентифицироваться там. И он умеет, ведь где-то в настройках задается пароль доступа.
Настройки доступа к vCenter.
Раскрыв HTML-код, я был счастлив: пароль там отображается в открытом виде, как есть, хотя визуально, в браузере, прячется за «звездочками».
Админская учетка от vCenter наша!
Кроме того, там пароли от почтового аккаунта, от доменных учетных записей и от прочих вещей, которыми «Оркестратор» должен уметь пользоваться. Прямо менеджер паролей для хакера! Понятно, что вся система была успешно взломана, причем не только виртуальная, но и контроллер домена, а значит, все, что там было.
Moarrrrrr!
Казалось бы, все, но есть еще одна деталь. Как вы обратили внимание, «Оркестратор» где-то хранит пароли. Причем так, чтобы их можно было получить в чистом виде и использовать. Это нам говорит о том, что можно было не ломать MD5-хэш, а поискать, где лежат эти паролики. Покопавшись немного, я таки их нашел: так, например, хранится пароль от доступа vCenter:
http://target:9084/vci/download/.................Program FilesVMwareInfrastructureOrchestratorapp-serverservervmoconfpluginsVC.xml
Причем, судя по формату закодированной строки, это шифрование обратимо. Даже похожие пароли выглядят в зашифрованном виде очень похоже.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<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 FilesVMwareInfrastructureOrchestratorapp-serverservervmoconfvmo.propirties. Тут закодирован пароль от СУБД, таким же методом.
Осталось разобрать суть метода кодирования и понять, верна наша догадка или нет. Тут в дело вступает мой друг и коллега, а по совместительству еще и игрок CTF-команды LeetMore – Александр jug Миноженко. Для него такие задачки – как два пальца… Одним своим взглядом он определил, что первые два байта описывают длину всего пароля, а далее идет кодированное представление. Саша просто декомпилировал Java-класс «Оркестратора», отвечающего за сохранение пароля, и разобрал алгоритм кодирования. Суть проста: берем длину пароля, затем кодируем в хекс каждый байт пароля, добавляя к нему номер позиции байта (начиная с нулевого). Таким образом, кодированное значение “Password01.” выглядит как:
000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef
Саша написал декодер (на Руби):
#Закодированная строка
pass = "010506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef"
#Считаем длину
len = (pass[0..2]).to_i # Первые 3 символа длина пароля
enc_pass = pass[3..-1].scan(/.{2}/) # Разбиваем hex-строку на байты
dec_pass = (0...len).collect do |i|
byte = enc_pass[i].to_i(16) # Переводим hex в целое число
byte -= i # вычитаем позицию байта и получаем раскодированное значение
byte.chr
end
#Результат – чистый пароль: “Password01.”
puts "Password: #{dec_pass.join()}"
Таким образом, атака сводится к использованию нашего 0-дэя, на чтение файла, и второго – на раскодирование паролей из считанных файлов. И опять получаем полный доступ к vCenter. За несколько секунд… (готов соответствующий модуль для Metasploit)
Финал
Как видно, 0-дэи бывают простыми и опасными. Что можно сказать еще?.. Если бы администраторы фильтровали доступ с помощью фаервола, ограничив доступ к административным портам, провести атаку было бы намного сложнее. Многое осталось за кадром, ведь защита виртуальной инфраструктуры – дело не одной минуты и не одного сервера. Могу всем посоветовать VMware Hardening Guide (http://www.vmware.com/files/pdf/techpaper/VMW-TWP-vSPHR-SECRTY-HRDNG-USLET-101-WEB-1.pdf). В этой PDF’ке указаны многие места, на которые стоит обратить внимание. На этом все, не болейте!
Автор: d00kie
