Правительство США и ряд ведущих компаний в области информационной безопасности недавно предупредили о серии очень сложных и распространённых атак DNS hijacking, которые позволили хакерам предположительно из Ирана получить огромное количество паролей электронной почты и других конфиденциальных данных у нескольких правительств и частных компаний. Но до сих пор подробности произошедшего и список жертв хранились в тайне.

В этой статье постараемся оценить масштаб атак и проследить эту чрезвычайно успешную кампанию кибершпионажа от начала и до каскадной серии сбоев у ключевых поставщиков инфраструктуры интернета.

Прежде чем углубиться в исследование, полезно рассмотреть факты, раскрытые публично. 27 ноября 2018 года исследовательское подразделение Talos компании Cisco опубликовало отчёт с описанием продвинутой кампании по кибершпионажу, названной DNSpionage.

DNS означает Domain Name System: система доменных имён, которая служит своего рода телефонной книгой интернета, транслируя удобные названия веб-сайтов (example.com) в числовой компьютерный IP-адрес.

Эксперты Talos написали, что благодаря атаке DNSpionage злоумышленники смогли получить учётные данные электронной почты и других сервисов ряда государственных организаций и частных компаний в Ливане и Объединенных Арабских Эмиратах путём смены DNS-записей, так что весь трафик электронной почты и виртуальных частных сетей (VPN) был перенаправлен на IP-адрес, контролируемый злоумышленниками.

Talos сообщила, что благодаря DNS hijacking хакеры сумели получить сертификаты шифрования SSL для целевых доменов (в том числе webmail.finance.gov.lb), что позволило им расшифровать трафик с аккаунтов электронной почты и VPN.

9 января 2019 года поставщик услуг безопасности FireEye опубликовал свой отчёт «Глобальная кампания по захвату DNS: массовые манипуляции с записями DNS», в котором гораздо больше технических подробностей, как проведена операция, но мало деталей о жертвах.

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

Ситуация изменилась 25 января 2019 года, когда специалисты по информационной безопасности CrowdStrike выложили список практически всех IP-адресов, которые использовались в хакерской операции на сегодняшний день. Остальная часть этой истории основана на открытых данных и интервью, которые мы провели, пытаясь пролить больше света на истинные масштабы этой экстраординарной атаки, продолжающейся до сих пор.

«Пассивный» DNS

Для начала я взял все IP-адреса, упомянутые в отчёте CrowdStrike, и проверил их в сервисах Farsight Security и SecurityTrails, которые пассивно собирают данные об изменениях записей DNS, связанных с десятками миллионов доменов по всему миру.

Обратная проверка по этим IP-адресам позволила убедиться, что в последние несколько месяцев 2018 года хакерам DNSpionage удалось поставить под угрозу ключевые компоненты инфраструктуры DNS для более чем 50 ближневосточных компаний и правительственных учреждений, включая цели в Албании, Кипре, Египте, Ираке, Иордании, Кувейте, Ливане, Ливии, Саудовской Аравии и ОАЭ.

Например, эти «пассивные данные» показывают, что злоумышленники смогли перехватить DNS-записи домена mail.gov.ae, который обслуживает электронную почту правительственных учреждений ОАЭ. Вот лишь несколько других интересных доменов, успешно скомпрометированных в рамках операции:

-nsa.gov.iq: Совет национальной безопасности Ирака
-webmail.mofa.gov.ae: электронная почта Министерства иностранных дел ОАЭ
-shish.gov.al: государственная разведывательная служба Албании
-mail.mfa.gov.eg: почтовый сервер министерства иностранных дел Египта
-mod.gov.eg: министерство обороны Египта
-embassy.ly: посольство Ливии
-owa.e-albania.al: портал Outlook Web Access для электронного правительства Албании
-mail.dgca.gov.kw: почтовый сервер бюро гражданской авиации Кувейта
-gid.gov.jo: Главное разведывательное управление Иордании
-adpvpn.adpolice.gov.ae:VPN-сервис полиции Абу-Даби
-mail.asp.gov.al: электронная почта албанской государственной полиции
-owa.gov.cy: портал Microsoft Outlook Web Access для правительства Кипра
-webmail.finance.gov.lb: почта министерства финансов Ливана
-mail.petroleum.gov.eg: министерство нефти Египта
-mail.cyta.com.cy: кипрский телекоммуникационный и интернет-провайдер Cyta
-mail.mea.com.lb: почтовый сервер Middle East Airlines

