HTML5 и новые виды атак


HTML 5 переопределяет основные правила для разработки веб-приложений, обеспечивая богатый набор технических характеристик и расширяя существующие технические особенности и программный интерфейс. Безопасность HTML5 — еще не изученная область, потому что функции стандарта HTML5 пока не были заимствованы существующими веб-приложениями (если не говорить об экспериментальных моделях), и считается, что пока этого не произойдет, пользователям волноваться не о чем.


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

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

  1. Межсайтовый скриптинг с помощью HTML5
  2. Обратный веб-шелл и COR
  3. clickjacking посредством HTML5
    • вставка текстового поля
    • iframe и «песочница»
  4. Отравление кэша в HTML5
  5. Удаленное подключение файлов на стороне клиента
  6. межсайтовая публикация
  7. Разведка сети
    • сканирование портов
    • сканирование сети
    • определение IP-адреса пользователя
  8. Бот-сети на HTML5
    • Создание бот-сети
      • Обращение к жертвам
      • Увеличение длительности выполнения
    • Атаки основанные на бот-сетях
      • DDos-атаки
      • спам на электронную почту
      • распределенные атаки на пароли

Межсайтовый скриптинг с помощью HTML5

В спецификации HTML5 представлены новые элементы, которые содержат атрибуты событий и новые атрибуты событий для существующих тегов. Они могут быть использованы для выполнения JavaScript сценариев, обходя фильтры, основанные на «черных списках».

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

Примеры:

<video onerror=?javascript:alert(1)?><source>
<audio onerror=?javascript:alert(1)?><source>

Фильтры, блокирующие символы «<» и «>» могут предотвратить внедрение тегов в большинстве случаев. XSS еще может быть возможен в тех случаях, если атакующий может внедрить сценарий внутрь существующего атрибута события или же добавить новый атрибут события. Фильтр, который блокирует существующие атрибуты событий, можно обойти с помощью новых атрибутов событий, добавленных в HTML5. Например, «onforminput» и «onformchange».

Примеры:

<form id=test onforminput=alert(1)> <input> <form> <button form=test onformchange=alert(2)>

В HTML5 есть дополнения, которые позволяют автоматизировать выполнение сценария, например атрибут «autofocus». Когда этот атрибут установлен, на элементе автоматически устанавливается фокус.

Также распространены случаи, когда инъекция возможна внутри атрибута тэга «input». В этом случае JavaScript сценарий, как правило, размещается внутри тэга «omnouseover» или «onclick». В этом случае потребуются действия со стороны пользователя для выполнения сценария. В случае HTML5 мы можем внедрить тэг «onfocus» в сценарий и спровоцировать автоматическое выполнение этого сценария путем установки атрибута «autofocus».

Это выглядит следующим образом:
До HTML5:

<input type=?text? value=?-->Injecting here? onmouseover=?alert(?Injected value?)?>

В HTML5:

<input type=?текст? value="-->веб-ижект ? onfocus=?alert(?Injected value?)? autofocus>

Обратный веб-шелл и COR

СOR (cross-origin requests) позволяют браузерам осуществлять кросс-доменные вызовы от a.com до b.com и считывать ответы в зависимости от того, как долго сервер b.com это позволяет делать. Этот функционал может использоваться для туннелирования HTTP трафика посредством кросс-доменных Ajax вызовов и создания эквивалента обратного шелла средствами браузера. Таким образом, нападающий может перехватить сессию пользователя, используя межсайтовый скриптинг, даже если используются механизмы для защиты сессий, например, Http?Only куки и привязка идентификатора сесии к IP адресу.

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

В прошлом году автор этого пособия выпустил утилиту с открытым кодом «Shell of the Future», в которой реализована эта идея. Утилита предельно проста в использовании, поскольку полностью автоматизирует атаку и поставляется с двумя JavaScript пейлоадами.

Вставка текстового поля

ClickJacking, или «угон кликов» применяется для того чтобы обойти защиту от подмены HTTP-запросов (CSRF, cross site request forgery). Очень просто щелкнуть по ссылке или кнопке через clickjacking, гораздо сложнее заполнить поле ввода или атрибут формы. С помощью представленного в HTML5 “Drag and Drop” API можно очень просто заполнить поля форм, заставив жертву выполнить перетаскивание объекта с помощью мыши. Атакующий сайт может быть замаскирован под обычную игру, в которой пользователь должен взять и перетащить с помощью мыши некий нарисованный объект. В это время атакующий начинает заполнять атрибуты формы и поля ввода.

Например:

<div draggable=?true? ondragstart=?event.dataTransfer.setData (?text/plain?, ?Evil data?)?>

<h3>DRAG ME!!</h3>

</div>

Данный метод был разработан Полом Стоуном (Paul Stone) в 2010 году.

