Скрытые резолверы DNS и как скомпрометировать вашу инфраструктуру
Анализируя закрытые резолверы DNS в Интернете, мы обнаружили множество интернет-провайдеров и хостинг-провайдеров, уязвимых для тривиальных атак Каминского. Это позволяет злоумышленнику манипулировать разрешением DNS-имен тысяч систем. Как следствие, возможны перенаправления электронной почты, захват учетных записей и даже компрометация целых систем. Закрытые преобразователи DNS по всему миру затронуты.
В этой статье описывается основная проблема нашего исследования и способы поиска уязвимостей в закрытых резолверах DNS. Кроме того, представлены и предоставляются инструменты с открытым исходным кодом, такие как сервер анализа DNS. Наконец, мы покажем, как захватить полностью пропатченный экземпляр WordPress с помощью эксплойта ПОК!
- Это влияет на меня?
- Как я могу защитить себя?
- Должен ли я быть в поисках уязвимостей DNS?
Раздел "Вопросы и ответы" внизу этой статьи охватывает эти и многие другие вопросы.
Основная проблема
В нашем блоге статья "Забыли пароль? Захват учетных записей пользователей в стиле Каминского" мы показали, как злоумышленник может получить доступ к учетным записям пользователей веб-приложения, манипулируя разрешением имен DNS. Кроме того, мы подробно рассказали о том, как найти уязвимости в настройках DNS веб-приложений, и о том, что такие уязвимости существуют даже сегодня. Однако мы не решили основную проблему!
Как правило, если система хочет разрешить имя через DNS, используется преобразователь DNS. Популярным примером преобразователя DNS является преобразователь Google 8.8.8.8 (как показано на рисунке 1). Этот преобразователь является общедоступным/открытым и поэтому может использоваться любым пользователем в Интернете. В отличие от публичных/открытых распознавателей, существуют закрытые распознаватели. Такие резолверы находятся во внутренних сетях или доступны только избранной группе систем. Закрытые резолверы могут, например, предоставляться серверам хостинг-провайдера, клиентам интернет-провайдера или клиентам компании. Обычно не предполагается, что кто-либо в Интернете может получить доступ к закрытым преобразователям.
Однако, как показано в нашем предыдущем сообщении в блоге DNS, функциональные возможности веб-приложений могут быть "злоупотреблены" для анализа и атаки на эти закрытые распознаватели. Более того, оказалось, что самые небезопасные резолверы, скорее всего, были закрытыми резолверами. Итак, что, если эти закрытые преобразователи очень небезопасны, но никто об этом не знает?
Или, говоря метафорически: что скрывается под айсбергом распознавателя DNS?
Вот что мы собираемся выяснить!
Резолверы не закрыты... закрыты?
Закрытые резолверы недоступны напрямую из Интернета, так как же их анализировать и атаковать?
В общем, нам нужен способ отправить DNS-запрос на закрытый резолвер. В нашем предыдущем сообщении в блоге "Забыли пароль? Захват учетных записей пользователей в стиле Каминского", мы достигли этого, используя функции регистрации, сброса пароля и новостной рассылки веб-приложений. Указав наш специальный аналитический домен в качестве адреса электронной почты (например, test@0100001337.analysis.example ), мы смогли проанализировать разрешение DNS-имен закрытых преобразователей.
Однако не каждая компания предоставляет веб-приложение, не говоря уже о функциях регистрации, сброса пароля или новостной рассылки. Другой метод доступа к закрытым резолверам — подмена исходного IP-адреса IP-адресом, разрешенным закрытым резолвером [1] (см. рис. 3).
Однако это не позволило бы нам тестировать резолверы во внутренних сетях. Поэтому мы выбрали другой, еще более простой способ. SPF, DKIM и DMARC — это механизмы защиты от спама в электронной почте, использующие DNS. Теперь мы можем "эксплуатировать" эти механизмы для анализа закрытых распознавателей. "Но как же нам это сделать?" — спросит кто-то.
Использование защиты от спама
При отправке электронной почты принимающий почтовый сервер проверяет, разрешено ли отправителю отправлять электронные письма для указанного домена, чтобы предотвратить спам. Например, если мы отправляем электронное письмо как " test@gmail.com", сервер электронной почты, скорее всего, отправит DNS-запросы для получения информации SPF, DKIM и DMARC для "gmail.com". Это означает, что преобразователь должен связаться с авторитетным сервером имен (ADNS) gmail.com (как показано на рисунке 4).
Теперь, если мы указываем наш собственный аналитический домен в адресе электронной почты (например, test@0100001337.analysis.example), мы можем заставить распознаватель связываться с нашим собственным аналитическим ADNS для домена "analysis.example". Это позволяет нам анализировать разрешение DNS-имен потенциально закрытого резолвера. Как всегда, картинка лучше тысячи слов (см. рис. 5).
Анализ разрешения DNS
Таким образом, мы можем заставить потенциально закрытый резолвер связываться с нашей аналитической ADNS, отправив электронное письмо. Что теперь?
Теперь анализируем! Используя обновленную версию средства проверки сброса DNS, сервера анализа DNS, мы можем считывать и управлять трафиком DNS, который поступает в нашу аналитическую ADNS и из нее. Делая это, мы можем проанализировать интересные функции безопасности DNS закрытого преобразователя, такие как рандомизация исходного порта, DNSSEC, фрагментация IP и многое другое. Вкратце этот процесс анализа можно обобщить, как показано на рисунке 6.
Для более подробного ознакомления с тем, как работает сервер анализа DNS, ознакомьтесь с нашей предыдущей статьей в блоге или загляните в репозиторий GitHub https://github.com/The-Login/DNS-Analysis-Server .
Сканирование Интернета
Теперь, когда мы знаем, как тестировать закрытые преобразователи на наличие уязвимостей, тяжелая (умственная) работа выполнена. Все, что осталось сделать, это отправить электронные письма на некоторые известные домены и указать домен анализа в качестве домена отправки. Например, будет отправлено следующее электронное письмо:
Субдомен "0100001337" используется для указания версии теста (01), метода анализа для начала (00) и идентификатора тестируемого домена (001337). В частности, идентификатор домена имеет решающее значение для возможности различать DNS-трафик нескольких доменов.
Кроме того, чтобы также инициировать запросы DNS для записей DKIM, мы добавляем подпись DKIM с соответствующим селектором DKIM "_dkim.0100001337.analysis.example" к нашему электронному письму. Инструмент для создания и отправки таких сообщений электронной почты также включен в сервер анализа DNS!
Теперь мы можем отправить это электронное письмо на несколько важных доменов и надеяться на лучшее/худшее!
Первые результаты
После просмотра данных первой сотни доменов результаты были… неутешительными. Однако, как только мы подумали, что не найдем ничего интересного, мы нашли домен со следующей диаграммой разброса исходных портов UDP (см. рисунок 7). Кому-то это может показаться просто точками на белом холсте, но для нас эти точки значили гораздо больше. Это связано с тем, что эти точки визуализируют случайное распределение исходных портов преобразователя DNS. Однако, как мы видим, эти исходные порты распределяются не случайным образом, а статически. Итак, что это значит?
Обход Каминского
В 2008 году Дэн Камински показал миру, насколько важно случайное распределение исходных портов или почему оно должно быть. Когда преобразователь DNS отправляет запрос "gmail.com" в ADNS "gmail.com", какие средства защиты мешают злоумышленнику отправить поддельный ответ DNS преобразователю до того, как придет фактический ответ? Ну, это не так много. Поскольку DNS в основном использует UDP, злоумышленник может провести атаку не по пути (как показано на рисунке 8).
Однако в наше время все не так просто. Злоумышленник также должен угадать правильный случайный 16-битный DNS-идентификатор и правильный случайный 16-битный исходный порт UDP законного ответа. В совокупности это 32 случайных бита, которые составляют примерно 4 миллиарда различных комбинаций. Получайте удовольствие, угадывая это! Но еще в 2008 году лишь несколько преобразователей DNS фактически использовали случайные исходные порты, что упрощало угадывание примерно в 65 000 раз! В конечном итоге это привело к тому, что Дэн Камински обнаружил атаку Каминского, которая позволяет манипулировать кэшами преобразователей DNS с произвольными записями DNS, как показано на рисунке 9.
Спуск в кроличью нору
Найти статическое распределение исходных портов UDP — это здорово (по крайней мере, для нас), но у нас было ощущение, что это нечто большее. Так с чего бы закрытый резолвер только для одного сервера, а не для многих? Итак, мы немного покопались!
Проверив номер автономной системы (ASN) IP-адреса резолвера, мы обнаружили, что IP принадлежит хостинг-провайдеру. Кроме того, выполнив обратный поиск DNS, мы увидели, что IP-адрес также связан с именем "dns3.victim.example". Это очень похоже на название ADNS! Затем, используя пассивную базу данных DNS, мы выявили сотни доменов, размещенных в этом ADNS. Отправка электронных писем на эти домены позволила нам проанализировать разрешение их DNS-имен. Таким образом, было выявлено еще 306 доменов, использующих статические исходные порты для DNS-запросов (см. рис. 10).
Бинго! Но это еще не все!
В некоторых случаях внешний IP-адрес преобразователя связан с доменным именем, например "id3451.mailprovider.example ". Это большой показатель того, что домен использует внешнего провайдера электронной почты! Путем поиска записей MX изначально идентифицированного уязвимого домена в пассивной базе данных DNS мы можем найти тысячи других доменов, которые используют те же записи MX/почтовые серверы. Проверка этих доменов на наличие статических исходных портов в их разрешении DNS-имен приводит к сотням более уязвимых доменов (как показано на рисунке 11).
(Не)безопасность закрытых преобразователей DNS
После отправки электронных писем примерно 50 тысячам доменов мы получили и проанализировали данные DNS примерно для 7000 из них. Среди этих 7000 доменов как минимум 25 использовали статические исходные порты. Снова спустившись в кроличью нору, были обнаружены еще тысячи доменов, использующих статические исходные порты. Джекпот!
А как насчет функций безопасности DNS. Разве такие механизмы, как DNSSEC, не смягчили бы атаки Каминского? Теоретически да, однако, как было обнаружено в нашем предыдущем посте в блоге DNS, большинство преобразователей DNS не используют эти функции или не применяют их. В этом случае 0 из 25 уязвимых распознавателей использовали/обеспечивали дополнительные функции безопасности. Это может быть результатом неправильно настроенного или устаревшего программного обеспечения DNS.
Итак, кто пострадал? Хотя мы не можем раскрывать точные домены, вот список доменов верхнего уровня (TLD), которые были определены как уязвимые.
Тепловая карта затронутых доменов показывает, что уязвимые серверы разбросаны в основном по северному полушарию (см. рис. 12).
Затронутые службы, работающие за этими доменами, открывают широкий спектр возможностей. Наряду с государственными службами, политическими кампаниями и сайтами крупных компаний было обнаружено множество сайтов малого бизнеса.
Из-за того, что было проанализировано всего около 7000 доменов, это все еще, вероятно, только верхушка айсберга закрытых распознавателей, как показано на рисунке 13!
Итак, теперь мы можем манипулировать разрешением DNS-имен тысяч доменов с помощью атак Каминского. Но в чем проблема?
Использование DNS
В целом, запустив атаку Каминского, злоумышленник может манипулировать записями DNS преобразователей DNS. Например, злоумышленник может манипулировать записью MX для "gmail.com", чтобы указать на "attacker.example" (рис. 14). Как подробно описано в нашем первой статье в блоге DNS, это, по сути, позволяет злоумышленнику перенаправлять электронные письма!
Это особенно деликатно, когда речь идет об административных интерфейсах (например, WordPress, Joomla и т. д.) и их функциях сброса пароля, поскольку электронные письма для сброса пароля также могут быть перенаправлены (см. пример на рисунке 15). Даже если на веб-сайте не отображается сообщение "Забыли пароль?", иногда страдает и панель управления хостинг-провайдера (см. рис. 16).
Кроме того, можно было бы манипулировать информацией SPF, DKIM и DMARC, что по существу позволяет использовать все виды спуфинга электронной почты (см. рис. 17). Кроме того, манипулируя разрешением DNS-имен сервера, большинство сетевых соединений, зависящих от разрешения DNS-имен, можно перенаправлять, перехватывать и, возможно, даже манипулировать ими. Дэн Камински дал хороший обзор возможных векторов DNS-атак еще в 2008 году!
Доказательство концепции
Итак, можем ли мы использовать закрытые преобразователи DNS на практике?
Как уже заявил Дэн Камински в 2008 году, это вполне возможно! Процесс эксплойта отравления кэша DNS выглядит примерно так, как показано на рисунке 18.
Злоумышленник отправляет электронное письмо с домена "XXX.mx.gmail.com" на сервер электронной почты, где XXX является случайным субдоменом, не кэшированным распознавателем DNS. Затем сервер электронной почты запрашивает у закрытого преобразователя DNS запись TXT для этого имени. Поскольку случайный поддомен не кэшируется в DNS-преобразователе, преобразователь запрашивает ADNS "gmail.com".
Злоумышленник теперь может попытаться совместить фактический ответ ADNS с манипулируемым ответом. Если ответ злоумышленника побеждает в гонке, "mx.gmail.com" теперь указывает на "attacker.example". В противном случае злоумышленник отправляет другое электронное письмо с другим случайным поддоменом и повторяет процедуру до тех пор, пока кеш DNS не будет отравлен поддельным ответом. При успешной атаке злоумышленник может изменить пример домена MX "mx.gmail.com», чтобы он указывал на сервер имен "attacker.example". По сути, это позволяет злоумышленнику указать произвольный IP-адрес почтового сервера! Кэш отравленного распознавателя будет выглядеть следующим образом:
Проведя эту атаку в несколько реалистичной среде, мы подтвердили, что можно отравить кеши закрытых распознавателей DNS и что мы можем захватить полностью пропатченные экземпляры WordPress с помощью реидректора сброса пароля! Однако, чтобы не наносить ущерб резолверам DNS по всему миру, мы пока не выпускаем инфраструктуру PoC и сценарии PoC.
Ответственное раскрытие информации
Чтобы ответственно раскрыть эту проблему и связаться с затронутыми интернет-провайдерами и хостинг-провайдерами, мы отправили отчет об уязвимости в Коммуникационный центр CERT (CERT/CC) в июле этого года. CERT/CC очень помог нам с скоординированным раскрытием информации. Огромное спасибо CERT/CC за их профессиональную и быструю связь и координацию!
Однако, поскольку мы не можем сканировать и исправлять весь Интернет, скорее всего, все еще существует множество уязвимых преобразователей DNS.
Вопросы и ответы (Q&A)
Кто первым проанализировал закрытые резолверы DNS?
Сначала мы думали, что мы первые. Однако, покопавшись в некоторой литературе, мы обнаружили, что первые тесты уже были проведены в 2018 году [2]. Хотя почему-то уязвимых резолверов обнаружено не было. В статье от 2020 года [1] закрытые резолверы снова были протестированы с помощью IP-спуфинга внутренних IP-адресов. Цифры из этой статьи примерно такие же, как и у нас.
Должен ли я быть в поисках уязвимостей DNS?
Да, определенно, так как уязвимости DNS могут допустить всевозможные плохие вещи! К счастью, проверку на наличие уязвимостей в вашей инфраструктуре DNS можно выполнить довольно быстро с помощью уже настроенного сервера анализа.
Как узнать, подвержен ли я приступу Каминского?
Если есть сомнения относительно используемых преобразователей DNS и инфраструктуры DNS в целом, самый простой способ выяснить это — воспользоваться нашим сервером анализа DNS !
Как я могу защитить себя от атаки DNS?
Чтобы предотвратить этот вектор атаки, в первую очередь должна быть защищена инфраструктура DNS. Некоторые рекомендации по обеспечению безопасности собственных преобразователей DNS можно найти в Google и на сайте DNS flag day. Также можно использовать крупных публичных DNS-провайдеров, таких как Google, Cloudflare или Cisco. Эти крупные провайдеры обычно быстро реализуют меры противодействия новым DNS-атакам .
Существуют ли уязвимости после защиты инфраструктуры DNS, можно проверить с помощью сервера анализа DNS .
Может ли быть больше уязвимостей DNS, скрывающихся под айсбергом распознавателя DNS?
Да! Во-первых, из-за кучи данных, через которые мы прошли, вполне вероятно, что мы пропустили некоторые уязвимые распознаватели. Кроме того, электронные письма были отправлены на, скорее всего, несуществующие адреса электронной почты (например, test@victim.example). В зависимости от сервера электронной почты это может не запускать разрешение DNS нашего домена отправителя/анализа.
Являются ли закрытые распознаватели более уязвимыми, чем открытые распознаватели?
Из 25 уязвимых распознавателей было подтверждено, что только два из них находятся в открытом доступе. Это подтверждает первоначальную гипотезу о том, что уязвимые распознаватели с большей вероятностью будут закрыты. (Обратите внимание, что 35% проанализированных распознавателей оказались открытыми, а 65% — закрытыми).
Где я могу найти предыдущий пост в блоге об уязвимостях DNS в веб-приложениях?
Ну вот! https://sec-consult.com/blog/detail/forgot-password-taking-over-user-accounts-kaminsky-style/
Использованная литература
[1] Deccio, Кейси и др. "За закрытыми дверями: сетевая история о спуфинге, вторжении и ложной безопасности DNS". Материалы конференции ACM Internet Measurement. 2020.
[2] Шеффлер, Сара и др. "Непреднамеренные последствия предотвращения спама по электронной почте». Международная конференция по пассивным и активным измерениям сети. Спрингер, Чам, 2018 г.
Это исследование было проведено Тимо Лонгином и Клеменсом Стокенрайтнером и опубликовано от имени SEC Consult Vulnerability Lab.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://sec-consult.com/blog/detail...king-over-your-infrastructure-kaminsky-style/
Анализируя закрытые резолверы DNS в Интернете, мы обнаружили множество интернет-провайдеров и хостинг-провайдеров, уязвимых для тривиальных атак Каминского. Это позволяет злоумышленнику манипулировать разрешением DNS-имен тысяч систем. Как следствие, возможны перенаправления электронной почты, захват учетных записей и даже компрометация целых систем. Закрытые преобразователи DNS по всему миру затронуты.
В этой статье описывается основная проблема нашего исследования и способы поиска уязвимостей в закрытых резолверах DNS. Кроме того, представлены и предоставляются инструменты с открытым исходным кодом, такие как сервер анализа DNS. Наконец, мы покажем, как захватить полностью пропатченный экземпляр WordPress с помощью эксплойта ПОК!
- Это влияет на меня?
- Как я могу защитить себя?
- Должен ли я быть в поисках уязвимостей DNS?
Раздел "Вопросы и ответы" внизу этой статьи охватывает эти и многие другие вопросы.
Основная проблема
В нашем блоге статья "Забыли пароль? Захват учетных записей пользователей в стиле Каминского" мы показали, как злоумышленник может получить доступ к учетным записям пользователей веб-приложения, манипулируя разрешением имен DNS. Кроме того, мы подробно рассказали о том, как найти уязвимости в настройках DNS веб-приложений, и о том, что такие уязвимости существуют даже сегодня. Однако мы не решили основную проблему!
Как правило, если система хочет разрешить имя через DNS, используется преобразователь DNS. Популярным примером преобразователя DNS является преобразователь Google 8.8.8.8 (как показано на рисунке 1). Этот преобразователь является общедоступным/открытым и поэтому может использоваться любым пользователем в Интернете. В отличие от публичных/открытых распознавателей, существуют закрытые распознаватели. Такие резолверы находятся во внутренних сетях или доступны только избранной группе систем. Закрытые резолверы могут, например, предоставляться серверам хостинг-провайдера, клиентам интернет-провайдера или клиентам компании. Обычно не предполагается, что кто-либо в Интернете может получить доступ к закрытым преобразователям.
Однако, как показано в нашем предыдущем сообщении в блоге DNS, функциональные возможности веб-приложений могут быть "злоупотреблены" для анализа и атаки на эти закрытые распознаватели. Более того, оказалось, что самые небезопасные резолверы, скорее всего, были закрытыми резолверами. Итак, что, если эти закрытые преобразователи очень небезопасны, но никто об этом не знает?
Или, говоря метафорически: что скрывается под айсбергом распознавателя DNS?
Вот что мы собираемся выяснить!
Резолверы не закрыты... закрыты?
Закрытые резолверы недоступны напрямую из Интернета, так как же их анализировать и атаковать?
В общем, нам нужен способ отправить DNS-запрос на закрытый резолвер. В нашем предыдущем сообщении в блоге "Забыли пароль? Захват учетных записей пользователей в стиле Каминского", мы достигли этого, используя функции регистрации, сброса пароля и новостной рассылки веб-приложений. Указав наш специальный аналитический домен в качестве адреса электронной почты (например, test@0100001337.analysis.example ), мы смогли проанализировать разрешение DNS-имен закрытых преобразователей.
Однако не каждая компания предоставляет веб-приложение, не говоря уже о функциях регистрации, сброса пароля или новостной рассылки. Другой метод доступа к закрытым резолверам — подмена исходного IP-адреса IP-адресом, разрешенным закрытым резолвером [1] (см. рис. 3).
Однако это не позволило бы нам тестировать резолверы во внутренних сетях. Поэтому мы выбрали другой, еще более простой способ. SPF, DKIM и DMARC — это механизмы защиты от спама в электронной почте, использующие DNS. Теперь мы можем "эксплуатировать" эти механизмы для анализа закрытых распознавателей. "Но как же нам это сделать?" — спросит кто-то.
Использование защиты от спама
При отправке электронной почты принимающий почтовый сервер проверяет, разрешено ли отправителю отправлять электронные письма для указанного домена, чтобы предотвратить спам. Например, если мы отправляем электронное письмо как " test@gmail.com", сервер электронной почты, скорее всего, отправит DNS-запросы для получения информации SPF, DKIM и DMARC для "gmail.com". Это означает, что преобразователь должен связаться с авторитетным сервером имен (ADNS) gmail.com (как показано на рисунке 4).
Теперь, если мы указываем наш собственный аналитический домен в адресе электронной почты (например, test@0100001337.analysis.example), мы можем заставить распознаватель связываться с нашим собственным аналитическим ADNS для домена "analysis.example". Это позволяет нам анализировать разрешение DNS-имен потенциально закрытого резолвера. Как всегда, картинка лучше тысячи слов (см. рис. 5).
Анализ разрешения DNS
Таким образом, мы можем заставить потенциально закрытый резолвер связываться с нашей аналитической ADNS, отправив электронное письмо. Что теперь?
Теперь анализируем! Используя обновленную версию средства проверки сброса DNS, сервера анализа DNS, мы можем считывать и управлять трафиком DNS, который поступает в нашу аналитическую ADNS и из нее. Делая это, мы можем проанализировать интересные функции безопасности DNS закрытого преобразователя, такие как рандомизация исходного порта, DNSSEC, фрагментация IP и многое другое. Вкратце этот процесс анализа можно обобщить, как показано на рисунке 6.
Для более подробного ознакомления с тем, как работает сервер анализа DNS, ознакомьтесь с нашей предыдущей статьей в блоге или загляните в репозиторий GitHub https://github.com/The-Login/DNS-Analysis-Server .
Сканирование Интернета
Теперь, когда мы знаем, как тестировать закрытые преобразователи на наличие уязвимостей, тяжелая (умственная) работа выполнена. Все, что осталось сделать, это отправить электронные письма на некоторые известные домены и указать домен анализа в качестве домена отправки. Например, будет отправлено следующее электронное письмо:
Субдомен "0100001337" используется для указания версии теста (01), метода анализа для начала (00) и идентификатора тестируемого домена (001337). В частности, идентификатор домена имеет решающее значение для возможности различать DNS-трафик нескольких доменов.
Кроме того, чтобы также инициировать запросы DNS для записей DKIM, мы добавляем подпись DKIM с соответствующим селектором DKIM "_dkim.0100001337.analysis.example" к нашему электронному письму. Инструмент для создания и отправки таких сообщений электронной почты также включен в сервер анализа DNS!
Теперь мы можем отправить это электронное письмо на несколько важных доменов и надеяться на лучшее/худшее!
Первые результаты
После просмотра данных первой сотни доменов результаты были… неутешительными. Однако, как только мы подумали, что не найдем ничего интересного, мы нашли домен со следующей диаграммой разброса исходных портов UDP (см. рисунок 7). Кому-то это может показаться просто точками на белом холсте, но для нас эти точки значили гораздо больше. Это связано с тем, что эти точки визуализируют случайное распределение исходных портов преобразователя DNS. Однако, как мы видим, эти исходные порты распределяются не случайным образом, а статически. Итак, что это значит?
Обход Каминского
В 2008 году Дэн Камински показал миру, насколько важно случайное распределение исходных портов или почему оно должно быть. Когда преобразователь DNS отправляет запрос "gmail.com" в ADNS "gmail.com", какие средства защиты мешают злоумышленнику отправить поддельный ответ DNS преобразователю до того, как придет фактический ответ? Ну, это не так много. Поскольку DNS в основном использует UDP, злоумышленник может провести атаку не по пути (как показано на рисунке 8).
Однако в наше время все не так просто. Злоумышленник также должен угадать правильный случайный 16-битный DNS-идентификатор и правильный случайный 16-битный исходный порт UDP законного ответа. В совокупности это 32 случайных бита, которые составляют примерно 4 миллиарда различных комбинаций. Получайте удовольствие, угадывая это! Но еще в 2008 году лишь несколько преобразователей DNS фактически использовали случайные исходные порты, что упрощало угадывание примерно в 65 000 раз! В конечном итоге это привело к тому, что Дэн Камински обнаружил атаку Каминского, которая позволяет манипулировать кэшами преобразователей DNS с произвольными записями DNS, как показано на рисунке 9.
Спуск в кроличью нору
Найти статическое распределение исходных портов UDP — это здорово (по крайней мере, для нас), но у нас было ощущение, что это нечто большее. Так с чего бы закрытый резолвер только для одного сервера, а не для многих? Итак, мы немного покопались!
Проверив номер автономной системы (ASN) IP-адреса резолвера, мы обнаружили, что IP принадлежит хостинг-провайдеру. Кроме того, выполнив обратный поиск DNS, мы увидели, что IP-адрес также связан с именем "dns3.victim.example". Это очень похоже на название ADNS! Затем, используя пассивную базу данных DNS, мы выявили сотни доменов, размещенных в этом ADNS. Отправка электронных писем на эти домены позволила нам проанализировать разрешение их DNS-имен. Таким образом, было выявлено еще 306 доменов, использующих статические исходные порты для DNS-запросов (см. рис. 10).
Бинго! Но это еще не все!
В некоторых случаях внешний IP-адрес преобразователя связан с доменным именем, например "id3451.mailprovider.example ". Это большой показатель того, что домен использует внешнего провайдера электронной почты! Путем поиска записей MX изначально идентифицированного уязвимого домена в пассивной базе данных DNS мы можем найти тысячи других доменов, которые используют те же записи MX/почтовые серверы. Проверка этих доменов на наличие статических исходных портов в их разрешении DNS-имен приводит к сотням более уязвимых доменов (как показано на рисунке 11).
(Не)безопасность закрытых преобразователей DNS
После отправки электронных писем примерно 50 тысячам доменов мы получили и проанализировали данные DNS примерно для 7000 из них. Среди этих 7000 доменов как минимум 25 использовали статические исходные порты. Снова спустившись в кроличью нору, были обнаружены еще тысячи доменов, использующих статические исходные порты. Джекпот!
А как насчет функций безопасности DNS. Разве такие механизмы, как DNSSEC, не смягчили бы атаки Каминского? Теоретически да, однако, как было обнаружено в нашем предыдущем посте в блоге DNS, большинство преобразователей DNS не используют эти функции или не применяют их. В этом случае 0 из 25 уязвимых распознавателей использовали/обеспечивали дополнительные функции безопасности. Это может быть результатом неправильно настроенного или устаревшего программного обеспечения DNS.
Итак, кто пострадал? Хотя мы не можем раскрывать точные домены, вот список доменов верхнего уровня (TLD), которые были определены как уязвимые.
Тепловая карта затронутых доменов показывает, что уязвимые серверы разбросаны в основном по северному полушарию (см. рис. 12).
Затронутые службы, работающие за этими доменами, открывают широкий спектр возможностей. Наряду с государственными службами, политическими кампаниями и сайтами крупных компаний было обнаружено множество сайтов малого бизнеса.
Из-за того, что было проанализировано всего около 7000 доменов, это все еще, вероятно, только верхушка айсберга закрытых распознавателей, как показано на рисунке 13!
Итак, теперь мы можем манипулировать разрешением DNS-имен тысяч доменов с помощью атак Каминского. Но в чем проблема?
Использование DNS
В целом, запустив атаку Каминского, злоумышленник может манипулировать записями DNS преобразователей DNS. Например, злоумышленник может манипулировать записью MX для "gmail.com", чтобы указать на "attacker.example" (рис. 14). Как подробно описано в нашем первой статье в блоге DNS, это, по сути, позволяет злоумышленнику перенаправлять электронные письма!
Это особенно деликатно, когда речь идет об административных интерфейсах (например, WordPress, Joomla и т. д.) и их функциях сброса пароля, поскольку электронные письма для сброса пароля также могут быть перенаправлены (см. пример на рисунке 15). Даже если на веб-сайте не отображается сообщение "Забыли пароль?", иногда страдает и панель управления хостинг-провайдера (см. рис. 16).
Кроме того, можно было бы манипулировать информацией SPF, DKIM и DMARC, что по существу позволяет использовать все виды спуфинга электронной почты (см. рис. 17). Кроме того, манипулируя разрешением DNS-имен сервера, большинство сетевых соединений, зависящих от разрешения DNS-имен, можно перенаправлять, перехватывать и, возможно, даже манипулировать ими. Дэн Камински дал хороший обзор возможных векторов DNS-атак еще в 2008 году!
Доказательство концепции
Итак, можем ли мы использовать закрытые преобразователи DNS на практике?
Как уже заявил Дэн Камински в 2008 году, это вполне возможно! Процесс эксплойта отравления кэша DNS выглядит примерно так, как показано на рисунке 18.
Злоумышленник отправляет электронное письмо с домена "XXX.mx.gmail.com" на сервер электронной почты, где XXX является случайным субдоменом, не кэшированным распознавателем DNS. Затем сервер электронной почты запрашивает у закрытого преобразователя DNS запись TXT для этого имени. Поскольку случайный поддомен не кэшируется в DNS-преобразователе, преобразователь запрашивает ADNS "gmail.com".
Злоумышленник теперь может попытаться совместить фактический ответ ADNS с манипулируемым ответом. Если ответ злоумышленника побеждает в гонке, "mx.gmail.com" теперь указывает на "attacker.example". В противном случае злоумышленник отправляет другое электронное письмо с другим случайным поддоменом и повторяет процедуру до тех пор, пока кеш DNS не будет отравлен поддельным ответом. При успешной атаке злоумышленник может изменить пример домена MX "mx.gmail.com», чтобы он указывал на сервер имен "attacker.example". По сути, это позволяет злоумышленнику указать произвольный IP-адрес почтового сервера! Кэш отравленного распознавателя будет выглядеть следующим образом:
Проведя эту атаку в несколько реалистичной среде, мы подтвердили, что можно отравить кеши закрытых распознавателей DNS и что мы можем захватить полностью пропатченные экземпляры WordPress с помощью реидректора сброса пароля! Однако, чтобы не наносить ущерб резолверам DNS по всему миру, мы пока не выпускаем инфраструктуру PoC и сценарии PoC.
Ответственное раскрытие информации
Чтобы ответственно раскрыть эту проблему и связаться с затронутыми интернет-провайдерами и хостинг-провайдерами, мы отправили отчет об уязвимости в Коммуникационный центр CERT (CERT/CC) в июле этого года. CERT/CC очень помог нам с скоординированным раскрытием информации. Огромное спасибо CERT/CC за их профессиональную и быструю связь и координацию!
Однако, поскольку мы не можем сканировать и исправлять весь Интернет, скорее всего, все еще существует множество уязвимых преобразователей DNS.
Вопросы и ответы (Q&A)
Кто первым проанализировал закрытые резолверы DNS?
Сначала мы думали, что мы первые. Однако, покопавшись в некоторой литературе, мы обнаружили, что первые тесты уже были проведены в 2018 году [2]. Хотя почему-то уязвимых резолверов обнаружено не было. В статье от 2020 года [1] закрытые резолверы снова были протестированы с помощью IP-спуфинга внутренних IP-адресов. Цифры из этой статьи примерно такие же, как и у нас.
Должен ли я быть в поисках уязвимостей DNS?
Да, определенно, так как уязвимости DNS могут допустить всевозможные плохие вещи! К счастью, проверку на наличие уязвимостей в вашей инфраструктуре DNS можно выполнить довольно быстро с помощью уже настроенного сервера анализа.
Как узнать, подвержен ли я приступу Каминского?
Если есть сомнения относительно используемых преобразователей DNS и инфраструктуры DNS в целом, самый простой способ выяснить это — воспользоваться нашим сервером анализа DNS !
Как я могу защитить себя от атаки DNS?
Чтобы предотвратить этот вектор атаки, в первую очередь должна быть защищена инфраструктура DNS. Некоторые рекомендации по обеспечению безопасности собственных преобразователей DNS можно найти в Google и на сайте DNS flag day. Также можно использовать крупных публичных DNS-провайдеров, таких как Google, Cloudflare или Cisco. Эти крупные провайдеры обычно быстро реализуют меры противодействия новым DNS-атакам .
Существуют ли уязвимости после защиты инфраструктуры DNS, можно проверить с помощью сервера анализа DNS .
Может ли быть больше уязвимостей DNS, скрывающихся под айсбергом распознавателя DNS?
Да! Во-первых, из-за кучи данных, через которые мы прошли, вполне вероятно, что мы пропустили некоторые уязвимые распознаватели. Кроме того, электронные письма были отправлены на, скорее всего, несуществующие адреса электронной почты (например, test@victim.example). В зависимости от сервера электронной почты это может не запускать разрешение DNS нашего домена отправителя/анализа.
Являются ли закрытые распознаватели более уязвимыми, чем открытые распознаватели?
Из 25 уязвимых распознавателей было подтверждено, что только два из них находятся в открытом доступе. Это подтверждает первоначальную гипотезу о том, что уязвимые распознаватели с большей вероятностью будут закрыты. (Обратите внимание, что 35% проанализированных распознавателей оказались открытыми, а 65% — закрытыми).
Где я могу найти предыдущий пост в блоге об уязвимостях DNS в веб-приложениях?
Ну вот! https://sec-consult.com/blog/detail/forgot-password-taking-over-user-accounts-kaminsky-style/
Использованная литература
[1] Deccio, Кейси и др. "За закрытыми дверями: сетевая история о спуфинге, вторжении и ложной безопасности DNS". Материалы конференции ACM Internet Measurement. 2020.
[2] Шеффлер, Сара и др. "Непреднамеренные последствия предотвращения спама по электронной почте». Международная конференция по пассивным и активным измерениям сети. Спрингер, Чам, 2018 г.
Это исследование было проведено Тимо Лонгином и Клеменсом Стокенрайтнером и опубликовано от имени SEC Consult Vulnerability Lab.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://sec-consult.com/blog/detail...king-over-your-infrastructure-kaminsky-style/