 |  |
https://bugtraq.ru/library/books/attack/chapter04/07.html |
|
|||
|
|
|
||
| https://bugtraq.ru/library/books/attack/chapter04/07.html |
||||
| ||||
Завершая тему, мы хотели бы рассказать о так называемых мифических удаленных атаках. К ним можно отнести "почти" осуществимые угрозы, основанные на реальных особенностях протоколов Internet. На практике такое воздействие либо нельзя осуществить (например, IP-фрагментацию как способ проникновения через Firewall), либо вероятность его успеха чрезвычайно мала (например, превышение максимально возможного размера IP-пакетa, или Ping Death). Однако шумиха, поднимаемая некоторыми зарубежными "экспертами" по безопасности Internet, вводит в заблуждение многих пользователей, создавая миф об этих атаках, которые на самом деле никому не угрожают.
Как известно из описания протокола IP (RFC 791), максимальный размер IP-пакета может достигать 216-1 байт. Однако размер пакета (дейтаграммы), пересылаемого непосредственно по каналу связи, зависит от типа среды передачи. Например, в среде Ethernet максимальный размер дейтаграммы - 1 500 байт, в среде АТМ - 56 байт. Для того чтобы IP-пакеты могли передаваться по сетям любых типов, в протоколе IP предусмотрена IP-фрагментация, то есть разбиение одного большого пакета на соответствующее количество дейтаграмм меньших размеров. Применение такой фрагментации в Internet делает ее более гибкой и инвариантной но отношению к разнообразным физическим средам передачи. На рис. 4.17 приведен формат IP-пакета версии IPv4.
| |||||||||||||||||||||||||||||||||||
Обратим внимание на поля Fragment Offset (Смещение фрагмента) и Flags (Индикаторы фрагментации) в IP-заголовке (RFC 791). Поле Flags показывает, фрагментирован пакет или нет. В поле Fragment Offset содержится значение смещения фрагмента относительно начала дейтаграммы, измеряемое восьмерками байт. Именно на эту особенность и не обратил внимания д-р Коэн (F.В.Cohen) в своей статье "Packet Fragmentation Attacks" ("Атаки посредством фрагментации пакетов") [20]: единица в таком поле означает смещение на 8 байт от начала дейтаграммы.
Каков же механизм предполагаемого воздействия? Как известно, одной из основных функций всех межсетевых экранов (МЭ) является фильтрация проходящего через них сетевого трафика. При фильтрации на сетевом уровне ограничивается возможность доступа к определенным службам защищаемых хостов. Тип службы, на которую направляется пакет, определяется параметром "порт назначения" в заголовке пакета TCP или UDP (рис. 4.18, 4.19), поэтому МЭ анализирует этот параметр, проверяя его соответствие установленным правилам фильтрации. Если пакет отвечает заданным условиям, то он пропускается дальше, в противном случае - отфильтровывается.
| ||||||||||||||||||||||||||||
| ||||||
В статье "Packet Fragmentation Attacks", опубликованной в конференции All.net, доктор Коэн предложил следующий сценарий предполагаемой атаки, заключающейся в прохождении фрагментироваиного пакета через Firewall без фильтрации. Взломщик разбивает пакет на два фрагмента, из них первый содержит фиктивный TCP- или UDP-заголовок с номером порта назначения, который не фильтруется межсетевым экраном (например, 25-й порт - почтовый SMTP-сервер), а второй имеет такое смещение (равное 1) в поле Fragment Offset, что перекрывает первый пакет и записывает в поле "порт назначения" истинное значение порта той службы, к которой доступ через МЭ запрещен.
 |