Iframe и песочница

Существует всеобщее заблуждение, что использование кода Framebusting на каждой странице сайта защитит его от clickjacking. Подобный метод, к сожалению, имеет множество недостатков. Если Framebusting — это единственная защита против таких атак, то его можно обойти различными способами. Например, используя атрибут «sandbox» тега iframe, который является частью стандарта HTML5.

Пример:

<iframe src=?http://www.victim.site? sandbox></iframe>

Установка этого атрибута отключает сценарий JavaScript в пределах тега <iframe>. Поскольку защита «framebusting» основывается на JavaScript сценарии, то защита будет полностью нейтрализована. Популярные сайты, такие как eBay, WordPress, PayPal полагаются только на «framebusting», и поэтому подвержены подобным атакам.

Отравление кэша

HTML5 представляет новый тип кэширования системы, который называется «программным кэшем» (Application Cache). Если обычное кэширование предназначено для того, чтобы ускорить загрузку страницы, то программный кэш разработан для возможности работы в интернете в offline режиме.

Отравляя HTML5 кэш, злоумышленник может на более длительный период времени сохранить данные в кэше страниц и использовать их для хищения учетных данных пользователей.

Ранее в этом году автором была представлена версия программы Imposter, которая может использоваться для отравления кэша в HTML5.

Удаленное подключение файлов на стороне клиента

Веб-сайты, которые осуществляют Ajax-запросы к URL-адресам, хранящимся в свойстве location hash, и включают ответ в HTML код страницы, могут быть атакованы с помощью COR. После того как пользователь нажал на ссылку, которая содержит в свойстве location hash адрес, контролируемый злоумышленником, существует возможность произвести удаленное подключение файлов на стороне клиента и произвести XSS нападение. Этот способ атаки был обнаружен Мэтом Аустином в июле прошлого года. mobile.facebook.com и многие другие сайты, использующие библиотеку JQuery, оказались уязвимыми к этой атаке.

Межсайтовая публикация

Это разновидность удаленного подключения сценария на стороне клиента, описанная ранее. Если URL для Ajax-запроса может контролировать атакующая сторона, как в случае с location hash, злоумышленник может перенаправить запросы на свой сайт и похитить важную информацию о сессии пользователя. Даже если ответ на Ajax-запрос не обработывается запрашивающим сайтом, эта атака все равно будет работать.

Разведка сети

Кросс-доменные XMLHttpRequest и WebSocket запросы могут использоваться для осуществления надежного сканирования портов. Последние версии Firefox, Chrome и Safari поддерживают эти функции, а значит могут быть использованы для разведывания внутренней сети.

Кросс-доменнный XHR имеет 5 возможных статусов состояний, а у WebSocke есть 4 возможных статуса состояния. Когда осуществляется новое подключение к произвольной службе, значение свойства readystate изменяется согласно статусу подключения. Этот переход между различными состояниями может быть использован для того, чтобы определить, в каком статусе находится удаленный порт: открыт, закрыт или заблокирован.

Сканирование портов

Когда осуществляется подключение через WebSocket или COR к указанному порту IP адреса во внутренней сети, начальное состояние readystate для WebSocket равно 0, для COR - 1. В зависимости от состояния удаленного порта эти значения рано или поздно изменятся.

Данная таблица показывает соотношение между состоянием удаленного порта и продолжительностью статуса readystate. Наблюдая, как быстро может измениться значение readystate, мы можем идентифицировать состояние удаленного порта.

Статус порта

Веб-сокет (readystate0)

COR (readystate1)

Открыт

<100мс

<100мс

Закрыт

~1000мс

~1000мс

Заблокирован

>30000мс

>30000мс

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

Существует 4 типа ответов, которые мы можем получить от приложений:

  1. Закрытие при подключении. Приложение завершает соединение из-за несоответствия протокола сразу, как только соединение будет установлено.
  2. Ответ и закрытие при подключении. Похоже на 1 тип, но прежде чем соединение будет закрыто, приложение отправит стандартный ответ.
  3. Открытие без ответа. Приложение сохраняет соединение и ожижает большого количества данных или данных, которые бы соответствовали особенностям протокола.
  4. Открытие с ответом. Похоже на 3 тип, но приложение посылает некоторый ответ по умолчанию в виде заголовка и приветственного сообщения.


Поведение WebSocket и COR для каждого из этих типов показано в следующей таблице.

Тип приложения

WebSocket (readystate 0)/COR (readystate 1)

Закрытие при подключении

<100 мс

Ответ и закрытие при подключении

<100 мс

Открытие без ответа

<30000 мс

Открытие с ответом

<100 мс (для Firefox и Safari) и 30000 мс (для Chrome)

Сканирование сети

