Создание канала связи при удаленном эксплоитинге

Авторы: DimmoBorgir и theShockwaveRider

На сегодняшний день существует много различных типов уязвимостей, дающих возможность атакующему выполнять произвольную последовательность команд процессора на удаленной системе. Как правило, выполнение такой последовательности команд, называемой шеллкодом,приводит к созданию канала связи между удаленной системой и атакующим и к запуску командного интерпретатора, потоки ввода и вывода которого перенаправлены на этот канал связи.

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

Гораздо большую опасность представляет третий способ установки связи с атакуемой машиной, позволяющий обойти сетевые экраны. Он заключается в использовании уже установленного сокетного соединения, по которому отправляется специально сформированный запрос, приводящий к исполнению шеллкода. Как правило, для сетевого экрана запрос атакующего к предоставляемым сервисам неотличим от запроса легитимного пользователя, поэтому установка соединения возможна.

Мы провели тщательное исследование и убедились, что описанная проблема действительно актуальна. В частности нами была доказана возможность реализации этой схемы для операционной системы Linux под архитектуру IA—32. В данной операционной системе доступ процесса к каналам связи, таким, как файлы и сокеты, осуществляется через дескриптор — неотрицательное четырех байтовое целое число. При этом подходе шеллкод должен уметь находить среди всех дескрипторов файлов и сокетов, имеющихся в распоряжении процесса, тот дескриптор, который соответствует сокетному соединению, установившемуся в результате посылки атакующим специально сформированного запроса. После отыскания этого дескриптора происходит стандартная процедура перенаправления стандартных потоков и запуска командного интерпретатора.

Мы проанализировали два способа нахождения нужного дескриптора и методы борьбы с этим. Первый способ заключается в подключении атакующего к уязвимой машине с определенного порта. При выполнении шеллкода происходит поиск сокетного соединения, совершенного с этого порта. Это довольно простая схема, и защититься от возможного ее использования также просто. Установка маршрутизатора с NAT между уязвимым сервисом и атакующим решит проблему. В этом случае номер порта, с которого атакующий открывает соединение, не будет совпадать с номером порта, с которого происходит соединение с уязвимым сервисом.

Второй способ заключается в следующем. Вслед за специально сформированным запросом, содержащим шеллкод, посылается некоторая идентификационная строка. При выполнении шеллкода происходит последовательный перебор дескрипторов с попытками неблокирующего чтения данных функцией recv, доступной в linux через системный вызов socketcall. В случае успешного получения данных, они сравниваются с идентификационной строкой, совпадение укажет на искомый дескриптор.

Стоит отметить, что атакующий может ограничить себе перебор, поскольку дескрипторы с нулевого по второй соответствуют стандартным потокам STDIN, STDOUT, STDERR. В некоторых случаях устройство уязвимых программ таково, что дескриптор можно угадать с большой вероятностью, например в случае сервиса, который делает системный вызов fork для обработки каждого нового клиента. Такие приложения крайне уязвимы, поскольку будут отсутствовать следы перебора, что затруднит распознавание атаки.

Для защиты от переполнения буфера могут применяться широко известные методы, такие как canary words, рандомизация адресного пространства или неисполняемый стек. Кроме изучения стандартных подходов мы разрабатываем свой, довольно перспективный на наш взгляд, метод защиты — нормализация протоколов. Заключается он в наблюдении за входящим и исходящим трафиком. Для каждого сервиса создается набор правил, описывающих формат допустимых входных и выходных данных. Команды, не удовлетворяющие правилам, блокируются и не допускаются до сервиса.

Мы убедились, что действительно существуют техники установления канала, которые сложно пресечь, и продолжаем активную разработку своих методов защиты.

В приложении приведен шеллкод, демонстрирующий идею с идентификационной строкой. Мы его не комментируем во избежание использования людьми, мало осведомленными в данной тематике, в деструктивных целях. А тем, кому интересно, наверняка не привыкать к дизассемблеру ;) Мы не несем ответственность за использование материалов данной статьи в противозаконных целях. Мы не распространяем вредоносный код, а всего лишь показываем вам строку из некоторых байтов.