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

[bga68comp]

Алексей Лукацкий

17 Января, 2018

Об утечках через 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 не ловят утечки через туннелирование конфиденциальной информации в разрешенные протоколы. Вообще с туннелированием они не работают.

Источник: https://www.securitylab.ru/blog/personal/Business_without_danger/343229.php