Техника сканирования портов может быть применена для горизонтального сканирования внутренних сетей. Так как открытые и закрытые порты могут быть точно идентифицированы, горизонтальное сканирование может быть произведено для портов, таких как 3389, доступ к которым в большинстве случаев разрешен в настройках межсетевых экранов в корпоративных системах.

Определение открытого или закрытого порта позволяет определить, является ли система с этим IP адресом подключенной к сети.

Определение пользовательского IP- адреса

Большинству домашних пользователей, подключенных к Wi-Fi машрутизаторам, выдается IP адрес в пределах 192.168.x.x. IP адрес Wi-Fi маршрутизатора в большинстве случаев равен 192.168.x.1 и его административный интерфейс работает на 80 или 443 порту. С помощью этих данных мы может определить локальный IP адрес пользователя за два шага:

Шаг 1. Определяем пользовательскую подсеть

Мы можем это сделать, сканируя порт 80 и/или 443 на IP-адресах от 192.168.0.1 до 192.168.255.1. Если пользователь находится в подсети 192.168.3.x, мы получим ответ от 192.168.3.1, который и будет его маршрутизатором, и значит, его подсеть идентифицирована.

Шаг 2. Определяем IP- адрес

После того как мы идентифицировали подсеть, мы сканируем ее для того чтобы найти порт, который фильтруется межсетевым экраном. Например, TCP порт 30000. Мы делаем итерацию от адреса 192.168.x.2 до 192.168.x.254. Когда мы найдем нужный IP-адрес пользователя, мы получим ответ («открыт» / «закрыт»), потому что запрос сгенерирован браузером пользователя, внутри его собственной системы, а значит, он не может быть заблокирован его же брандмауэром.

Бот-сети

Каждый раз, когда пользователь нажимает на ссылку, он позволяет удаленному веб-сайту выполнить JavaScript сценарий на своей машине. Многие пользователи открывают множество вкладок в браузере, и большинство из них остаются открытыми на протяжении всего сеанса, который может длиться несколько часов. Это позволяет любому внешнему объекту использовать вычислительную мощность компьютера пользователя для своих злонамеренных целей. Например, на таких сайтах, как Twitter, спамеры могут за очень короткий промежуток времени заставить тысячи пользователей нажать на специально сформированные ссылки. Но JavaScript сценарии являются слишком «тяжелыми» для системы и ограничены песочницей браузера, что не позволяет их активное использование. В HTML5 был представлен WebWorker – потоковая модель для JavaScript. Это позволяет любому сайту запускать в фоновом режиме JavaScript сценарии без ведома пользователей и никак не влияя на работу браузера.

Создание бот-сетей:

Бот-сеть в HTML5 содержит тысячи систем, на которых в браузере открыта вредоносная страница.
Существует две стадии создания подобной бот-сетей:

  1. достижение компьютера «жертвы»
  2. расширение времени функционирования

Достижение компьютера «жертвы»

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

  1. спам на электронную почту
  2. актуальные темы в Twitter
  3. хранимый XSS на популярных веб-сайтах и форумах
  4. «отравление» поисковой системы
  5. взломанные сайты

Эти методы используются создателями вредоносного программного обеспечения для атаки на своих «жертв». В то время как обычный веб-сайт с вредоносным программным обеспечением может быть легко вычислен с помощью автоматизированных поисковых роботов, то такие сайты, основанные на HTML5, вероятно будут вычисляться гораздо реже.

Расширение времени функционирования

После того как пользователь посетил контролируемую злоумышлениками страницу, нужно, чтобы эта страница осталась открыта в браузере пользователя как можно дольше. Это делается с помощью приемов clickjacling и tabnabbing. Загруженная в браузер страница содержит невидимую ссылку с установленным атрибутом «_blank». Она всегда помещается под указателем мыши, используя обработчик событий «document.onmousmove». Таким образом, когда пользователь щелкает на странице, открывается новая вкладка и отвлекает его внимание. Если у пользователя открыто множество вкладок, то повышается вероятность, что пользователь не закроет эту страницу. Tabanabbing может быть использован для того, чтобы после того как пользователь покинет страницу, обновить ее (а точннее ее flavicon, значок на вкладке этой страницы) и замаскировать под какой-нибудь популярный ресурс, например YouTube, Google или Facebook для того, чтобы пользователь оставил ее открытой.

Атаки, основанные на бот-нетах:

Следующие атаки могут быть осуществлены с использованием HTML5 бот-нетов:

  1. DDoS-атаки уровня приложений
  2. Спам на электронную почту
  3. Распределенный взлом паролей

DDoS-атаки

