Одна уязвимость — много ревардов

Ошибки настройки DNS топовых веб-проектов

Очень здорово было бы найти какую-то одну уязвимость, которая работала бы на всех веб-проектах сразу. Эдакий крякер интернета icon smile Одна уязвимость — много ревардов . Но сделать это довольно трудно, ведь у проектов разный функционал, написаны они на разных языках, работают под разными платформами. Но есть и много общего между всем вебом — протокол НТТР и механизм DNS. Мы задались целью немного изучить внутреннюю кухню DNS крупнейших веб-ресурсов и нашли у многих из них один очень интересный общий баг, о котором и пойдет речь.

ПОЧЕМУ DNS? Хороший вопрос. Мы выбрали DNS как вектор изучения по многим причинам. Во-первых, DNS был, есть и остается основой методологии обследования периметра при любых аудитах и пентестах. Именно отсюда чаще всего начинается сбор информации. Обратные зоны, резолв, брутфорс по словарю и так далее. Во-вторых, DNS ложится в основу фундамента всей клиентской безопасности веба — Same Origin Policy. Как говорится, Domains, protocols and ports must match.

Так вот именно домен — это DNS. Помимо этого, как ты уже знаешь, SOP есть не только в самих браузерах, но и в плагинах, таких как Java и Flash.

У них свои причуды, и нередко в crossdomain.

xml можно видеть *.domain.com (например, вот: https://www.paypal.com/crossdomain.xml). Наконец, третья причина — это механизм управления cookie. Чаще всего cookie наследуются браузером на все поддомены относительно того домена, с которого они пришли (например, .facebook.

com). Это удобно для настройки сквозной авторизации между своими проектами, но и открывает дополнительные возможности для атак на клиентов при получении доступа к каким-либо из вебресурсов внутри такой вот «доверенной» доменной зоны.

СОБИРАЕМ ИНФОРМАЦИЮ

Правильный дебют — залог успеха. Собрать сведения по всем DNS-именам периметра не так легко, как может показаться. Причина простая: сам периметр по IP-адресам тесно связан с DNS- записями (одно из другого, как правило, и следует). Но точка входа едина — это основной домен.

Берем его и начинаем копать вглубь — брутим поддомены, резолвим обратные зоны. Все как всегда, в общем. Для этих целей пригодится замечательная утилита dnsmap (bit.ly/12E8pXD).

Очень простая в использовании и функциональная штука, к тому же содержащая уже набор слов для перебора доменных имен. Эта программа, к слову, входит в стандартный Backtrack (Kali)

Linux и другие сборки систем для пентестов. В качестве альтернатив можно рекомендовать скрипты bit.ly/1bgv6dP и bit.ly/13lgcda. Но пригодиться они могут, разве что когда нет возможности собрать из сырцов dnsmap.

Только замечание — веб такой веб, что в реальной жизни дедовских (сетевых) методов исследования периметра может и не хватить. Тут надо и crossdomain.xml проглядывать, и по самому веб-ресурсу активно краулерами шариться.

Тот же гугл использует массу не *.google.com доменов для разных целей. Но здесь нам хорошо фартило: некоторые из подопытных целей крупнейших интернет-проектов отдают всю свою зону, так что даже брутить особо-то и не пришлось.

РАЗГРЕБАЕМ РЕЗУЛЬТАТЫ

Итак, долго ли, коротко ли, мы получили списки поддоменов следующих интернет-гигантов:

• att.com

• baidu.com

• ccbill.com

• facebook.com

• google.com

• live.com

• microsoft.com

• nokia.com

• paypal.com

• yahoo.com

• twitter.com

Сразу оговоримся — по понятным причинам списки неполные. Во-первых, брут всегда ограничен словарями. Во-вторых, не все домены вебпроекта, скажем google, покрываются маской

*.google.com (тот же gmail.com, например, чего уж далеко ходить). В-третьих, брутили мы только домены третьего уровня, не залезая ниже. Тем не менее этого списка вполне хватило для статистической выборки и получения интересных результатов.

Мы начали детально смотреть на IP-адреса в А-записях DNS поддоменов и обнаружили странные вещи: многие админы крупнейших компаний держат в публичных DNS IP-адреса внутренних сетей! Удивление не было столь сильным, поскольку в классическом смысле сетевых атак этот факт есть только раскрытие чувствительной информации. Но с точки зрения веба это фатально. Подумай сам — ребята доверили свои домены (поддомены своего проекта, своего детища)

IP-адресам, которые им не принадлежат! Ведь в разных приватных (локальных) сетях будут свои хосты, висящие на тех же адресах, что поддомены этих админов.

Много слов и ничего не понятно? Тогда стоит немного изучить основы работы интернета и IP- протокола. Лучше всего изучить RFC 1918 (tools.

ietf.org/html/rfc1918), но если уж совсем нет времени, то краткое содержание здесь (bit.ly/

YUQGdT). Говоря простым языком, ошибка состоит в самой идее привязывать DNS-имена на адреса внутренних сетей, типа 10.0.0.1, 192.168.0.1,

172.21.0.1 и тому подобные. Почему ошибка?

Как написано выше, таким образом ты отдаешь привилегии своей доменной зоны на IP-адреса, которые тебе не принадлежат. Ведь в других внутренних сетях совсем другие машины будут по тем же адресам!

