Всем привет! Меня зовут Алексей Романов, я руководитель направления развития облачных решений в компании BI.ZONE. В этой статье я хочу рассказать об интересном кейсе использования DNS-туннелей в современной реальности. Я, как и многие другие специалисты, считал, что DNS-туннели попросту неактуальны на текущий момент, так как данный транспорт требует много времени на передачу данных, а современные классы решений типа DNS filter, IDPS и NTA покрывают подобную технику. Однако не так давно вышел очень интересный ресерч о том, как malware-семплы могут дропаться через TXT-запись, об этом подробно говорилось в данной статье.

Поэтому я решил подсветить еще один интересный кейс использования DNS-туннелей злоумышленниками. 

Предыстория

Я наткнулся на одном закрытом даркнет-форуме на пост, где некий пользователь продает доступ к подломанным маршрутизаторам в инфраструктурах разных компаний, L3-коммутаторам, IP-камерам и другим IoT-устройствам. Казалось бы, очень старая история: еще известные ботнеты MIRAI или Qbot в свое время базировались на подломанных telnet-брутфорсом (и не только) IoT-устройствах. Но я все же решил потратить время и копнуть глубже, чтобы разобраться, как обстоят дела с этим. 

И вот какая последовательность атаки выстраивалась:

1. Злоумышленник выгружает доменные имена из ICANN или же IP-диапазоны стран/городов из https://suip.biz/ru/.

2. Собирает информацию об интересных таргетах через ripe.net или открытый passive DNS (это классический OSINT). 

3. Далее атакующий использует masscan или Angry IP Scanner и указывает пул портов, которые могут быть интересны: 8080, 80, 443, 88, 161, 162, 153, 1723, 137, 445, 3389, 3306, 5432, 22, 23, 25, 21 и подобные.

4. Если находит маршрутизатор, L3-коммутатор, IP-камеру или любое IoT-устройство, использует инструмент на Python с открытым исходным кодом routersploit и модуль autopwn, чтобы реализовать автоматизированный перебор известных техник веб-эксплуатации на основе CVE или же при помощи брутфорса.
   И знаете, в чем вся соль? В том, что большинство эксплоитов для популярных китайских камер будут актуальны для некоторых других IoT-устройств!
   Пример здесь. Эта вулна актуальна для некоторых версий прошивок MicroTik и Zyxel: /uapi-cgi/viewer/simple\_loglistjs.cgi?(){ :;}; {ls}. Это broken acces control (MFLAC, если быть точным) + SSTI (server-side template injection) + command injection.
   И вуаля! Атакующий делает wget (который есть в 99% прошивок в /bin/ и не удален, не переименован) на заранее поднятую VDS/VPS и загружает пейлоад под ARM, x86, MIPS, MIPSEL, SPARC и другую архитектуру! 
   Делается exec — устройство протроянено! Reverse remote access trojan или reverse shell в деле.

5. Ну а что дальше? Атакующий может прокинуть SOCKS proxy до LAN и начинает атаку уже во внутренней сети. И всё! Неважно, как защищены внешние веб-серверы или другие системы, если по итогу IP-адрес IoT торчит наружу и никаким образом не покрывается. И казалось бы, анализ трафика, контроль incoming-соединений... Но, как показывает практика, далеко не все заводят сетевое оборудование за мониторинг.

Самое интересное: на подобных устройствах нет антивирусных приложений и EDR-агентов. А значит, сделать exec очень легко, потому что syscall не мониторятся. Опять же мало кто собирает syslog с них. Именно поэтому IoT-устройства — один из удобных и легких таргетов для злоумышленников. 

Подломить подломили. Как сделать back-connect?

Посерчив чуть больше на этом даркнет-форуме, я наткнулся на продажу одного malware-семпла (полноценный C2 + C&C — панель управления) от того же автора, который продавал доступ к IoT в инфраструктурах разных компаний. Разумеется, автор гарантирует FUD (full undetectable EDR/AV support) за 145 долларов в месяц. Но это не так важно. Как мы уже обсудили ранее, EDR/AV на Linux-based-прошивках IoT нет (по крайней мере, я ни разу не видел). Здесь интересна другая деталь...

У малвари есть опция, которая позволяет поддерживать закрепление на устройствах в жестко сегментируемом и фильтруемом контуре. Да, когда злоумышленник атаковал какой-нибудь завод или производство, где сетевой контур обвешан PVLAN/VLAN и кучей средств сетевого мониторинга, и смог, например, закрепиться на L3-коммутаторе или маршрутизаторе, малварь может передавать отклики и команды с огромной задержкой и безумно низкой скоростью, но вшивая данные в информационные биты Do53-/DoT-/DoH-протоколов: бит-транзакции, RCODE, \*COUNT и подобные.

