Обход механизмов IDS Active Response: часть первая - Session Sniping

Введение

Все еще продолжаются споры среди разработчиков программного обеспечения, какой из методов обнаружения нападения является оптимальным, но заказчики систем обнаружения вторжения (IDS), в целом, уже удовлетворены ныне существующими технологиями. Чтобы получить преимущество в конкурентной борьбе, многие продавцы IDS добавляют возможности активного ответа в свои программы. Концепция, лежащая в основе этой тактики, состоит в том, что IDS обнаружит нападение и остановит его. Проблема состоит лишь в том, что любой хакер с элементарными знаниями TCP/IP может легко сломать этот механизм или выводить из строя сеть достаточно часто, что приведет к тому, что системные администраторы будут вынуждены отключить эту возможность. Для системных администраторов важно знать все ограничения механизмов активного ответа, чтобы не теряться в проблемной ситуации.

Большинство механизмов активного ответа представлены двумя типами:

1. Session Sniping

2. Firewall Update

В этой статье остановимся на методе Session Sniping.

Session Sniping

Session Sniping - наиболее популярный способ среди производителей IDS. Популярный, потому как не требует никаких специальных драйверов для разных внешних устройств (например, межсетевых защит) и прост в осуществлении. Механизм несложен. Я попытаюсь примитивно, «на пальцах» объяснить механику TCP, так что заранее приношу извинения всем, кто работает с этим постоянно и считает себя специалистом в этой области. Они могут пропустить следующий абзац.

Представим злоумышленника с 51-байтовым эксплойтом, который атакует сеть, способную передавать 20 байтов данных в пакете. Скажем, IDS имеет сигнатуру "system32/cmd.exe" и может выполнять полную дефрагментацию, потоковую сборку и unicode/hexcode/escape/base36 декодирование. IDS захватит эксплоит (если атакующий не изменит его некоторым образом) и поднимет тревогу.

IP стек атакующего наугад выбирает Initial Sequence Number (ISN) и разбивает эксплоит на три пакета следующим образом:

 

 

(Да, я знаю, это не будет работать без небольшой модификации. Приведен, всего лишь, безобидный пример)

Некоторые TCP/IP будут отсылать пакеты по одному за время ожидания, при получении подтверждения после каждого пакета. Другие отошлют все три пакета разом, а затем дошлют  те, на которые не придет подтверждения. Третьи пошлют первый пакет, а после подтверждения установления сессии – два остальных. Смысл заключается в том, что стеки могут работать с любым количеством пакетов в одно и то же время. 

В приведенном выше примере, IDS поднимет тревогу на третьем пакете, потому что он вместе со вторым и третьим пакетами заканчивает сигнатуру.

IDS, который использует Session Sniping, сгенерирует TCP RESET пакет для обоих подключенных сторон. Стеки интерпретируют RESET пакет, как требование с другой стороны о прекращении связи. Они разорвут связь и очистят буфер. В этот момент, эксплоит, возможно, даже находится в TCP/IP буфере стека машины жертвы, но не будет допущен к приложению. Буфер вскоре очистится, а эксплоит так и не будет никогда выполнен.

Пакеты RESET должны иметь правильные числа sequence/acknowledgement, иначе они будут просто игнорироваться. В нашем случае, Acknowledgement Number должен быть 152 (на один больше последнего sequence number). Если бы был получен пакет RESET с номером подтверждения 141, он был бы просто проигнорирован стеком, который интерпретировал бы его, как сбой или недопустимый трафик.

 

Как обманывают метод Session Sniping

Существует множество методов обойти метод Session Sniping, большинство из которых основано на синхронизации по времени. Если эксплоит не требует интерактивной сессии, существует возможность просто установить флажок PUSH на TCP пакеты. TCP/IP стеки, как правило, не поставляют каждую порцию данных приложению сразу при получении. Это слишком накладно и медленно, если менять контекстные переключатели (context switches) в программах и приостанавливать работу приложения каждый раз для загрузки очередного маленького кусочка данных. Как правило, стек накапливает данные в буфере, до тех пор, пока буфер не будет полон, а затем перемещает полный буфер данных разом к приложению. В вышеупомянутом примере, все 51 байт эксплоита будут доставлены сразу.

 

