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
    Метки:
    Поделиться публикацией
    Комментарии 29
    • +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 января, спасибо человеку, который о ней сообщил.
                      • 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.
                                • +1
                                  Чисто из интереса стянул с сайта центробанка около 1000 доменов, приписываемых банкам. Получил около 80-90 трансферов. Из топ-50 банков — 5. Подумываю о засылке списка в финцерт…

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