Другая А запись где? на публичном днс сервере или на

днс сервере атакующего?

На твоём домене. Причем тут днс.

У тебя свой домен, у этого домена меняется а-запись При первом запросе возвращается нормальный ip, проходишь проверку. При втором локальный

А зачем тогда сервера уязвимого ресурса делают днс резолв по этим А записям на моем домене? Если у них уже есть адрес моего домена

Потому что там ошибка в коде. О чем, кстати, говорится в видосе. (Я исходники не смотрел, могу чуток ошибаться. Опишу как говорится в видосе, и что видно в коде на видосе) До fix`a: 1) функция получает на вход hostname 2) резольвит ip-адрес 3) валидирует ip-адрес (проверки на приватные ip, и т.п.) 4) возвращает True - если все успешно, или False - если проверка не пройдена. 5) HTTP-запросы отправляются на hostname. После fix'a, 1) функция получает на вход hostname 2) резольвит ip-адрес 3) валидирует ip-адрес (проверки на приватные ip, и т.п.) 4) функция возвращает uri и hostname 5) hostname используется для проверки SSL, а http-запросы идут конкретно к тому IP, который был получен в пункте 2. Видно что до fix'a, проверка на IP-адрес очень просто обходится. Достаточно на момент проверки вернуть нормальный IP-адрес. Затем сменить его на локальный, подождать пока DNS-серваки начнут резольвить новый IP-адрес и вуаля - доступ в приватную сеть. Сама cwe: https://cwe.mitre.org/data/definitions/367.html

т.е. как я понял это происходит до фикса: сервер получает на вход hostname, делает dns запрос на публичный DNS сервер, который у него прописан. Затем из-за какой-то мисконфигурации он делает еще один dns запрос, только уже по IPшнику пришедшему с публичного DNS сервера по полученному хостнейму????? (Звучит очень странно, или я чего-то не понял?) Далее валидирует полученый со второй DNS очереди ip, передает запрос на бэкенд, бэкенд делает все то-же самое, только на этот раз получает локальный ipшник после чего отправляет запрос по этому ipшнику и т.д.

Я тебя чуток наебал, неправильно код прочитал. https://ru.wikipedia.org/wiki/DNS_rebinding

в итоге вопрос остается открытым, почему сервера уязвимого веб ресурса делают днс резолв на подконтрольный днс сервер атакующего / либо зачем после резолва айпишника хоста атакующего сервера они делают второй днс запрос уже на сам атакующий сервер? Я так и не понял какой из этих вариантов имеет место быть 😓

1 регаешь свой домен и делаешь контролируемый ip отвечающим за зону (там поддомен обычно делают), поэтому за днс запросами придут к тебе 2 небольшой ttl чтоб успело протухнуть

Там проблема не в самом dns а уязвимости Time of check time of use. Конечно чтобы ssrf не было они добавили проверки на айпи, но проверка айпи происходит только при первом запросе а то что потом dns сервер может поменять A запись они неучли. Поэтому получается байпас ssrf проверок time of check time of use.

ну это понятно, вопрос немного в другом. основной затык в том зачем и почему уязвимый веб сервер вообще делает запрос на днс сервер атакующего, ведь никаких причин для этого я не вижу. Например он может сделать на этот сервер http запрос - и это будет вполне полятно, поскольку в контексте ssrf entry point api колл подразумевает такое поведение, чего нельзя сказать о dns резолве на malicious сервер

Потому что у него hostname. В интернете нельзя ходить по hostname. Нужен IP, ip узнается через DNS.

так он айпишник этого хостнейма резолвит от публичного днс сервера, а не от днс сервера атакующего

А как публичный резольвит ip? А что будет если локальный кеш протухнет. А если протухнет кеш публичного.

по локальным рекордам между серверами, по которым он бегает через ns записи

если локальный кэш протухнет, будет еще одно обращение на публичный днс сервер.

продолжая мое сообщение: а публичный днс уж точно не будет с пониженым ttl кидать ответ или с локальным айпишником

nslookup --dns-ip=8.8.8.8 localhost.mail.ru

Может будет может нет. Бывает что низкий ттл используют для балансировки нагрузок например. Поэтому использовали свой домен и на нём настроили все как нужно.

то-есть ты хочешь сказать, что в контексте атаки, атакующий проводит конфигурации вида attacker.com - 1.2.3.4; attacker.com - 127.0.0.1 и манипуляции с ttl на Публичном днс сервере?

Да днс ребиндинг делает

твой публичный днс пойдет к серверу отвечающему за эту зону и спросит у него, вернет обратно а сервер к которому он придет ты контроллируешь

да, произошел небольшой мисандерстенд)) чтобы разобраться в котором чуть ли не целый день понадобился

чтоб интереснее было промежуточные серверы могут по своему кэшить ответы еще есть вариация когда возвращается 2 A записи и после обращения к первой, она делается недоступной и сервер пойдет ко второй А записи

хорошие статейки где почитать про такие интересные решения?)