Некоторые прикладные программы требуют получения данных с максимально возможной скоростью и готовы даже платить за это небольшим количеством дополнительного объема данных, чтобы установить в нем эту пометку срочности. Флаг PUSH инструктирует стек поставлять данные сразу при получении. Если, к примеру, вы хотите запустить просмотр директорий, флаг PUSH не поможет вам, потому что сеанс будет разорван системами безопасности прежде, чем вы сможете получить ответ. Но если вы хотите скопировать файл паролей в каталог, доступный для просмотра на web-сервере, вас может совершенно не заботить то, что вашу сессию обнаружат и прервут после того, как основная цель будет уже выполнена. Простая установка флажка PUSH приведет к выполнению эксплоита.

 

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

Первый метод основан на времени запаздывания IDS. Требуется немало времени для IDS, чтобы переместить по линии пакет, обнаружить в нем вредный эксплоит, создать RESET пакеты и запустить их в сеть. Многие IDS используют libpcap для перемещения пакета от сети. Многие также выполняются в *BSD. BSD могут использовать Berkeley Packet Filters, имеющие по умолчанию огромные буферы. Для  типичной сети, должно пройти в лучшем случае не менее пол секунды прежде, чем будут готовы RESET пакеты. Система Solaris среагирует быстрее, Linux в районе полусекунды, но в любом случае, имеется катастрофически большое время запаздывания.

 

Чтобы обмануть IDS, следующий пакет в TCP сеансе должен прибыть раньше RESET пакета. Я собираюсь снова обратиться к основам TCP, так что опять приношу извинения всем, кто не нуждается в этих разъяснениях. Работа стека TCP приведена на рисунке. Часть полученных данных уже были направлены к приложению, а часть ожидает этого в буфере. Существует также некоторый пустой объем для принятия новых данных. Все вместе известны как окно. Только данные в буфере и пустом объеме могут быть отправлены/получены/прерваны/и т.д. Данные слева уже были отосланы приложению. Данные после пустого объема не были затребованы пока ни одним приложением и будут проигнорированы, если все же будут получены.

 

Стек TCP также имеет текущий указатель (Current Pointer). Current Pointer - указатель на следующую часть данных, которую стек ожидает для приема. Текущий указатель - в принципе, acknowledgement number. Если стек принял 76 байтов, acknowledgement number будет 77. Он как бы заявляет, что принял все до 76 байта, и просит прислать следующую часть данных, начинающуюся с 77 байта. Когда прибывает следующий кусок, текущий указатель будет перемещен в конец этого фрагмента данных.

Фрагменты данных могут приходить и не в строгом порядке. Кусок, начинающийся с 90-го байта, может прийти раньше куска, начинающегося с 77-го. Такие неупорядоченные фрагменты будут скопированы в буфер, но текущий указатель останется на отметке 77 до получения фрагмента, начинающегося с 77. После чего указатель будет сдвигаться до конца последнего упорядоченного фрагмента.

 

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

 

Есть также другой вариант этого метода, который делает невозможным для IDS разрыв сеанса, но он требует применения кодирования атакующим. В этом методе, хакер просто посылает пакет 4 перед пакетом 3. Пакет будет скопирован в буфер сразу после получения, но текущий указатель не сместится. И как только прибудет третий пакет, текущий указатель переместится в конец пакета 4. RESET будет сгенерирован для пакета 3, но, теперь уже независимо от скорости отклика системы, он будет игнорироваться, так как текущий указатель неизбежно сместится.

 

Как определяют наличие Session Sniping

Ну это совсем просто. Если вы используете TCPDump (или другие аналоги), то определить, что специфическая сеть выполняет IDS с методом session sniping, элементарно. Достаточно создать  пакеты, содержащие данные, которые могут вызвать тревогу IDS, и послать их в сеть. По наличию RESET пакетов можно уже предположить такую систему, а конкретные особенности IDS можно определить по структуре пакета.