Пассивные данные DNS от Farsight и SecurityTrails также дают подсказки, когда «захвачен» каждый из этих доменов. В большинстве случаев злоумышленники, видимо, изменили записи DNS для этих доменов (чуть позже расскажем, как это сделано), чтобы они указывали на подконтрольные им серверы в Европе.

Вскоре после начала атаки — иногда спустя недели, иногда дни или часы — злоумышленники смогли получить SSL-сертификаты этих доменов от центров сертификации Comodo и/или Let’s Encrypt. Подготовку нескольких атак можно проследить по crt.sh: база всех новых SSL-сертификатов с функцией поиска.

Рассмотрим подробнее один пример. Отчёт CrowdStrike упоминает IP-адрес 139.59.134[.]216 (см. выше), на котором, согласно Farsight, в течение многих лет размещались семь различных доменов. Но в декабре 2018 года на этом адресе появились два новых, включая домены в Ливане и — что любопытно — Швеции.

Первый из них ns0.idm.сеть.lb — сервер ливанского интернет-провайдера IDM. С начала 2014 года по декабрь 2018 года запись ns0.idm.net.lb указывала на ливанский IP-адрес 194.126.10[.]18. Но на скриншоте от Farsight ниже видно, что 18 декабря 2018 года, DNS-записи для этого интернет-провайдера изменились, перенаправив трафик, предназначенный для IDM, к хостинг-провайдеру в Германии (адрес 139.59.134[.]216).


Обратите внимание, какие ещё домены сидят на этом IP-адресе 139.59.134[.]216 вместе с доменом IDM, согласно Farsight:


DNS-записи доменов sa1.dnsnode.net и fork.sth.dnsnode.net в декабре тоже изменились со своих законных шведских адресов на IP немецкого хостера. Эти домены принадлежат Netnod Internet Exchange, крупному глобальному DNS-провайдеру из Швеции. Netnod также управляет одним из 13 корневых серверов DNS: критически важный ресурс, лежащий в основе глобальной системы DNS.

Чуть позже вернёмся к компании Netnod. Но сначала давайте посмотрим на другой IP-адрес, указанный в отчёте CrowdStrike как часть инфраструктуры, пострадавшей от атаки DNSpionage: 82.196.11[.]127. На этом голладском адресе также размещается домен mmfasi[.]com. По информации CrowdStrike, это один из доменов злоумышленников, который использовался в качестве DNS-сервера для некоторых из захваченных доменов.



Как видим, на 82.196.11[.]127 временно размещалась другая пара DNS-серверов Netnod, а также сервер ns.anycast.woodynet.net. Он назван по прозвищу Билла Вудкока, исполнительного директора Packet Clearing House (PCH).

PCH — некоммерческая организация из Северной Калифорнии, которая тоже управляет значительной частью мировой инфраструктуры DNS, в том числе обслуживая более 500 доменов верхнего уровня и ряд доменов верхнего уровня Ближнего Востока, пострадавших в операции DNSpionage.

Атака на регистраторов

14 февраля мы связались с генеральным директором Netnod Ларсом Майклом Йогбеком. Он подтвердил, что часть DNS-инфраструктуры Netnod была захвачена в конце декабря 2018 года и начале января 2019 года после того, как злоумышленники получили доступ к учётным записям регистратора.

Йогбек сослался на заявление компании, опубликованное 5 февраля. В нём говорится, что Netnod узнала о своей причастности к атаке 2 января, после чего на протяжении всего времени действовала в контакте со всеми заинтересованными сторонами и клиентами.

«Как участник международного сотрудничества в области безопасности, 2 января 2019 года Netnod стало известно, что мы оказались втянуты в эту серию атак и подверглись атаке типа MiTM (человек-в-середине), — говорится в заявлении. — Компания Netnod не является конечной целью хакеров. По имеющейся информации, их цель состоит в сборе учётных данных для интернет-служб в странах за пределами Швеции».

15 февраля Билл Вудкок из PCH в интервью признался мне, что части инфраструктуры его организации тоже были скомпрометированы.

После получения неавторизованного доступа хакеры переписали записи доменов pch.net и dnsnode.net на те же сервера немецкого доменного регистратора Key-Systems GmbH и шведской компании Frobbit.se. Последняя является реселлером Key Systems, и часть интернет-инфраструктуры у них совпадает.

Вудкок сказал, что с помощью фишинга хакеры выманили учётные данные, которые PCH использовал для отправки сигнальных сообщений, известных как Extensible Provisioning Protocol (EPP) или «расширяемый протокол предоставления информации». Это малоизвестный интерфейс, своего рода бэкенд глобальной системы DNS, позволяющий регистраторам доменов уведомлять региональные реестры (например, Verisign) об изменениях в доменных записях, включая регистрации новых доменов, изменения и передачи.

