10.07.2012

Контроль над облачной инфраструктурой на раз-два-три

image

Исследовательский центр Positive Research проводил анализ безопасности системы Citrix XenServer.

Несколько месяцев назад исследовательский центр Positive Research проводил анализ безопасности системы Citrix XenServer. Помимо прочего, мы изучали безопасность интерфейсов администрирования, и в частности веб-интерфейсов различных компонентов системы. В результате нам удалось обнаружить несколько критических уязвимостей, которые позволяют получить контроль не только над этими компонентами, но и над мастер-сервером, а значит над всей облачной инфраструктурой. О найденных уязвимостях мы незамедлительно сообщили компании Citrix. После того как бреши были закрыты ([1][2],[3]), результаты были представлены на форуме Positive Hack Days в рамках секции FastTrack.

Итак, перейдем к делу.

При анализе в поле нашего внимания попали три компонента Citrix XenServer:

  1. Web Self Service — веб-консоль управления виртуальными машинами;
  2. vSwitch Controller — веб-консоль управления виртуальной сетевой
    инфраструктурой;
  3. License Administration Console — сервис управления лицензиями XenServer.

Тестировалась последняя на момент исследования версия XenServer (6.0.0).

Web Self Service


Этот компонент представляет собой веб-консоль управления виртуальными машинами.
Как и во всех остальных модулях, мы обнаружили «стандартный набор» веб-уязвимостей:
  • межсайтовая подмена запросов (CSRF);
  • межсайтовое выполнение сценариев (stored XSS);
  • злоупотребление перенаправлением URL (URL redirector abuse);
  • расщепление HTTP-ответа (HTTP response splitting).

Все формы приложения были подвержены атаке CSRF, фильтрация многих полей была недостаточна и делала возможными хранимые XSS. Кроме того, на странице входа в систему мы обнаружили очень «полезный» параметр, позволяющий осуществлять злоупотребление перенаправлением URL и расщепление HTTP-ответа. На видео представлено действие автоматизированного эксплойта, который получает cookie
администратора с помощью первых трех уязвимостей, после чего «заметает следы».

  1. Сначала при помощи злоупотребления перенаправлением URL мы направляем администратора на контролируемую нами страницу.
  2. Сценарий на этой странице, используя CSRF, создает новую учетную запись в системе. В поле имени пользователя существует уязвимость stored XSS. С ее помощью мы внедряем полезную JavaScript-нагрузку на страницу со списком пользователей и перенаправляем туда администратора.
  3. Внедренный JavaScript-код отсылает сookie администратора на наш сервер, после чего удаляет только что созданную учетную запись.



vSwitch Controller


Этот компонент был самым интересным. Здесь обнаружились следующие уязвимости:
  • межсайтовая подмена запросов (CSRF);
  • злоупотребление перенаправлением URL;
  • расщепление HTTP-ответа;
  • недостаточная авторизация (Insufficient Authorization).

Веб-интерфейс vSwitch Controller для взаимодействия с сервером использует REST API. Это значит, что в ответ на каждое действие пользователя формируется HTTP-запрос. В зависимости от привилегий пользователю разрешается или не разрешается выполнять соответствующие запросы.

Среди прочего, веб-интерфейс vSwitch controller позволяет администратору создавать полные снимки конфигурации системы. Эти снимки должны быть доступны для скачивания только привилегированным пользователям. Однако, как оказалось, пользователь с правами «только на чтение» тоже может скачать снимок, сформировав вручную запрос к REST API сервиса:

GET /ws.v1/nox/snapshot/<snapshot-uuid>/export

Вместо <snapshot-uuid> подставляется идентификатор снимка, который нужно скачать.
Список всех снимков и их идентификаторов можно получить, отправив запрос:

GET /ws.v1/nox/snapshot/

В снимке содержатся все параметры vSwitch controller, учетные данные пользователей vSwitch Controller (имена и хэши паролей с солью), SSL-сертификат сервера вместе с закрытым ключом и учетные данные привилегированного пользователя мастер-сервера в открытом виде. Используя эти учетные данные, можно подключиться по SSH к основному серверу XenServer и получить контроль над всей инфраструктурой XenServer. После того как такой доступ будет получен, возможности злоумышленника ограничиваются только его собственной фантазией.

Описанную уязвимость саму по себе трудно эксплуатировать, поскольку она требует наличия привилегий пользователя с правами «только на чтение». Однако, здесь на помощь приходит уязвимость CSRF, которая позволяет незаметно для администратора-жертвы создать нужную учетную запись с известным нам паролем (для этого достаточно заставить администратора перейти по фишинговой ссылке).



License Administration Console


Этот компонент предназначен для управления лицензиями и опирается на бесплатный менеджер лицензийlmadmin от компании Flexera Software. Нам удалось обнаружить следующие уязвимости:
  • подмена содержимого (Content Spoofing);
  • межсайтовое выполнение сценариев (stored XSS);
  • межсайтовая подмена запросов (CSRF);
  • отказ в обслуживании (Denial of Service).

Побродив по ссылкам, можно обнаружить, что у главной страницы сайта есть интересный GET-параметр admin, который определяет адрес ссылки, ведущей в административный раздел. Значение фильтруется таким образом, что полноценная XSS-атака невозможна, но «подсунуть» ссылку на произвольный ресурс ничто не помешает. Отказ в обслуживании можно осуществить, отправив один-единственный HTTP-запрос, в
котором один из параметров передается в виде массива, например:

?admin[]=blah

При этом от атакующего не требуется быть авторизованным в системе. Причина — необрабатываемое исключение в случае передачи массива в качестве параметра сценария. Поэтому добиться выполнения произвольного кода, эксплуатируя эту уязвимость, не удалось.

Стоит отметить, что в последней на момент проведения исследования версии lmadmin
этих уязвимостей уже не было.



Подводя итог, можно сделать вывод: не следует игнорировать некритические по степени риска уязвимости. На практике при использовании нескольких простых уязвимостей в совокупности возможно проведение атаки, в результате которой злоумышленник получит полный контроль над системой. Подобные сценарии были успешно реализованы далеко не один раз (в том числе при проведении тестов на проникновение).

Ни один продукт не застрахован от ошибок; уязвимости всегда были и никуда не исчезнут. И хорошо, если производители оперативно реагируют на сообщения об уязвимостях и своевременно выпускают исправления, как это произошло в данном случае, — но, к сожалению, так бывает не всегда.

Впрочем, риски всегда можно минимизировать. Почти все перечисленные бреши можно устранить, если принять дополнительные меры по ограничению доступа к интерфейсам администрирования XenServer. Кроме того, триггером срабатывания многих из этих уязвимостей может являться простейшая CSRF-атака. Как поется в одной известной песне: «Следи за собой, будь осторожен», — особенно когда дело касается подозрительных ссылок.
или введите имя

CAPTCHA