Разумеется, во многих закрытых сетях и DNS ограничен, но опять же не везде. И есть случаи, когда ограничения касаются всяких HTTP-/HTTPS-, SMB-, SIP-протоколов, но про DNS все забывают и спокойно его разрешают при формировании белых списков или вовсе составляют черный список запрещенных протоколов (тем самым существенно расширяя возможности для атакующего, так как протоколов для скрытной передачи трафика от malware-агента до панели управления очень много). 

Я крайне заинтересовался этим кейсом. Ладно бы помещать байт-код в Authority-секцию, в Additional-секцию или же по классике в Question-, Answer-секции либо в OPT RR при использовании EDNS0, но в HEADER?! Поэтому я принялся писать PoC этой истории, и вот что получилось в итоге:

unsigned short __do53_query(char *_qname, __do53_type _qtype, unsigned char *_wire)
{
  _wire[0] = // Вот здесь пейлоад
  _wire[1] = // Вот здесь пейлоад
  _wire[2] = 0x01;
  _wire[3] = 0x00;
  _wire[4] = 0x00;
  _wire[5] = 0x01;
  _wire[6] = 0x00;
  _wire[7] = 0x00;
  _wire[8] = 0x00;
  _wire[9] = 0x00;
  _wire[10] = 0x00;
  _wire[11] = 0x00;
 
  int query_lenght = __ascii_convertation_to_wire(_qname, &(_wire[12]));
  int nextLoc = 12 + query_lenght + 1;
 
  _wire[nextLoc] = 0x00;
  _wire[++nextLoc] = 0x01;
  _wire[++nextLoc] = 0x00;
  _wire[++nextLoc] = 0x01;
 
  return nextLoc + 1;
}

Да, у меня какая-нибудь команда ls будет выводиться условно день. Но, когда атакующий запаривается с сокрытием трафика, то чего бы и не подождать. Однако фишка здесь не в этом. Помимо захардкоженных команд С2-агента, та самая малварь с даркнет-форума предлагает «переход на другой транспорт».

То есть после того, как устройство подломлено, трафик идет на DNS-C&C-панель атакующего и отстукивает раз в несколько часов. И когда атакующий захочет переходить, допустим, на HTTP или любой другой протокол, то он просто в какой-то момент получает ответ в Additional-/Authority-секцию или в виде IPv6-адреса (16 байт) в рамках Do53-/DoT-/DoH-протоколов и далее исполняет переход уже на другой туннель.

Что мы в итоге имеем?

C2-агент идет к C&C-панели, и IDLE отстукивает данными в виде определенных битов, которые C&C понимает. И ходит так раз в час.

Если в C&C-панели есть команда, то в DNS answer прилетит в Additional-/Authority-секцию замаскированная хардкод-команда, которая позволит малвари выполнить какое-то действие. Агент может даже не отправить данные в ответ на «успешное исполнение», и атакующий может даже не увидеть результат. Но если там действие в формате «построй новый туннель через HTTP», «исполни функцию рекурсивного шифрования» или «активируй дроппер-функции», то будет ли ему нужен этот ответ? Нет, нужен будет такой же отстук от том, что малварь жива или успешно исполнилась, и это все в виде битов. Ну и конечно, в опциях есть возможность ответа на ту же команду ls. Только передавать все ответы будут также в виде битов. Долго.

Еще раз отмечу: в малвари есть функция, которая позволяет также получать ответные данные команды не в виде Authority-секции, а в виде IPv6-адреса. В 16 байтах. 

По сути, подломленное устройство просто будет резолвить раз в час один и тот же домен, где в FQDN не будет никаких аномалий, они будут в самой Do53-/DoT-/DoH-структуре пакета. Причем в единичных битах. 

Таким образом:

1. Ломается веб-приложение IoT-устройства.

2. Создается домен а-ля metrics-cisco.com или metrics-zyxel.com (что-то, похожее на оригинальный домен для сбора метрик или проверки обновлений прошивки).

3. Далее начинаем отстукиваться туда!

4. И все! Удачи решениям сетевого анализа что-то найти, когда rate limit не пробиваются, скорость на FQDN или отдельный FQDN не набирается за определенный промежуток времени и профилирование не отрабатывает корректно. 

А уже в момент развития атаки и нормального транспорта можно устроить вариативность через какие-то легитимные сервисы и решения, например GitHub. Правда, это явно неприменимо к IoT-устройствам — то, что сетевое устройство пошло на GitHub, уже будет отклонением от сетевого профиля.

И основная проблема здесь в том, что IoT-устройства, маршрутизаторы и коммутаторы постоянно находятся в публичной сети (даже неважно, статический адрес или динамический) и атакующий может просто их пробить и установить вредоносный семпл, а EDR-агентов там нет. И как итог — реализуется цепочка атаки. 

Важно не забывать о том, что сетевое оборудование на периметре нужно защищать и не оставлять без присмотра. На практике многие компании этим пренебрегают. Результат этого — успешные проекты red team или реальные случаи подлома инфраструктуры атакующими именно через IoT-устройства.