Главная
Архив новостей
Безопасность в Unix
Безопасность в Windows
Сборник FAQ'ов
Телефония, фрикинг
Кредитные карты
Криптография
Истории о хакерах
Программы, утилиты
_el@sp.sz.ru

RB2 Network


Team Void



Атака joilt2 действует против TCP-стеков NT4/Win2k и приводит к резкому расходу использования памяти (до 70 зарезервированых мегабайт на системе с 196 мегабайтами физической памяти).

Шведский аналитик Mikael Olsson (mikael.olsson@enternet.se) произвёл анализ механизмов действия данной атаки, и в нашем рассказе мы осветим детали того, что делает joilt после получения параметром IP-адреса жертвы.

Имеется два режима действия атаки: неверно фрагментированые пакеты ICMP-ECHO (ping) и неверно фрагментированные UDP-пакеты. В обоих cлучаях жетрве посылается непрерывный поток идентичных фрагментов (один и тот же оффсет, один и тот же ID и всё остальное), где все фрагменты подобраны следующим образом

  • Все фрагменты посылаются с оффсетом 8190
  • Посылается 9 байтов данных IP (длина пакета равна 29)
  • Поле IP равно 0x0455
  • Поле TTL равно 255
  • SRC_ADDR не изменено (реальный адрес атакующего)
  • DEST_ADDR - адрес жертвы
  • контрольная сумма равна нулю (ошибочное значение)
  • Поле IP total length установлено в 68 (IP+8+40) (ошибочное значение)
  • Флаг MF установлен в 0 (последний фрагмент)
Автор так же увеличил длину передаваемых пакетов с целью быть уверенным, что посылаемые пакеты имеют правильные заголовки, что довольно дабавно (так как корректного первого фрагмента не посылается). Итак, ни одна система, которая попытается собрать данные, ме сможет интерпретировать заголовки пакетов как принадлежащие к семейству IP-протоколов Заголовок ICMP посылается как ICMP Echo (ping) со следующими параметрами:
  • Тип: 0
  • Контрольная сумма: 0
  • неиспользуемое 32-битное значение: 0
  • Один байт данных: 0
Заголовок UDP посылается с задаваемым пользователем портом назначения, к которому применена операция OR по 1235. Контрольная сумма равна 0, длина UDP - 9, первый байт данных - 'a'. Получатель никогда не пропарсит такие заголовки.

Вспоминая о контрольной сумме, установленной в ноль, я вспоминаю о том, что читал где-то о том, что данный вид атак может применяться только лишь против жертв в одном сегменте с атакующим (любой роутер не пропустит такие пакеты, так как их контрольная сумма неверна). Установка контрольной суммы в 0 воспринимается стеком системы как флаг, указывающий ей игнорировать корректность данных только лишь для ICMP- и UDP- протоколов. Семейство протоколов IP всегда требует наличия контрольной суммы.

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

Так как проблема скорее не во фрагментации, а в исчерпывании ресурсов TCP-стека (возможно, это связано со слишком большим числом пакетов, получаемых стеком MS-системы - он просто не успевает обрабатывать их все). Помните: не существует задержки между посылаемыми пакетами, пока хватает пропускной способности канала и устройства, атакующий использует их полностью.

Итак, при анализе структуры фрагментов мы получаем следующее:
  • Посылаемые данные - 29 байт (20 IP + 9 байт данных), что корректно только лишь для последнего фрагмента
  • Длина данных, указная в заголовке IP - 68 байт. Это означает, что пакет не пройдёт ни одного теста на корректность структуры, если, конечно, они присутствуют. Как показывает практика, Microsoft никогда не заботилось об включении подобных тестов в TCP-стек исследуемой системы. Получатель пакетов с длиной, указаной в заголовке превосходящей реальную поставлен в совершенно нормальные условия - округление длины пакета в процессе передачи вполне нормальное явление
  • Фрагменты имеют флаги "last fragment"
В заключение стоит сказать, что к сбою могут приводить два фактора
  • Это атака, принадлежащая к классу атак, исчерпывающих ресурсы сетевого уровня, а не фрагментационная атака. Получатель должен быть способен идентифицировать получаемый пакет как ошибочный и сбросить его БЕЗ сохранения в стеке
  • Microsoft не производит таких проверок. Microsoft не производит проверок структуры пакетов и хранит все получаемые фрагментированные пакеты, используя для их обработки процедуру, требующую значительных затрат ресурсов
Как настроить правила фильтрации пакетов для защиты от данной атаки?

Во-первых, любой роутер должен не пропускать такой траффик, поскольку контрольная сумма пакетов неверна.

Если контрольная сумма верна, что несомненно будет реализовано в последующих версиях атаки, правильно написанный пакетный фильтр должен будет способен блокировать данную атаку.
  • Если файрвол имеет способность осуществлять любой род сборки (псевдо)фрагментированных пакетов, он не должен пропускать фрагментированные пакеты, поскольку в пакетах, генерируемых эксплоитом, не присутствует корректных фрагментов - иными словами, из этого невозможно что-либо собрать
  • Если файрвол пропускает фрагменты, проверяя по таблице состояний, к чему они относятся, то при определении того, что соединение, к которому якобы относятся фрагментированные пакеты, не существует, файрвол должен блокировать фрагментированный траффик

 duke.


<== Back to main page