Вот такие забавные результаты получились у нас для просканированных интернет-гигантов.

Получается 7 из 11, то есть ~63%, — неутешительно. Хотя, скорее всего, именно наши ограничения при сканировании DNS не дали получить оставшиеся 37% результатов.

СТРОИМ ВЕКТОР АТАКИ

Итак, вскрытие показало, что у большинства топовых веб-проектов есть DNS-записи, смотрящие в приватные (локальные) сети. Что нам это дает? Возвращаемся к первому абзацу — с чего мы, собственно, начали смотреть в сторону DNS: cookie и SOP. Отсюда ровно два варианта развития событий. Начнем с кук, так как, скорее всего, покрытие здесь будет больше. Наш вектор атаки мог бы основываться на классическом MITM внутри того же сегмента сети, но тогда все эти трюки с поддоменами выглядели бы очень избыточными — MITM DNS-серверов, и все дела icon smile Одна уязвимость — много ревардов . Профит от такой уязвимости (скорее даже ошибки в настройке DNS) более интересный и дает возможность провернуть все без MITM. Вот сценарий атаки:

1. Атакующий и жертва находятся в одной подсети, с адресацией, совпадающей с той, где расположена уязвимая A-запись DNS целевого ресурса (например, 10/8 для live.com).

2. Атакующий поднимает у себя интерфейс с адресом, соответствующим небезопасной

А-записи (10.245.6.27 для monitoring.live.com).

3. Атакующий передает тем или иным способом жертве ссылку на домен с небезопасной А-записью (здесь все полностью аналогично отраженному вектору атаки XSS или CSRF).

4. Атакующий получает после обработки ссылки в браузере жертвы запрос на свой хост, к которому будут прикреплены все cookie браузера жертвы, распространяемые на все поддомены уязвимого проекта (например, *.live.com).

Это и есть профит icon smile Одна уязвимость — много ревардов .

Очевидно, что в данном случае есть следующие ограничения: cookie с флагом Secure будут передаваться только в том случае, если жертва примет поддельный сертификат атакующего. Что само по себе уже дает возможность делать MITM, и данный вектор становится бесполезным. Таким образом, можем утверждать, что флаг Secure на cookie будет хорошей защитой от этой атаки. А вот флаг httpOnly, напротив, по понятным причинам никакой защиты от такого вектора не представляет. Ведь атакующий работает с куками на сетевом уровне, а не на уровне DOM, где куки защищает флаг httpOnly. Кажется, слишком сложные и большие ограничения для реальной атаки? Мы сначала тоже так подумали icon smile Одна уязвимость — много ревардов .

Но раз уж взяли для примера *.live.com, рассмотрим подробнее, какие же куки в данном случае будут передаваться и как. Нас интересует, например, почта на mail.live.com — почему бы и нет icon smile Одна уязвимость — много ревардов . После авторизации на mail.live.com пользователь получает целый ворох печенья в свой браузер. На разных куках разные флаги и разная привязка к доменам (какие-то привязаны к *.live.

com, какие-то к *.mail.live.com). Проведем простой эксперимент — удалим все куки, которые мы не сможем получить через данный вектор атаки, то есть *.mail.live.com и все с флагом Secure. Затем пробуем обновить страницу… Барабанная дробь — все работает! Остатка кук вполне себе хватает, чтобы ходить с ними на https://mail.

live.com и читать почту. Ирония, не правда ли, что флагом Secure MS, например, защищает mkt, содержащие локаль, наподобие ru-RU, но не защищает сессию…

Вектор атаки номер два носит гордое имя paypal.com, так как именно на этой крупнейшей и безопаснейшей платежной системе можно найти следующий конфигурационный файл SOP для Flash: paypal.com/crossdomain.xml:

<cross-domain-policy>

<allow-access-from domain=”*.

paypal.com”/>

<allow-access-from domain=”*.

ebay.com”/>

<allow-access-from domain=”*.

paypalobjects.com”/>

</cross-domain-policy>

Ребята, вы МОЛОДЦЫ!!! Сценарий атаки такой же, ровно до пункта 4, где злоумышленник не только получает cookie, но и передает в ответ страницу с Flash-роликом, который уже может выполнять междоменные запросы. Браузер жертвы спокойно отдает такому ролику контент любой страницы на paypal.com со всей авторизацией, а дальше ролик может творить с этим контентом уже все что угодно. Например, выслать злоумышленнику. Весело и просто. Если бы не было так печально.

МОРАЛЬ

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

Практически все они на настоящий момент исправлены. За исключением тех примеров, которые были приведены выше, — PayPal и live.com.

Что ж, право вендоров — исправлять данные баги или нет, а наше право как исследователей — сообщить о такой проблеме владельцам других ресурсов. Так или иначе, ревард-программы — это прикольно, многие ответили и даже заплатили, благо покрытие баги получилось очень хорошее. Facebook, к слову, отказался принимать ошибку настройки DNS как уязвимость, так как все куки авторизации у них имеют Secureфлаг, а crossdomain.xml не включает уязвимые домены. Тоже их право — фактически вектора атаки нет, мы полностью согласны. Спрашивать о том, что учитывается в ревардах — атака или уязвимость, смысла нет: хозяин — барин, как говорится.


Скажи спасибо! Кликни на одну из кнопочек ниже:


1