«В начале января Key-Systems сообщила, что их интерфейсом EPP воспользовались посторонние лица, укравшие учётные данные», — сказал Вудкок.

Key-Systems отказалась комментировать историю. Она заявила, что не обсуждает детали бизнеса своих клиентов-реселлеров.

Официальное заявление Netnod о нападении адресует дальнейшие запросы директору по безопасности Патрику Фёльтстрёму, который также является совладельцем Frobbit.se.

В переписке с нами Фёльтстрём сказал, что хакерам удалось отправить EPP-инструкции в различные реестры как от имени Frobbit, так и Key Systems.

«С моей точки зрения, очевидно, что это ранняя версия будущей серьёзной атаки на EPP, — написал Фёльтстрём. — То есть целью было отправить в реестры правильные EPP-команды. Лично меня очень пугает то, что может произойти в будущем. Должны ли реестры доверять всем командам от регистраторов? У нас всегда будут уязвимые регистраторы, верно?»

DNSSEC

Один из наиболее интересных аспектов этих атак — то, что Netnod и PCH являются громкими сторонниками и последователями DNSSEC, технологии для защиты именно от атак такого типа, какой сумели использовать хакеры DNSpionage.



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

Хотя DNSSEC может быть эффективным инструментом для смягчения подобных атак, только около 20% основных сетей и сайтов в мире включили поддержку этого протокола, согласно исследованию APNIC, интернет-регистратору Азиатско-Тихоокеанского региона.

Йогбек сказал, что инфраструктура Netnod подверглась трём атакам в рамках операции DNSpionage. Первые две произошли в двухнедельном промежутке между 14 декабря 2018 года и 2 января 2019 года и были нацелены на серверы, не защищённые DNSSEC.

Однако третья атака между 29 декабря и 2 января произведена на инфраструктуру Netnod, защищённую DNSSEC и обслуживающую собственную внутреннюю сеть электронной почты. Поскольку у злоумышленников уже был доступ к системам регистратора, они сумели ненадолго отключить эту защиту — по крайней мере, этого времени хватило, чтобы заполучить SSL-сертификаты двух почтовых серверов Netnod.

Когда злоумышленники получили сертификаты, то заново запустили DNSSEC на целевых серверах, вероятно, готовясь ко второму этапу атаки — перенаправлению почтового трафика на свои серверы. Но Йогбек говорит, что по какой-то причине злоумышленники не отключили DNSSEC повторно, когда начали перенаправлять трафик.

«К счастью для нас, они забыли его отключить в момент начала MiTM-атаки, — сказал он. — Будь они более квалифицированными, то удалили бы DNSSEC с домена, что вполне могли сделать».

Вудкок говорит, что PCH проверяет DNSSEC на всей инфраструктуре, но при этом не все клиенты компании настроили системы для полной реализации технологии. Это особенно относится к клиентам из стран Ближнего Востока, на которых нацелена атака DNSpionage.

Вудкок сказал, что инфраструктура PCH подверглась нападению DNSpionage четыре раза с 13 декабря 2018 года по 2 января 2019 года. Каждый раз хакеры использовали инструменты для перехвата трафика с учётными данными в течение примерно одного часа, а затем сворачивались и возвращали сеть в исходное состояние.

Наблюдение дольше часа было бы избыточным, ведь большинство современных смартфонов настроены постоянно проверять электронную почту. Таким образом, всего за час хакеры смогли собрать очень большое количество учётных данных.

2 января 2019 года — в тот же день, когда состоялась атака на внутренние почтовые серверы Netnod — хакеры напрямую атаковали PCH, заполучив SSL-сертификаты Comodo двух доменов PCH, через которые тоже идёт внутренняя почта компании.

Вудкок сказал, что благодаря DNSSEC атаку удалось почти полностью нейтрализовать, но хакеры смогли получить учётные данные электронной почты двух сотрудников, которые в то время были в отпуске. Их мобильные устройства загружали почту через WiFi в гостинице, поэтому (по условиям предоставления сервиса WiFi) использовали DNS-серверы отеля, а не системы с поддержкой DNNSEC от PCH.

«Оба пострадавших в это время находились в отпуске со своими iPhone и им пришлось пройти через скомпрометированные порталы при получении почты, — сказал Вудкок. — При доступе им пришлось отключить наши серверы имён, и в течение этого времени их почтовые клиенты проверяли новую почту. Если не считать этого, DNSSEC спасла нас от полного захвата».