С этой статьей д-ра Коэна [20] происходили с течением времени довольно любопытные изменения. В статье, которую авторы нашли на WWW-сервере all.net в мае 1996 года, для осуществления атаки предлагалось занести в поле Fragment Offset значение, равное 1 (далее будет показано, что в этом случае подобная атака в принципе невозможна). Однако после посещения одного из серверов уже в мае 1997 года авторы с удивлением обнаружили ту же статью, но с одним "небольшим" исправлением: предлагалось заносить в это поле уже не 1, а 0! Во всем остальном статья осталась неизменной. |
В этом случае правила фильтрации пропустят такой IP-пакет, так как сборкой фрагментированных пакетов занимается не МЭ, а операционная система получателя, не проверяя, как правило, накладываются ли части пакета друг на друга. Собранный пакет сетевая ОС передает соответствующей службе, основываясь на данных в поле "порт назначения".
На первый взгляд атака состоялась: фрагментированный пакет, направленный одной службе, прошел через МЭ и после сборки был передан другой службе, доступ на которую был запрещен правилами фильтрации. Однако д-р Коэн не учел одного важного факта: значение в поле смещения согласно спецификации указывается в восьмерках байт, и даже если установить это значение равным единице и предположить, что сетевая ОС не проверяет наложения фрагментов, то такое наложение произойдет только после первых восьми байт TCP- или UDP-заголовка, в которых, как видно из рис. 4.19, и содержатся поля портов назначения.
Через некоторое время д-р Коэн, видимо, обнаружил описанную выше ошибку и исправил сценарий: единица в поле Fragment Ottset была заменена им на ноль. Проанализируем, насколько это изменение сделает возможным осуществление такой атаки.
Действительно, в этом случае кракер может заполнить нужным ему образом поле Flags (об этом поле в сценарии атаки д-р Коэн даже не упоминает) во втором пакете, а ведь сетевая ОС должна принимать решение о начале сборки фрагментов именно на основании значения из этого поля. Но анализ исходных текстов ядра операционных систем Linux и FreeBSD показал, что IP-пакет будет воспринят этими ОС как фрагмент только тогда, когда значение в поле Fragment Offset не равно 0. Тем не менее, так как в алгоритме сборки фрагментов, описанном в RFC 791, не требуется обязательной проверки значения этого поля, возможно, что некоторые сетевые ОС ее не производят, и, следовательно, атака может иметь успех.
Как нам кажется, сама идея наложения фрагментов достаточно любопытна. Другое дело, что применение ее для проникновения пакетов атакующего через Firewall в существующем стандарте IPv4 представляется маловероятным.
В максимальный размер IP-пакета (65 535 байт) включаются длина IP-заголовка и длина поля данных в IP-пакете. Так как минимальный размер IP-заголовка - 20 байт (максимальный - 60), то соответственно размер данных, передаваемых в одном IP-пакете, не может превышать 65 535 - 20 = 65 515 байт. А что будет, если превысить это число?
Тестировать свои программы на предельных критических значениях - стандартный для любого программиста ход. Подобные тесты позволяют выявить такие неприятные ошибки, как всевозможные переполнения (буфера, стека, переменной и т. д.).
Но вернемся к IP. В принципе ничто не мешает атакующему сформировать набор фрагментов, которые после сборки превысят максимально возможный размер IP-пакета. Собственно в этой фразе и сформулирована основная идея данной атаки.
Итак, 18 декабря 1996 года на информационном сервере СЕКТ появились сообщения о том, что большинство сетевых операционных систем, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допустимое значение, в этих ОС переполняется буфер или переменная, в результате система "зависает" или перезагружается, то есть налицо отказ в обслуживании. Был приведен и список потенциально опасных платформ:
Мы с удивлением прочитали этот перечень операционных систем на различных платформах, а потом принялись за эксперименты. Наше глубочайшее изумление вызвал тот факт, что элементарную ошибку переполнения буфера в модуле IP ядра ОС за почти 20 лет активного функционирования протокола IP разработчики сегодняшних систем до сих пор не замечали. Поэтому мы позволили себе не поверить столь уважаемой организации, как CERT. Но прежде чем начать эксперименты, было решено посмотреть по указанной в CERT ссылке (http://www.sophist.demon.co.uk/ping) на WWW-сервер, где экспертами проводились подобные исследования на различных ОС. На WWW-сервере предлагалось реализовать такое воздействие следующим образом: необходимо выполнить на рабочей станции с ОС Windows 95 или Windows NT следующую команду: ping -l 65527 victim.destination.IP.address (по этой команде атака и получила свое название - Ping Death).
Так как обычный размер IP-заголовка составляет 20 байт, а размер IСМР-заголовка - 8 байт, то подобный ICMP-пакет будет превышать максимально возможный размер IP-пакета на 20 байт: 65 527 +20+8-65 535 = 20.
Основываясь на приведенном расчете, эти "эксперты" декларировали, что обычной командой ping можно нарушить работоспособность практически любой сетевой ОС. В завершение предлагалась следующая таблица тестирования различных операционных систем (здесь она приводится в сокращении), на которые данная удаленная атака якобы произвела необходимый эффект. Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда исследуемые ОС - IRIX, AIX, VMS, SunOs, FreeBSD, Linux, Windows NT 4.0, даже Windows 95 и Windows for WorkGroups 3.11 - абсолютно не реагировали на подобный некорректный запрос, продолжая нормально функционировать. Тогда были предприняты специальные поиски операционной системы, которую бы действительно вывела из строя данная атака. Ей оказалась Windows 3.11 с WinQVT - эта ОС действительно "зависла".
Таблица 4.2. Уязвимые операционные системы
|
Этим "экспертам", которым столь доверяют CERT и СIАС, мы послали запрос, где попросили прояснить возникшую ситуацию, а также уточнить сведения из вышеприведенной таблицы. В полученном нами ответе говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьютере, и, самое главное, от фазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели бы привести описание exploit, созданного для Windows NT 4.0, задача которого, используя ping, "завесить" собственный компьютер (!). Сначала предлагалось запустить Web Browser, затем - taskmgr (Task Manager): так Ping Death якобы лучше работает (еще не хватает шаманского бубна!). И наконец, требовалось запустить 18 ping-процессов (почему не 100?). Если вы думаете, что после всего этого ваша ОС немедленно "повиснет", то ошибаетесь! В комментариях к exploit до получения эффекта предлагалось ждать примерно 10 минут, а может быть, несколько больше или несколько меньше.
Можно сделать вывод, что опасения по поводу данного воздействия ни на чем не основаны, и нам остается только назвать эту атаку очередной программистской байкой и причислить ее к разряду практически неосуществимых.
[27806]
|
|
|