DDoS-атаки уровня приложений на сайты стали все более распространенными, даже для таких сайтов, как Twitter. Обычно, атаки используют большое число HTTP запросов на специальные разделы сайта, которые могут наиболее интенсивно использовать ресурсы сервера. Потоки JavaScript, запущеные в фоновом режиме с использованием WebWorker, создают кросс-доменные XMLHttpRequest запросы даже тогда, когда сайт их не поддерживает. Система защиты против COR срабатывает только во время ответа на запросы. Но в любом случае будет большая нагрузка на сервер. Такой простой запрос, как http://www.target.site/search_product.php?product_id=% если он создается большое число раз, способен создать проблемы в работе сервера.

Браузер может отправить большое число GET запросов к удаленному веб-сайту, используя COR от WebWorker. Во время тестирования было выяснено, что около 10 000 запросов в минуту могут быть отправлены из одного браузера. Даже используя небольшую бот-сеть из 600 “зомбированных” компьютеров, мы можем отправить 100 000 запросов в секунду на одну страницу, и этого будет вполне достаточно, чтобы обвалить сайт.

Спам в электронной почте

Спам-рассылки осуществляются с помощью почтовых серверов, на которых не ограничена отправка почтовых сообщений (open relay) и с помощью «зомбированных» компьютеров. Такие спам-рассылки можно делать, используя веб-эквиваленты открытых почтовых сервисов. У многих веб-сайтов есть разделы обратной связи, в которых пользователи должны указать их имя и электронный адрес. После того, как эти данные введены, сервер может их обработать и отправить на сервер внутренней почты. Плохо разработанные веб-сайты могут содержать адреса отправителя и адреса назначения письма в скрытых формах браузера, что позволяет отправлять письма с поддельными адресами, если почтовый сервер компании может работать в режиме открытого ретранслятора. Поскольку только GET запросы могут быть отправлены через COR, формы обратной связи должны передавать данные в адресной строке либо при обработке не должно быть разграничение между данными в адресной строке и параметрам POST запроса. Также, если используется jsp страница, злоумышленник может воспользоваться приемом HTTP Parameter Pollution для отправки формы методом GET.

Распределенные атаки на пароли

Взлом паролей всегда был задачей для программ, написанных на низкоуровневых языках с ASM вставками для оптимизации производительности. JavaScript никогда не рассматривали для решения задач, требующих наличия больших вычислительных ресурсов. Времена изменились, и некоторые функции программ, написанных на javascript стали выполняться быстрее. Концепция WebWorker позволяет создать фоновые потоки для взлома пароля. Тесты показали значение уровня подбора пароля в 100 000 MD5 хешей в секунду.

Стоит отметить, что данное значение еще не столь велико. На программах, написанных на низкоуровневых языках, оно достигает нескольких миллионов. Тем самым программы на javascript работают в 100-115 раз медленнее. Это значит, что 100 компьютеров, взламывающих пароль на javascript равноценны одному компьютеру с обычным приложением.
С помощью описанных выше механизмов будет несложно создать бот-нет, состоящий из нескольких тысяч компьютеров, выполняющий взлом пароля с помощью JavaScript в фоновом режиме. Даже с 1000 «зомби», код будет эквивалентен 10 обычным компьютерам. Эффективный бот-нет из нескольких сотен тысяч «зомби» предоставит огромные вычислительные ресурсы для взлома хешей паролей.

Ravan

Ravan — это основанный на javascript взломщик паролей, который использует WebWorker для взлома паролей в фоновом режиме. В текущей реализации осуществлена поддержка MD5 и SHA хешей, сгенерированных с salt. Он взламывает пароли полным перебором. Сначала он проверяет наиболее вероятные комбинации, а остальные — ближе к завершению работы. Несмотря на то, что простой MD-5 и SHA-1 хеш может быть быстро взломан с помощью Rainbow таблиц, взломать более устойчивые salt-хэши можно только полным перебором.

Ravan — это утилита, которая состоит из трех компонентов:

  • «Хозяин». Браузер, который отправляет хеши.
  • «Рабочий». Браузер, который осуществляет взлом.
  • «Веб интерфейс». Средство, которое проксирует сообщения между «хозяином» и «рабочим».

Когда «хозяин» отправляет хеш для взлома в веб-интерфейсRavan генерирует уникальный идентификатор хеша вместе с URL, который содержит этот ID . Этот URL должен быть отправлен всем «рабочим», которые и будут выполнять фактическое взламывание с помощью своих браузеров. Процесс взлома разбивается на мелкие блоки. Каждый блок или слот соответствует 20 миллионам комбинаций.

Когда присоединяются новые «рабочие», им выделяются новые участки работы. Процесс координации слотов среди рабочих и контроля над процессом взлома осуществляется из браузера «хозяина».

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

Просмотров: 4245 | Дата публикации: 14.03.2013



Похожие записи