DNS AXFR-запросы

Эта статья о давно известном баге в конфигурации dns-серверов — разрешение на трансфер зоны любому юзеру. И о том, как я написал небольшой сканер для проверки конфигурации dns-серверов самых популярных сайтов. И где уязвимыми оказались банки, гос. сайты, провайдеры и многие другие важные ресурсы.

AXFR-запросы

Передача зоны DNS, AXFR — вид транзакции DNS. Является одним из механизмов репликации баз DNS между серверами © wikipedia

Когда DNS-сервер получает AXFR-запрос он отдает все данные, которые ему известны для запрошенного домена. Подразумевается, что такой запрос придет от DNS-сервера, который пытается выполнить трансфер зоны (перенести домен к себе, реплицировать). Но если DNS-сервер сконфигурирован неверно, любой юзер может получить доступ к этим данным.

Почему это security-баг?

Хочу напомнить вам о взломе Valve, когда хакер украл исходные коды Half-Life 2 (на тот момент разработка стоила ~$1 млн в месяц). Для начала хакер отправил AXFR-запрос DNS серверу ValveSoftware.com. Получив данные о домене, Gembe (хакер) получил всю информацию, включая поддомены ValveSoftware.com.

Подробнее можно прочитать здесь.

Так же, об AXFR можно прочитать в Metasploit Penetration Testing Cookbook, глава 2:

Zone Transfer is a special method used by the DNS server to exchange authoritative records
for a domain between multiple servers. This method is responsible for transferring bulk lists of domain information between primary and secondary servers. A misconfigured DNS server can respond to client query and provide information about the queried domain.

(надеюсь, уже читали переводы от levinkv).

Очень часто сайты имеют «секретные» поддомены (dev.*, test.* и подобные) для внутреннего использования. Обычно, эти домены имеют небезопасную конфигурацию (включенный stacktrace для dev доменов как пример) или разрабатываемые фичи.

Сканирование

Я скачал топ популярных сайтов по версии Alexa и проверил около 25к доменов, ~2k оказались уязвимы. Так же некоторые сайты выбирал вручную. Некоторые из уязвимых сайтов (уже исправлены):

• wikipedia.org (считают, что бага нет [link]);
• xda-developers.com;
• megaupload.com (закрыт);
• topface.com;
• liveinternet.ru (просто закрыли мой тикет с пометкой «не требует ответа», не исправлено);
• kinopoisk.ru;
• exler.ru.

И некоторые другие, очень известные и крупные ресурсы, которые я не могу упомянуть здесь (или так и нет ответа). Но немного фактов, не называя ресурсы:

Хостеры, парковочные DNS сервисы уязвимы. Один из ресурсов подобным образом отдал мне ~3.2млн записей о клиентах этого сайта (клиент = домен).

Некоторые крупные компании, работающие в области безопасности — так же уязвимы.

Многие платежные системы, сайты авиалиний, банки, провайдеры подвержены этому багу.

Я потратил немало времени на репорты тех. поддержке по данному поводу. Многие админы тут же правили конфигурацию на верную, но некоторые админы не считают, что это баг (wikipedia.org как пример) и может быть они правы (но я так не считаю) и некоторые так и не ответили. Бывало, что просто вообще нет контактов для связи, но

Благими намерениями вымощена дорога в ад

После очередного репорта в ответ было не очень приятное общение, после чего я сразу прекратил сканирование и рассылку писем админам.

Забавный факт. На одном из университетских сайтов обнаружился домен «muonline.NAMEOFUNIVERSITY» который является сервером популярной MMORPG — MU Online (похоже на WoW, LineAge2 и т.п.). Жду статистику онлайна на главной странице университета 🙂

Проверь свой домен

Я написал небольшой сервис, который может помочь в проверке вашего домена, точнее, его DNS-серверов, на их конфигурацию к приему AXFR-запросов — http://sergeybelove.ru/tools/axfr-test (возможно, это позволит избежать вашему ресурсу плачевных последствий). Так же можно использовать утилиту «dig» для этого.

Fix?

Ограничить IP-адреса, которым разрешено выполнять трансфер-зоны. Пример для Bind:
allow-transfer { first_ip; second_ip; };
и
rndc reconfig