Ситуация: новая волна атак с перехватом DNS-запросов — разбираем базовые методы защиты

    Специалисты по ИБ зафиксировали рост числа атак DNS hijacking на сайты частных и правительственных компаний. Рассказываем, кто пострадал и как защититься.


    / Flickr / F Delventhal / CC BY / Фото изменено

    Что произошло


    Организация FireEye, занимающаяся вопросами ИБ, в прошлом месяце опубликовала отчёт, в котором сообщила о масштабной волне атак на частные компании и правительственные организации. Злоумышленники использовали технику перехвата DNS, или DNS hijacking. Они перекрывали конфигурации TCP/IP на компьютере жертвы и переводили все запросы на подложный DNS-сервер. Это позволило им направить трафик пользователя на собственные веб-серверы и применить их для кражи персональных данных.

    По информации FireEye, рост числа подобных атак начал расти в январе 2017 года. Хакеры делают своей целью домены из Европы, Северной Америки, Ближнего Востока и Северной Африки. Пострадали минимум шесть доменов федеральных агентств США и сайты правительств стран Ближнего Востока.

    Какие методы используют взломщики


    Специалисты FireEye в своем отчете отмечают три схемы подмены DNS, которыми пользуются злоумышленники. Первую из них описывали сотрудники ИБ-подразделения Cisco — Talos. Злоумышленники взламывали системы DNS-провайдеров (пока достоверно неизвестно каким образом), а затем изменяли запись DNS A, связывая настоящий домен с принадлежащим хакерам IP.

    В результате жертвы попадали на аналогичный оригинальному по внешнему виду сайт. Чтобы добиться максимального сходства, для поддельного сайта даже изготавливали криптографические сертификаты Let’s Encrypt. При этом запросы с поддельного ресурса перенаправляли на оригинальный. Фальшивая страница возвращала настоящие ответы, и подмену можно было заметить только по более долгой загрузке страниц.

    Эту схему атаки применили для взлома сайтов правительства ОАЭ, министерства финансов Ливана, а также авиакомпании Middle East Airlines. Хакеры перехватывали весь трафик и перенаправляли его на IP-адрес 185.20.187.8. По словам специалистов Talos, злоумышленники крали пароли от почтовых ящиков сотрудников организаций и данные для доступа к VPN-сервисам.

    Вторая схема злоумышленников связана с изменением в регистре DNS-адресов NS-записи домена. Она отвечает не за одну страницу конкретного домена (например: mail.victim.com), а за все ссылки вида x.victim.com. В остальном метод похож на первый: взломщики создавали копию оригинального сайта и перенаправляли на него пользователей, после чего крали данные.

    Третий метод часто использовался в связке с первыми двумя. Посетителей сайта не сразу отправляли на поддельную страницу. Сперва они переходили на дополнительный сервис — DNS Redirector. Он распознавал, откуда пользователь отправляет DNS-запрос. Если посетитель заходил на страницу из сети компании-жертвы, его перенаправляли на поддельную копию сайта. Другим пользователям Redirector возвращал настоящий IP-адрес, и человек попадал на оригинальный ресурс.

    Что думают об атаках


    Специалисты пока не могут оценить точный ущерб от взломов, так как о новых жертвах хакеров становится известно и после публикации отчета. Поэтому на проблему обратило внимание даже Министерство внутренней безопасности США (DHS). Специалисты организации опубликовали директиву, в которой сформировали список обязательных требований для других федеральных агентств. К примеру, DHS требуют от правительственных подразделений обновить пароли от учётных записей администраторов, включить многофакторную аутентификацию в DNS-аккаунтах и провести проверку всех DNS-записей.


    / Wikimedia / ANIL KUMAR BOSE / CC BY-SA

    Рекомендации из директивы все агентства должны внедрить за десять рабочих дней. Согласно изданию CyberScoop, такой срок достаточно редко встречается в документах Министерства. Это указывает на «экстренный» статус директивы.

    Примечательной серию взломов назвали и представители провайдеров DNS-серверов. По словам генерального директора DNS-хостинга NS1 Криса Биверса (Kris Beevers), самый важный вывод из последних атак — организации не используют базовые средства защиты. По своей сути атаки довольно просты, и многие из них можно было предотвратить.

    Как защититься


    В своем отчёте специалисты FireEye приводят несколько способов защиты, которые помогут организациям предотвратить атаки DNS hijacking:

    Подключить многофакторную аутентификацию (MFA). Это одно из требований, которые предьявило Министерство внутренней безопасности США к господразделениям. Многофакторная аутентификация усложняет задачу для злоумышленников по подключению к панели управления с настройками DNS.

    К примеру, 2FA смогла бы помешать злоумышленникам подменить сайт Linux.org в начале декабря прошлого года. К счастью, атака ограничилась только вандализмом с переключением на другой сервер в DNS.

    «Двухфакторная аутентификация — простая мера безопасности, которая поможет защититься от атак с подменой ответа DNS-сервера, — комментирует начальник отдела развития IaaS-провайдера 1cloud.ru Сергей Белкин. — Облачные провайдеры могут помочь с защитой. В частности, пользователи нашего бесплатного DNS-хостинга могут быстро подключить 2FA с помощью подготовленной инструкции. Дополнительно клиенты могут отследить в своём профиле все изменения в DNS-записях, чтобы убедиться в их достоверности».

    Проверить логи сертификатов. ИБ-специалисты советуют администраторам перепроверить сертификаты с помощью инструмента Certificate Transparency. Это IETF стандарт и открытый проект, который хранит информацию обо всех сертификатах, выпущенных для конкретного домена.

    Если окажется, что какие-то из них были сфальсифицированы, на сертификат можно пожаловаться и отозвать его. Отслеживать изменения в логах Certificate Transparency помогут специальные инструменты, например SSLMate.

    Перейти на DNS-over-TLS. Для предотвращения атак с перехватом DNS некоторые компании также используют DNS-over-TLS (DoT). Он шифрует и проверяет запросы пользователя к DNS-серверу и не даёт злоумышленникам подменить данные. Например, недавно поддержку протокола внедрили в Google Public DNS.

    Перспективы


    Атак с перехватом DNS становится всё больше, причём не всегда хакеров интересуют данные пользователей. Недавно десятки взломанных доменов, в том числе от компаний Mozilla и Yelp, использовали для рассылки мошеннических писем. В этом случае хакеры применяли другую схему атак — они брали контроль над доменами, которые компании перестали использовать, но не удалили из DNS-записей провайдера.

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

    Часто DNS-серверы вендоров, в отличие от систем компаний, защищены дополнительным протоколом DNSSEC. Он защищает все DNS-записи цифровой подписью, которую можно создать только с помощью секретного ключа. Произвольные данные в такую систему хакеры внести не могут, поэтому подменить ответ от сервера становится сложнее.

    Наши посты из корпоративного блога:

    • +11
    • 5,8k
    • 7
    1cloud.ru
    270,00
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией

    Комментарии 7

      0
      Разве DNS-over-TLS поможет, если взломали DNS-провайдера и подменили вашу запись? 2FA и сертификаты здесь тоже не спасут.
        0
        Всё равно не совсем понятно, как происходил взлом, или в итоге виноваты владельцы сайтов. Чтобы подмена DNS не имела смысла, достаточно включить https (+ перенаправление на него с http), включить HSTS и добавить домен в HSTS preload list популярных браузеров, чтобы новых клиентов сразу перебрасывало на https. В этом случае взлом сводится к похищению закрытого ключа с хостинга, что значительно сложнее подмены DNS.

        Злоумышленники взламывали системы DNS-провайдеров (пока достоверно неизвестно каким образом), а затем изменяли запись DNS A, связывая настоящий домен с принадлежащим хакерам IP.
        В результате жертвы попадали на аналогичный оригинальному по внешнему виду сайт. Чтобы добиться максимального сходства, для поддельного сайта даже изготавливали криптографические сертификаты Let’s Encrypt. При этом запросы с поддельного ресурса перенаправляли на оригинальный. Фальшивая страница возвращала настоящие ответы, и подмену можно было заметить только по более долгой загрузке страниц.

        Какая-то дичь написана, нельзя получить сертификат Let’s Encrypt на неподконтрольное имя домена, для этого нужен взлом хостинга оригинального домена. И потом, даже если DNS провайдера подменён, браузер сразу же предупредит о фишинге. В этом и есть смысл https, а здесь по сути рассказывается о mitm без https.

        Вторая схема злоумышленников связана с изменением в регистре DNS-адресов NS-записи домена. Она отвечает не за одну страницу конкретного домена (например: mail.victim.com), а за все ссылки вида x.victim.com. В остальном метод похож на первый: взломщики создавали копию оригинального сайта и перенаправляли на него пользователей, после чего крали данные.

        Опять же это можно сделать только без https. Даже если владельцы сайта забыли настроить HSTS, на http попадут только новые пользователи, а у них красть нечего.

        Посетителей сайта не сразу отправляли на поддельную страницу. Сперва они переходили на дополнительный сервис — DNS Redirector.

        Уже тогда браузер предупреждал бы о фишинге, и остальные программы отказывались бы работать с сайтом без корректного сертификата.
          +1
          В статье FireEye авторы пишут, что сертификаты Lets Encrypt браузер считал валидными и не выдавал никаких ошибок.

          «Let’s Encrypt certificate allows browsers to establish a connection without any certificate errors as Let's Encrypt Authority X3 is trusted.»

          Что касается HTTPS, то могу только предположить: раз волна атак идет довольно давно, и не все еще используют HTTPS, то схема работала
            +1
            Нужно чтобы был не любой сертификат Let’s Encrypt, а по имени домена, и чтобы его получить требуется контроль над хостингом. При таком уровне доступа нет смысла менять DNS.
              0
              Если учесть что
              Злоумышленники взламывали системы DNS-провайдеров

              То выпустить сертификат Let's Encrypt не должно составить большого труда — Lets encrypt (Provisioning a DNS record under example.com)
              +1
              Чтоб получить сертификат LE на домен, вам надо сначала сам LE убедить в том что домен смотрит на подконтрольный вам IP так?
              А как это можно сделать без получения доступа к админке/базе регистратора домена я не особо представляю.
              Выводом можно было написать — для регистрации доменов используемых в корпоративных целях или связанных с ценной информацией используйте надёжных регистраторов, ну и плюсом обычные советы по паролям.
              А так, если у вас уже спёрли домен, и проксируют с него все запросы на настоящий туды-сюды, многофакторная авторизация не особо спасёт, наверное.
            0
            Как я понял, поддельный сайт работал по HTTP и пользователь не обращал на это внимание или по HTTPS, но с опечаткой в названии и валидным сертификатом Let's encrypt.

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

            Самое читаемое