# DNS Rebinding ## Теоретический минимум - что такое DNS :::info DNS - Domain Name System - система доменных имён. ::: Для простоты понимания её можно представить как табличку типа доменное имя - IP адрес. Что-то вроде: | Доменное имя | IP адрес | | -------- | -------- | | google.com | 8.8.8.8 | | ... | ... | ### Зачем нужна эта табличка? **Житейская аналогия** Когда мы хотим посмотреть страничку в сети Интернет, мы вводим её адрес в браузере и получаем желаемое. Вроде всё просто, но... Если вам сказать, что вам надо пойти в незнакомом городе на улицу с красными цветами на клумбе, вы её найдёте? Вряд ли. А если вам указать конкретный адрес (ул. Цветочная, д.7)? Тут уже более вероятно. Но если один раз вам скажут, что именно по этому адресу растут красные цветы на клумбе, то в следующий вы уже сразу поймёте, где это находится. Вот доменное имя сайта для вашего компьютера - это какое-то странное описание, а IP-адрес - это вполне конкретные координаты. И если в реальной жизни вы в случае чего будете спрашивать всех прохожих где же там та клумба, чтобы получить адрес, то компьютеру с этим проще - он просто идёт к DNS серверу и просит его подсказать, где конкретно находится вот этот странный адрес из строки. И после получения ответа компьютер точно так же запомнит куда в прошлый раз ходил (да-да, в локальной памяти есть своя небольшая DNS табличка). **Теперь немного более техническим языком.** Когда мы вводим адрес сайта в браузере, компьютер начинает искать соответствующий ему IP адрес в локальной памяти компьютера. Если не находит, то посылает DNS Query уже DNS-серверу. После получения ответа компьютер сохраняет его в свою табличку (чтобы не запрашивать повторно при, например, перезагрузке страницы) и отправляет пакеты уже по конкретному ip-адресу. Этот ip-адрес - это либо адрес сервера, на котором физически висит этот сайт, либо адрес прокси, через который можно получить к нему доступ. Но конечно же пользователь этого всего не видит :) ### Как происходит поиск по протоколу DNS Как уже было сказано, во время поиска по протоколу DNS всё начинается с локальной памяти компьютера (а чего далеко ходить). Если там нет, то тогда мы уж обращаемся к локальному DNS-серверу. Но как может быть понятно, он тоже не может хранить все в мире адреса. Тогда что делать? Тогда в работу включается длинная цепочка. Локальный сервер, если сам не имеет нужной записи в табличке, перенаправляет нас к корневому серверу. Корневой сервер в свою очередь смотрит на искомый нами адрес и перенаправляет нас к DNS серверу той зоны (.ru, .com, ...), которая ему соответствует. И таким образом по цепочке мы спускаемся до того локального DNS сервера, который обслуживает домен, который мы ищем. ![](https://hackmd.io/_uploads/S1sMcTvp2.png) А тут очень наглядно показано как собирается эта цепочка: ![](https://hackmd.io/_uploads/HJESJ0D62.png) ## Просто о сложном - суть атаки ### Дано: Итак, представим следующую картину, в которой есть три важных составляющих: 1) Уязвимый сервис (example.com). Предположим, что наш уязвимый сервис виден из внешней сети, но даёт доступ к какому-то функционалу только при попытке доступа из ограниченного сегмента сети (например, с него самого). 2) Локальный DNS-сервер (attacker.dns), который подконтролен злоумышленнику и обслуживает ресурс evil.service.com. 3) Собственно, ресурс нашего злоумышленника - evil.service.com. Локальный DNS-сервер и ресурс злоумышленника висят во внешней сети относительно нашего уязвимого сервиса. ### Что же происходит? **1. Злоумышленник заманивает жертву на свой ресурс.** В этот момент устройство посылает DNS Query, который доходит до локального DNS-сервера злоумышленника (attacker.dns) и получает в ответ реальный внешний IP-адрес ресурса (evil.service.com). Но у полученного ответа есть одно важное свойство - TTL (Time To Live или время жизни). Оно выставлено очень коротким, благодаря чему ответ не будет кешироваться, а значит при следующем обращении к ресурсу по доменному имени устройство жертвы будет вынуждено снова обратиться к локальному DNS серверу злоумышленника, чтобы узнать ip-адрес. **2. Браузер жертвы загружает страницу ресурса, а вместе с ней вредоносный JavaScript код ресурса, который начинает выполняться.** Этот код при выполнении обязательно обратится к ресурсу evil.service.com (потому что именно этот функционал злоумышленник туда обязательно заложит). И именно в этот момент раскрывается суть атаки DNS Rebinding - теперь DNS сервер злоумышленника (attacker.dns) будет отвечать, что evil.service.com располагается не на внешнем адресе, а на каком-либо внутреннем (вполне вероятно, что и на 127.0.0.1). И теперь браузер жертвы, отправив запрос на evil.service.net, на самом деле будет его отправлять на тот внутренний адрес, который ему вернул последний ответ локального DNS сервера злоумышленника (attacker.dns). Т.е. жертва будет думать, что отправляет запрос на ресурс злоумышленника (evil.service.net), а на самом деле пошлёт его кому-то другому из своей внутренней сети (например, самой себе на 127.0.0.1). **3. Выполняется реальная цель, заложенная в скрипт злоумышленника.** Если это какой-то POST-запрос, то результат может отобразиться сразу на ресурсе жертвы (example.com), если GET-запрос, то злоумышленнику надо придумать как передать себе его результат. ### Теперь вопрос дня: а зачем такие сложности? Действительно, зачем мучиться с DNS Rebinding, если можно просто заманить жертву на свой ресурс и заставить выполниться JavaScript код на стороне клиента, посылая просто свой запрос из кода сразу по адресу? Да, действительно, зачем бы этот мазохизм, если бы не такая штука как [SOP](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%BE_%D0%BE%D0%B3%D1%80%D0%B0%D0%BD%D0%B8%D1%87%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B4%D0%BE%D0%BC%D0%B5%D0%BD%D0%B0) - Same Origin Policy. Если кратко, то именно из-за этой штуки JavaScript код, загруженный в браузере с одного сайта не сможет выполниться на другом. И именно из-за этого нужны все эти лишние телодвижения. Но правда есть и небольшое исключение - это подгрузка всяких картинок и прочего со сторонних ресурсов. Это можно. И именно этим пользуются как раз для передачи украденных данных в обратную сторону. ## Инструментарий Конечно можно сказать, что всё делается вручную, но зачем изобретать велосипед? Потому ~~для самых ленивых~~ список сервисов, готовых предложить свою помощь: 1. Самый известный вариант - [rbndr](https://lock.cmpxchg8b.com/rebinder.html). Есть онлайн-версия, есть в гитхабе открытый код. Работает максимально простым и понятным образом: генерит ссылку, привязываясь к двум DNS адресам, которые выдаются поочерёдно. Можно использовать для написания собственного кода, можно передавать какие-то переменные прям через неё. 2. Ещё одна штука - [Singularity of Origin](https://github.com/nccgroup/singularity). Ссылка ведёт в гитхаб, где расположен код и инструкции. 3. [DNSChef](https://kali.tools/?p=1425) - [гитхаб](https://github.com/iphelix/dnschef). ## Где попрактиковаться? 1. На root-me есть таск на эту тему: https://www.root-me.org/en/Challenges/Network/HTTP-DNS-Rebinding 2. Нашла лабу с достаточно интересным и понятным описанием. Что самое главное - тут есть решение (лежит в том же репозитории). Её суть в том, что у нас есть имитация IoT устройства (типа термометр), управление которым доступно только с той же самой машины, на котором оно развёрнуто. Задача - поменять температуру на нём с внешего сервера. Из минусов: лаба на английском. Из плюсов: в файле рядом лежит готовое решение, можно поробовать первый раз протыкать чужое и осознать как было сделано. https://github.com/MeghaJakhotia/InternetSecurityAttacks/tree/8a5b3de1099c43c63be0fe53b1b91068ee94a36a/DNS%20Rebinding%20Attack ## Несколько райтапов, которые можно изучить - [HITCON CTF 2021](https://blog.bi0s.in/2021/12/05/Web/Vulpixelize-HITCONCTF2021/) - тут райтап как раз с использованием rbndr. - [TokyoWesterns CTF 2020](https://gist.github.com/terjanq/e2198440c4fdfbdec43e921b600d4a1d) - тут коротенький райтап с использованием Singularity. - [HTB x Uni CTF 2020](https://sec.stealthcopter.com/htb-ctf-writeup-cached-web/) - ещё один таск с кусочком DNS Rebinding с использованием rbndr. - [BSidesTLV CTF 2018](https://jctf.team/BSidesTLV-2018/Can-you-bypass-the-SOP/) - тут люди вообще не поленились и сделали всё ручками. Что тут интересного - здесь как раз есть код с демонстрацией того, как вернуть себе результат не смотря на SOP. ## Материалы, из которых была взята информация - Такой хороший полноценный материал от Positive Technologies - [тык](https://www.ptsecurity.com/upload/corporate/ru-ru/analytics/DNS-Rebinding-ED.pdf). - Материал о применении DNS Rebinding на примере с IoT - [тык](https://habr.com/ru/companies/fbk_cs/articles/439522/). - Чуть подробнее про SOP (не википедия уже) - [тык](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy).