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

22.01.2018

В далёком 1996-м году была очень популярная вредоносная программа Loki, которая позволяла организовывать туннели внутри протокола ICMP. обычно этот протокол не контролируемого распространенными на тот момент межсетевыми экранами. Идея Loki была проста - путем обмена командами ECHO в поле данных пакета ICMP можно было разместить все, что угодно.

В далёком 1996-м году была очень популярная вредоносная программа Loki, что дает возможность организовывать туннели внутри протокола ICMP. Обычно этот протокол не контролируемого распространенными на тот момент межсетевыми экранами. Идея Loki была проста - путем обмена командами ECHO в поле данных пакета ICMP можно было разместить все, что угодно.

Обнаруживать такие атаки на МСЭ очень сложно и помогали их находить только IDS, для которых прописывались правила, отслеживающие длину запросов и ответов ICMP, а также смотрящие за тем, чтобы поле с информацией ICMP-пакета было пустым (с нулевой длиной). С разной эффективностью похожий метод использовался некоторыми другими вредоносными программами, которые появлялись уже позже, в 2000-х годах, и в 2010-х.

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

Для функционирования DNSFS нужны открытые DNS-резольверы и чем их больше, тем отказоустойчивее будет схема. В принципе доступ к таким серверам должен блокироваться извне на МСЭ, но как часто бывает, многие забывают или не могут правильно настроить безопасность своей инфраструктуры и это приводит к дырам в системе защиты. Автор DNSFS с помощью утилиты masscan просканировал все доступное Интернет-пространство и обнаружил около 4 миллионов открытых DNS-резольверов. Это позволило ему создать работающий прототип распределенной файловой системы на базе DNS, который может быть использован для различных целей, включая и вредоносные. Меня же во всей этой конструкции заинтересовала сама идея туннелирования в рамках DNS-трафика, который, в отличие от ICMP, очень часто разрешен на периметровых МСЭ, которые не умеют его контролировать.

 

 

На изображении выше показано распределение длин имен субдоменов. Логично предположить, что на первом месте у нас будут субдомены длиной 3 символа (www). А вот дальше длины субдоменов будут идти по нисходящей и мы увидим, что в обычной жизни сложно встретить субдомены длиной более 30 символов. Даже DGA-домены обычно гораздо короче. Но если задаться вопросом, а могут ли встречаться субдомены длиной более 30 или 50 или даже 100 символов, то мы увидим, что на границе в 200 символов проявляется аномалий - число субдоменов такой длины непропорционально высоко. Почему?

Ответ прост - злоумышленники используют особенности работы DNS в качестве инструмента для утечки данных (не фишинг, не DGA, не редиректы, не Fast Flux, а именно утечка), которые скрываются в названии субдомена, направленного на DNS-сервер, находящийся под контролем злоумышленников. Именно на нем происходит распознавание (часто и расшифрование) информации в пришедшем DNS-запросе. Такая вот проблема, которая находится вне контроля абсолютного большинства современных МСЭ, даже NGFW. Да и IPS тоже не всегда способны ловить такие вещи, хотя на них можно создать правила, отслеживающие длину DNS-запроса.

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

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

По материалам  портала channel4it.com