Поскольку PCH защищает свои домены с помощью DNSSEC, практический эффект от взлома почтовой инфраструктуры заключался в том, что в течение примерно часа никто, кроме двух удалённых сотрудников, не получал писем.

«По сути, для всех наших пользователей почтовый сервер был недоступен в течение короткого периода времени, — сказал Вудкок. — Люди просто смотрели на телефон, не видели новых писем и думали: странно, проверю позже. И когда они проверяли в следующий раз, всё работало нормально. Группа наших сотрудников заметила краткосрочное отключение почтового сервиса, но это не стало слишком серьёзной проблемой, чтобы началось обсуждение или кто-то зарегистрировал тикет».

Но хакеров DNSpionage это не остановило. В рассылке для клиентов PCH рассказала, что проведённое расследование установило взлом сайта с базой данных пользователей 24 января. База содержит имена пользователей, хэши паролей bcrypt, электронные письма, адреса и названия организаций.

«Мы не видим свидетельств, что злоумышленники осуществили доступ к базе, — говорится в сообщении. — Таким образом, мы сообщаем эту информацию в целях прозрачности и предосторожности, а не потому что считаем данные скомпрометированными».

Продвинутый уровень

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

Даже для тех компаний, которые пытаются контролировать свою DNS-инфраструктуру на предмет подозрительных изменений, некоторые службы мониторинга проверяют DNS-записи пассивно или только раз в день. Вудкок подтвердил, что PCH полагается не менее чем на три системы мониторинга, но ни одна из них не предупредила о часовых угонах DNS-записей, которые поразили системы PCH.

Вудкок сказал, что с тех пор PCH внедрила собственную систему мониторинга DNS-инфраструктуры несколько раз в час, которая немедленно предупреждает о любых изменениях.

Йогбек сообщил, что Netnod тоже усилила мониторинг и удвоила усилия по внедрению всех доступных опций безопасности доменной инфраструктуры. Например, раньше компания не блокировала записи для всех своих доменов. Такая защита предусматривает дополнительную аутентификацию перед внесением любых изменений в записи.

«Нам очень жаль, что мы не обеспечили максимальную защиту наших клиентов, но мы сами стали жертвой в цепочке атак, — сказал Йогбек. — После ограбления вы можете установить лучший замок и надеяться, что теперь повторить подобное станет сложнее. Я действительно могу сказать, что мы многому научились, став жертвой этого нападения, и сейчас чувствуем себя гораздо увереннее, чем раньше».

Вудкок обеспокоен тем, что ответственные за внедрение новых протоколов и другие сервисы инфраструктуры всерьёз не воспринимают глобальную угрозу DNS-атак. Он уверен, что хакеры DNSpionage взломают ещё много компаний и организаций в ближайшие месяцы и годы.

«Битва идёт прямо сейчас, — сказал он. — Иранцы проводят эти атаки не для краткосрочного эффекта. Они пытаются проникнуть в интернет-инфраструктуру достаточно глубоко, чтобы совершить что им захочется в любой момент. Они хотят обеспечить себе как можно больше вариантов для манёвра в будущем».

Рекомендации

Джон Крейн — руководитель по вопросам безопасности, стабильности и отказоустойчивости ICANN, некоммерческой организации, которая курирует глобальную индустрию доменных имен. Он говорит, что многие методы профилактики и защиты, которые могут затруднить злоумышленникам захват доменов или инфраструктуры DNS, известны уже более десяти лет.

«Многое сводится к гигиене данных, — сказал Крейн. — Ни крупные организации, ни самый малый бизнес, не обращают внимания на некоторые очень простые методы безопасности, такие как многофакторная аутентификация. В наши дни, если у вас неоптимальная защита, вас взломают. Такова реальность сегодняшнего дня. Мы видим в интернете гораздо более изощрённых противников, и если вы не обеспечиваете базовой защиты, они ударят по вам».

Некоторые из передовых методов защиты для организаций:

• Использовать DNSSEC (как для подписи, так и для проверки ответов)
  
• Использовать функции регистрации, такие как блокировка записи (Registry Lock), которые помогают защитить записи доменных имен от изменения
  
• Использовать списки контроля доступа для приложений, интернет-трафика и мониторинга
  
• Использовать двухфакторную аутентификацию и требовать её использования всеми соответствующими пользователями и субподрядчиками
  
• В случаях, когда применяются пароли, выбирать уникальные пароли и рассмотреть менеджеры паролей
  
• Проверять аккаунты у регистраторов и других поставщиков
  
• Проводить мониторинг сертификатов, например, с помощью Certificate Transparency Logs