Пользователь
13,6
рейтинг
23 января 2013 в 09:24

Разработка → 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
Sergey Belov @BeLove
карма
236,7
рейтинг 13,6
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (27)

  • +1
    Чем вам пригрозили, что вы прекратили свои действия? С точки зрения нашего закона, ИМХО, никаких правонарушений вы не совершаете. Пусть сосут лапу эти горе админы.
    • +4
      Доступ к конфиденциальность информации (список внутренних доменов, ресурсов)?
      Пентест (хотя, это лишь «разведка», но все-таки часть «типичного» пентеста) без разрешения на то самого ресурса? Ладно, когда это еще один бложик или новостной сайт. Но когда у сервиса операции на миллионы (миллиарды?) *неуказанной" валюты дело обретает совершенно другой оборот.
      Есть, за что зацепиться, если надо будет :)
      В итоге решил максимально сбалансировано (количество информации для завлечения (чтобы прочитало как можно больше людей) / цели (чтобы админы исправили популярную ошибку) написать статью и предоставить простейший сервис для проверки доменов.
      • +1
        У меня был такой случай, на прошлой работе размещали на своих серверах вторичную зону от дружественной организации, в один момент перестали получать от них информацию, после долгих «копаний» они выяснили что у них на файрволе режутся AXFR запросы. Много времени потратили мы на эту проблему тогда =)
  • НЛО прилетело и опубликовало эту надпись здесь
  • +4
    service bind9 restart
    грамотнее писать rndc reload
    • 0
      Спасибо, обновил пост.
    • +7
      Грамотнее писать rndc reconfig чтобы обойтись без релоада всех зон, коих может быть тысячи.
      • 0
        Почитал здесь. Исправил на reconfig.
      • 0
        Согласен, просто как-то даже забыл о reconfig, т.к. пишу reload для обновления изменённой зоны, а конфиг создаётся и правится примерно раз в жизни сервера. Да, разумеется, в случае если зон тысячи, то лучше вообще написать rndc reload domain.com.
      • 0
        rndc reload zone.name
        • +2
          А это вообще не сработает, т.к. при указании зоны, файл конфига не перечитывается.
  • 0
    Проверил свой домен на вашем сайте, свой домен держу сам.
    «An error occurred while testing this DNS-server»
    Это значит всё хорошо? Или мне уже надо бояться?
    • 0
      Это значит, что сервис не смог достучаться до данного DNS-сервера.
      Попробуйте проверить вручную, при помощи dig или аналогичных утилит.
      • 0
        Нет, ДНС-сервера как раз нашлись, похоже.
        «DNS-servers found...», и IP-адреса правильно указаны.
        • 0
          Видимо, отвечали еще на предыдущий коммент (я редактировал).
          Ответ в комментарии выше.
  • 0
    Читаю я последние новости по безопасности и все четче понимаю смысл фразы «Благими намерениями выложена дорожка в АД». Конечно, я ее и раньше понимал, но из приведенных примеров становится понятно, что о найденных уязвимостях, все-таки, лучше молчать. А то, в итоге, себе дороже получается.

    Наверное, так и становятся Black Hat?
    • 0
      Наверное, так и становятся Black Hat?

      Ну очень многое зависит от морально нравственного воспитания! Если оно есть тогда все ОК, ну а нет… на нет и суда нет.
  • +2
    Статья класс, автору спасибо!
    Позволю от себя добавить ссылку на команду dig (для общего развития) -> www.zytrax.com/books/dns/ch10/dig.html
  • +2
    Вообще на exler.ru эта дырка была закрыта еще 15 января, спасибо человеку, который о ней сообщил.
    • +8
      Это и был я :)
  • 0
    Мне тут люди приближенные к exler.ru говорят что починено еще 15 января ;)
  • 0
    Кстати, прошу автора убирать все комментарии из dig, какие возможно.
    Вот это
    ;; Connection to *#53(*) for*.ru failed: connection refused
    как уязвимость.

    Спасибо.
    • 0
      Спасибо, добавил правило.
      Вообще dig вызывается с +short.
      Кстати, либы из Pear в данном случае не получилось использовать, порой съедают over 3 GB Ram.
    • 0
      Опечатка. Читать так: вот это вот сервис сервис трактует как уязвимость
  • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      Вот-вот. Это проблема уязвимых сервисов в valve, а не ДНС. То, что dev доступен извне. Точно также его и без ДНС можно было «угадать».
  • 0
    > Но если DNS-сервер сконфигурирован неверно, любой юзер может получить доступ к этим данным.

    Я думаю, что это основная мысль поста. Все! Больше ничего не надо. Админ разрешил трансферить зону кому попало — это его проблема.

    Это то же самое, что давать root access на любой публичный ip с паролем qwerty.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.