Об утечках через DNS, которые не ловит ни одна DLP

Угрозы
Наверное то есть, кто давно занимается информационной безопасностью помнят, что в 1996-м году была очень популярная вредоносная программа Loki, которая позволяла организовывать туннели внутри ICMP-протокола, обычно не контролируемого распространенными на тот момент межсетевыми экранами. Идея Loki была проста — путем обмена командами ECHO REQUEST и ECHO REPLY (то есть обычный Ping) в поле данных пакета ICMP можно было засунуть все, что угодно. Детектировать такие атаки на МСЭ почти невозможно и помогали их обнаруживать только IDS, для которых писались правила, отслеживающие длину запросов и ответов ICMP (она должна быть равна 42 байтам), а также смотрящие за тем, чтобы поле данных ICMP-пакета было пустым (с нулевой длиной). С разной эффективностью схожий метод использовался некоторыми другими вредоносными программами, которые появлялись уже позже, в 2000-х годах, и в 2010-х.
Интересной интерпретацией данного метода стала утилита PingFS, которая позволяла, по словам ее автора, создать истинно облачное хранилище данных. PingFS — это файловая система, которая хранится в самом Интернете, а не каком-то из отдельных серверов или группе серверов. Все просто — данные о файлах постоянно циркулируют между узлом и Интернет в обычных пингах (и ответах на них). Понятно, что это достаточно вырожденный случай и в реальной жизни врядли у PingFS найдется применение, исключая небольшое количество не очень больших по объему файлов — все-таки производительность такой файловой системы невысока. Да и потери пакетов могут привести к сбою в «файловой системе». Но сама идея достаточно интересна и ее подхватили и другие авторы. Например, создав DNSFS, утилиту, работающую по тому же самому принципу, но обмен происходит по протоколу DNS и данные о файлах хранятся в кэше DNS, что устраняет ряд проблем, имеющихся у PingFS.
Для работы DNSFS нужны открытые DNS-резольверы и чем их больше, тем отказоустойчивее будет схема. В принципе доступ к таким серверам должен блокироваться извне на МСЭ, но как часто бывает, многие забывают или не могут правильно настроить безопасность своей инфраструктуры и это приводит к дырам в системе защиты. Автор DNSFS с помощью утилиты masscan происканировал все доступное Интернет-пространство и обнаружил около 4 миллионов открытых DNS-резольверов (Россия на 4-м месте по их числу после Китая, США и Южной Кореи). Это позволило ему создать работающий прототип распределенной файловой системы на базе DNS, который может быть использован для различных целей, включая и вредоносные. Меня же во всей этой конструкции заинтересовала сама идея туннелирования в рамках DNS-трафика, который, в отличие от ICMP, очень часто разрешен на периметровых МСЭ, которые не умеют его контролировать.
Посмотрите на эту картинку:
Она отражает распределение длин имен субдоменов. Логично предположить, что на первом месте у нас будут субдомены длиной 3 символа (пресловутый www). А вот дальше длины субдоменов будут идти по нисходящей и мы увидим, что в обычной жизни сложно встретить субдомены длиной более 30 символов. Даже DGA-домены обычно гораздо короче. Но если задаться вопросом, а могут ли встречаться субдомены длиной более 30 или 50 или даже 100 символов, то мы увидим, что на границе в 200 символов проявляется аномалий — число субдоменов такой длины непропорционально высоко. Почему?

Ответ прост — злоумышленники используют особенности работы DNS в качестве инструмента для утечки данных (не фишинг, не DGA, не редиректы, не Fast Flux, а именно утечка), которые скрываются в названии субдомена, направленного на DNS-сервер, находящийся под контролем злоумышленников. Именно на нем происходит распознавание (часто и расшифрование) информации в пришедшем DNS-запросе. Такая вот проблемка, которая находится вне контроля абсолютного большинства современных МСЭ, даже NGFW. Да и IPS тоже не всегда способны ловить такие вещи, хотя на них можно создать правила, отслеживающие длину DNS-запроса.
В любом случае этот пример показывает, что мониторинг трафика — задача важная и опираться в ней нужно не только на привычные периметровые средства защиты, но и на иные решения, которые позволяют заглядывать внутрь различных протоколов и выявлять в них аномалии. Это и решения класса NTA, и защищенные DNS-сервера с функцией инспекции трафика, и другие типы средств контроля и защиты трафика.
ЗЫ. Если вдруг вам тема безопасности DNS интересна, то 24-го января пройдет бесплатное онлайн-мероприятие по этой теме, где будут рассмотрены различные атаки на DNS и способы их обнаружения и нейтрализации — платные и нет, коммерческие и open source.
ЗЗЫ. Да, про DLP забыл упомянуть. Так вот DLP не ловят утечки через туннелирование конфиденциальной информации в разрешенные протоколы. Вообще с туннелированием они не работают. 
Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

Нажимая кнопку "Отправить", я даю свое согласие на обработку персональных данных (если вдруг они указаны в комментарии) в соответствие с политикой конфиденциальности. Также я соглашаюсь с тем, что в своем комментарии не раскрываю никаких сведений, составляющих государственную тайну, а также никакой иной информации, охраняемой законом (для этого используйте иные способы :-) ), если это не разрешено ее владельцем. Ваш комментарий может появиться не сразу, а после модерации (так бывает не всегда, но бывает).

  1. Vadim

    DNS Exfiltrator: http://arjamasaha.com/2018/01/14/dnsexfiltrator-data-exfiltration-over-dns-request-covert-channel/

    Ответить