Забросить shell-код на удаленную машину и застолбить там back-door -это только половина дела. А что делать дальше, мы подумали? Необходимоскрыть свой IP-адрес и обойти все брандмауэры, не оставляя никакихследов в логах, анализируемых как вручную, так и автоматизированнымисистемами определения вторжения. Существует множество утилит, прячущихлевые сетевые соединения от глаз администраторов, однако на физическомуровне весь «хакерский» трафик элементарно обнаруживается и пресекаетсяпрактически любым брандмауэром, чего атакующему допускать ни в коемслучае нельзя. В идеале необходимо пробить тоннель, открыв секретныйканал связи, не создающий никаких дополнительных соединений и негенерирующий никакого избыточного трафика, чтобы даже самый строгийразбор дампов, награбленных сетевым анализатором, не выявил ничегоподозрительного.
Над решением этой проблемы бились лучшие хакерские умы. Сначала идеяполучила чисто теоретическое обоснование (Andrew Hintz, Craig Rowland)с чисто лабораторной реализацией, непригодной для практическогоиспользования. Затем к делу подключилась Жанна Рутковская,разработавшая специальный протокол с кодовым названием NUSHU и вполнежизнеспособные модули, ориентированные на работу в Linux Kernel 2.4.Жанна вручила нам мощное средство для управления удаленными shell'ами,от которого практически невозможно разработать адекватную защиту.Осталось только разобраться, как этим средством воспользоваться.Скрытые пассивные каналы: основные концепцииС недавних пор в хакерском лексиконе появилось понятие «скрытых пассивных каналов» (Passive Covert Channels, или сокращенно PCC). Они представляют собой разновидность обычных скрытых каналов (Covert Channels),однако, в отличие от последних, не только не устанавливают своихсоединений, но и вообще не генерируют никакого собственного трафика!Передача информации осуществляется исключительно путем модификациипакетов, пролетающих мимо атакованного узла.
Соль в том, что эти пакеты направляются не к хакеру, а шуруют своимипутями на различные узлы интернета, например, www.google.com, за счетчего достигается высочайшая степень анонимности. Естественно, возникаетрезонный вопрос: как хакер сможет добраться до содержимого пакетов,идущих мимо него? Для этого необходимо подломать один из промежуточныхмаршрутизаторов (как правило, принадлежащих провайдеру, обслуживающемуатакуемую организацию) и установить на него специальный модуль,анализирующий заголовки TCP/IP-пакетов на предмет наличия скрытой информации или ее внедрения.
Таким образом, хакер организует двухсторонний секретный пассивныйканал связи с узлом-жертвой, не только засекретив факт передачи левойинформации, но еще и надежно замаскировав свой IP, который можетопределить только администратор взломанного маршрутизатора, но никак невладелец узла-жертвы!
Рассмотрим схему взаимодействия с целевым узлом (жертвой) поскрытому пассивному каналу. Хакер (обозначенный буквой Х) каким-тосовершенно не относящимся к обсуждаемой теме образом забрасывает нацелевой узел (обозначенный буквой A) shell-код, захватывающийуправление и устанавливающий back-door вместе со специальным модулем,обеспечивающим функционирование PCC-канала. Теперь все TCP/IP-пакеты,отправляемые жертвой во внешний мир, содержат незначительные изменения,кодирующие, например, пароли или другую конфиденциальную информацию.
Часть этих пакетов проходит через внешний маршрутизатор B,заблаговременно взломанный хакером, внедрившим в него PCC-модуль.PCC-модуль анализирует заголовки всех TCP/IP-пакетов на предметскрытого содержимого, после чего декодирует его и отправляет хакеру пооткрытому каналу. Передача данных от хакера к жертве осуществляется поаналогичной схеме. PCC-модуль, установленный на маршрутизаторе,выявляет пакеты, направленные на целевой IP-адрес, и модифицирует ихзаголовки в соответствии с выбранным принципом кодирования информации.
Таким образом, мы получаем защищенный канал A-B и открытый B-X,однако хакеру ничего не стоит общаться с узлом B через анонимныйproxy-сервер или даже выстроить цепочку из нескольких защищенныххостов. К тому же, выбор маршрутизатора B необязателен. Главное, чтобымаршрутизатор располагался между целевым узлом А и одним из узлов, скоторыми общается жертва.Во власти протокола IPВозьмем протокол IP и попробуем создать на его основе скрытыйпассивный канал. Среди множества полезных и бесполезных полей заголовканаше внимание привлекает 16-битовое поле Identification,генерируемое операционной системой случайным образом и используемое дляидентификации дейтаграммы в случае ее фрагментации. Узел-получательгруппирует фрагменты с одинаковыми IP-адресами источника/назначения,типом протокола и, разумеется, идентификатором.
Строгих правил, определяющих политику генерации идентификатора, вRFC нет. Одни операционные системы используют для этого таймер, другиевычисляют идентификатор на основе TCP-пакетов, чтобы при повторнойпередаче TCP-сегмента IP-пакет использовал тот же самый идентификатор,однако даже если идентификатор окажется иным, ничего ужасного непроизойдет. Ну подумаешь, чуть-чуть упадет скорость.Фишка в том, что PCC-модуль может беспрепятственномодифицировать поле идентификатора по своему вкусу, передавая с каждымIP-пакетом 16 бит полезных данных. Это в теории. На практике же нампотребуется выделить несколько бит для маркировки своих пакетов, иначеPCC-приемник ни за что не сможет отличить их от остальных. Пусть в 12младших битах передаются полезные данные, а в четырех старших - ихконтрольная сумма. Тогда PCC-приемнику останется всего лишь взять12 бит, рассчитать их CRC и сравнить с оставшимися четырьмя битами.Если они совпадут, значит, это наш пакет, если же нет - пускай идетсебе лесом.
Также следует позаботиться о нумерации пакетов, поскольку порядокследования IP-пакетов в общем случае не совпадает с порядком ихотправки. А для этого также требуются биты, в результате чего реальнаяинформационная емкость IP-заголовка стремится к одному байту, что, вобщем-то, не так уж и плохо. Для передачи небольших объемов данных(типа паролей) вполне сойдет. Главное - не забывать о том, чтоидентификатор должен: а) быть уникальным; б) выглядеть случайным.Поэтому необходимо прибегнуть к скремблированию, то есть к наложению напередаваемый текст некоторой псевдослучайной последовательности данных(известной как PCC-отправителю, так и PCC-получателю) через операторXOR.Кроме идентификатора, можно (с некоторой осторожностью) менять поляTTL (Time To Live – максимальное время жизни пакета), тип сервиса (TOS)и протокола (protocol). Однако это слишком заметно и легкообнаруживается просмотром дампов, полученных любым снифером.Наш извозчик - протокол TCPПри установке TCP-соединения передающая сторона (узел A)устанавливает флаг SYN и выбирает произвольный 32-битный номерпоследовательности (Sequence Number, или сокращенно SEQ). Еслипринимающая сторона (узел
согласна принять узел А в свои объятия,она отправляет ему пакет с установленным флагом ACK и номеромподтверждения (Acknowledgment Number), равным SEQ+1, а также генерируетсвой собственный номер последовательности, выбираемый случайнымиобразом. Узел A, получив подтверждение, поступает аналогичным образом,что наглядно демонстрирует следующая схема:узел A ------ SYN(ISN) -----------> узел B узел A <----- SYN(ISN+1)/ACK ------ узел B
узел A ------ ACK ----------------> узел BISN – это начальный номер последовательности (Initial Sequence Number),уникальный для каждого TCP/IP-соединения. С момента установкисоединения номера последовательности планомерно увеличиваются наколичество принятых/отправленных байт. Впрочем, не будем углубляться втеорию. Остановимся на том факте, что 32-битное поле ISN можно изменятьпсевдослучайным образом, «промодулированным» секретными данными и...никто ничего не заметит! Конечно, пропускная способность упадет дочетырех байт на каждое TCP-соединение, устанавливаемое узлом-жертвой, аTCP-соединений устанавливается не так уж и много (особенно если мыимеем дело не с нагруженным сервером, а с рабочей станцией). Тем неменее, для перекачки паролей и удаленного управления через команднуюстроку даже такой скромной пропускной способности вполне достаточно.
Жанна Рутковская, решив не ограничивать себя лабораторными опытами, разработала протокол NUSHU,создающий скрытые пассивные каналы посредством модификации ISN споследующим шифрованием последнего алгоритмом DES на основеидентификатора IP-пакета (IP.id), порта-источника (TCP.sport) иIP-адреса назначения (IP.daddr).Сеанс практической магииИдем на сайт Жанны Рутковской - invisiblethings.org, видим раздел с инструментами tools, находим в нем «NUSHU - passive covert channel engine for Linux 2.4 kernels» и качаем архив исходных текстов - invisiblethings.org/tools/nushu/nushu.tar.gz(всего 18 Кб). Распаковываем, компилируем. Компиляция осуществляетсястандартно. Просто запускаем утилиту make и получаем три модуля ядра:nushu_receiver.o (приемник), nushu_sender.o (передатчик) иnushu_hider.o.
Механизм шифрования ISN в протоколе NUSHUПриемник устанавливается на поломанный маршрутизатор, передатчик -на целевой узел жертвы. Для организации двухсторонней связи приемник ипередатчик устанавливаются на оба узла. Модуль nushu_hider.o ворганизации скрытого канала не участвует и предназначен для обманаштатных анализаторов (типа tcpdump), не позволяя им обнаруживать фактизменения ISN.
Из readme следует, что модуль-передатчик обрабатывает следующие параметры командной строки:dev=, где device – сетевое устройство, с которым предполагается работать (например, eth0); cipher=[0|1], где 0 означает передачу без шифрования, а 1 предписывает использование DES;key="string",где string - произвольная строка-маркер, идентичная строке-маркеру,установленной на модуле-приемнике (используется только в том случае,если шифрование выключено, иначе игнорируется);src_ip= - IP-адрес узла, на котором установлен передатчик.Модуль-приемник, помимо описанных выше ключей dev, cipher и key,обрабатывает аргумент exclude_ip=, задающий списокнеприкосновенных IP-адресов, при отправке пакетов на которые протокол NUSHU задействован не будет, поскольку ISN останется неизменным (этот параметр является опциональным).
Модуль nushu_hider.o загружается без каких-либо параметров и только в том случае, если в этом возникает необходимость.
Хорошо, все модули успешно загружены, ядро функционирует нормально ив панику, судя по всему, впадать не собирается. Что делать дальше? Аничего! Ведь это только движок, обеспечивающий функционирование PCC-каналов.К нему можно прикрутить кейлоггер или удаленный shell, но это ужепридется делать самостоятельно. А как?! Ни readme, ни сопроводительныепрезентации не дают ответа на этот вопрос, поэтому приходитсязарываться в исходные тексты и разбирать их на отдельные байты.
Начнем с передатчика, реализованного в файле sender.c. В процедуреinit_module(), отвечающей за инициализацию модуля, сразу же бросаются вглаза следующие строки:struct proc_dir_entry *proc_de = proc_mkdir ("nushu", NULL);
create_proc_read_entry ("info", 0, proc_de, cc_read_proc_info, NULL);
struct proc_dir_entry * wpde = create_proc_entry ("message_to_send", 0, proc_de);Все ясно! Модуль использует псевдофайловую систему /proc, создаваядиректорию nushu, а в ней - два файла: info и message_to_send, скоторыми можно работать с прикладного уровня, как с обычнымиустройствами (если быть точнее, псевдоустройствами). Аналогичным образом обстоят дела и с приемником, реализованным в файле receiver.c, ключевой фрагмент которого приведен ниже:struct proc_dir_entry *proc_de = proc_mkdir ("nushu", NULL);
create_proc_read_entry ("message_received", 0, proc_de, cc_read_proc_message, NULL);
create_proc_read_entry ("info", 0, proc_de, cc_read_proc_info, NULL);Как видно, вместо устройства message_to_send на этот раз создаетсяmessage_received, из которого можно читать получаемые сообщения черезстандартные функции ввода/вывода. В общем, имея на руках исходныетексты, со всеми этими причиндалами совсем несложно разобраться, темболее что их суммарный объем составляет всего 69 Кб.ЗаключениеПомимо описанных, существуют и другие транспортные средства,пригодные для передачи скрытого трафика, например, опция штампа временив TCP-заголовке. HTTP-протокол дает еще большие возможности, посколькувключает в себя множество факультативных полей, которые можнобезболезненно модифицировать в весьма широких пределах. Однако все этослишком заметно, и наиболее стойким к обнаружению на сегодняшний деньостается протокол NUSHU, работающий с ISN.
Может ли атакованный администратор обнаружить скрытые пассивныеканалы хотя бы теоретически? Скрупулезный анализ сетевого трафикапозволяет выявить некоторую ненормальность распределения ISN, но дляэтого требуется обработать сотни тысяч «хакнутых» пакетов, сравнивая ихс оригиналами. Потому намного проще выявить посторонний ядерный модуль,отвечающий за создание и поддержку PCC-каналов, используя общиеметодики верификации целостности системы. Однако это уже совсем другойразговор, к которому мы еще вернемся.
