 |  |
https://bugtraq.ru/library/books/attack1/chapter4/c47.html |
|
|||
|
|
|
||
| https://bugtraq.ru/library/books/attack1/chapter4/c47.html |
||||
| ||||
В завершении разговора об удаленных атаках в сети Internet авторы хотели бы рассказать о так называемых мифических удаленных атаках. К этим курьезным атакам можно отнести "почти" реально осуществимые угрозы, основанные на реальных особенностях протоколов Internet. "Почти" осуществимые угрозы на практике нельзя осуществить (п. 4.7.1), либо вероятность их успеха чрезвычайно небольшая (п. 4.7.2). Однако шумиха, поднимаемая некоторыми не совсем компетентными зарубежными "экспертами" по безопасности Internet, вводящими в заблуждение многих пользователей, создает миф об этих атаках, которые на самом деле практически никому не угрожают.
Как известно из описания протокола IP (RFC 791),максимальный размер IP-пакета может достигать 216-1 байт. Однако размер пакета (дейтаграм-мы), передаваемого непосредственно по каналу передачи, зависит от типа среды передачи. Например, в среде Ethernet максимальный размер дейтаграммы 1500 байт, в среде ATM - 56 байт. Поэтому для того, чтобы IP-пакеты могли передаваться по сетям любых типов, в протоколе IP предусмотрена фрагментация пакетов. То есть для передачи одного большого пакета он разбивается на соответствующее количество пакетов меньших размеров (их размер обуславливается максимальным размером пакета в соответствующей среде передачи). Этот процесс разбиения IP-пакета на части называется IP-фрагментацией. Применение в сети Internet фрагментации пакетов делает ее более гибкой и инвариантной по отношению к разнообразным физическим средам передачи. На рисунке 4.12 приведен формат IP-пакета версии IPv4.
Не будем вдаваться в подробности, что означает каждое поле в IP-заголовке (RFC 791), так как в данном случае нас будут интересовать только поля Fragment Offset и Flags. В поле Fragment Offset содержится значение, измеряемое восьмерками байт, обозначающее смещение фрагмента относительно начала дейтаграммы (именно на то, что оно измеряется в восьмерках байт, и не обратил внимание д-р F. B. Cohen в его статье "Packet Fragmentation Attacks" [28]). Таким образом, единица в этом поле означает смещение на 8 байт от начала дейтаграммы. Поле Flags показывает фрагментирован ли пакет или нет.
Итак, каков механизм предполагаемого воздействия? Как известно, одной из основных функций всех файрволов является фильтрация проходящего через них сетевого трафика. В случае фильтрации на сетевом уровне ограничивается возможность доступа к определенным службам защищаемых хостов. Тип службы, на которую направляется пакет, определяется параметром "порт назначения" в заголовке пакета TCP или UDP (рис 4.12). Поэтому файрвол анализирует этот параметр и проверяет его соответствие тем правилам фильтрации, которые на нем установлены. В случае соответствия правилам пакет пропускается дальше, в противном случае - отфильтровывается.
Рис. 4.12. Формат IP-пакета версии IPv4.
| |||||||||||||||||||||||||||||||||||
Рис. 4.13. Формат TCP-пакета.
| ||||||||||||||||||||||||||||
Рис. 4.14. Формат UDP-пакета.
| ||||||
В своей статье "Packet Fragmentation Attacks" (опубликована в All.net) доктор F. B. Cohen предложил следующий сценарий предполагаемой атаки, заключающейся в прохождении фрагментированного пакета через файрвол, минуя правила фильтрации. Атакующий разбивает пакет на два фрагмента, первый из которых содержит фиктивный TCP- или UDP-заголовок с номером порта назначения, который не фильтруется правилами на файрволе (например, 25 порт - почтовый SMTP-сервер), а второй имеет такое смещение (равное 1) в поле Fragment Offset, что перекрывает первый пакет и записывает в поле "порт назначения" истинное значение порта той службы, к которой доступ через файрвол запрещен. В этом случае правила фильтрации на файрволе пропустят этот IP-пакет, так файрвол не занимается сборкой фрагментированных IP-пакетов.
|
С этой статьей д-р Cohen'a [28] происходили с течением времени довольно любопытные изменения. В статье, которую авторы нашли на WWW-сервере all.net в мае 1996 года, для осуществления атаки предлагалось занести в поле Fragment Offset значение, равное 1 (далее будет показано, что в этом случае подобная атака в принципе невозможна). Однако, после посещения одного из серверов уже в мае 1997 года авторы с удивлением обнаружили ту же статью, но с одним "небольшим" исправлением: предлагалось заносить в это поле уже не 1, а 0! Во всем остальном статья осталась неизменной. |
Действительно, сборкой фрагментированных IP-па-кетов занимается операционная система конечного получателя пакета, и при сборке, как правило, не проверяется, не накладываются ли фрагменты пакета друг на друга. Сетевая ОС собирает фрагментированный пакет и передает его соответствующей службе, основываясь на значении в поле "порт назначения" . На первый взгляд атака состоялась: фрагментированный пакет, направленный одной службе, прошел через файрвол и при сборке фрагментов передался другой службе, доступ на которую был запрещен правилами фильтрации файрвола. Однако, д-р F. B. Cohen не учел того важного факта, что значение в поле смещения согласно спецификации указывается в восьмерках байт, и даже если установить это значение в единицу и предположить, что сетевая ОС не проверяет наложение фрагментов, то после сборки фрагментов наложение произойдет только после первых восьми байт TCP- или UDP-заголовка, в которых, как видно из рис. 4.12, и содержатся поля портов назначения.
Через некоторое время после опубликования статьи д-р Cohen, видимо, обнаружил описанную выше ошибку и внес в сценарий атаки одно изменение: единица в поле Fragment Offset теперь была им заменена на 0! Проанализируем, насколько это изменение сделает возможным осуществление данной атаки.
Действительно, в этом случае атака может быть успешной, так как поле Flags ("индикатор фрагментации" ) во втором пакете атакующий может заполнить нужным ему образом, а ведь именно на основании значения из этого поля сетевая ОС должна принимать решение о начале сборки фрагментов.
|
Об этом поле в сценарии атаки др. Cohen'a даже не упоминается! |
Однако, анализ исходных текстов ядра операционных систем Linux и FreeBSD показал, что IP-пакет будет воспринят этими ОС как фрагмент только в том случае, если значение в поле Fragment Offset не равно 0! Тем не менее, так как в алгоритме сборки фрагментов, описанном в RFC 791, не требуется обязательная проверка значения этого поля, то возможно, что некоторые сетевые ОС ее не производят (что маловероятно!) и, следовательно, атака может иметь успех.
Как нам кажется, сама идея наложения фрагментов является достаточно любопытна. Другое дело, что применение ее для проникновения пакетов атакующего через Firewall в существующем стандарте IPv4 представляется маловероятным.
В максимальный размер IP-пакета (65535 байт) включается длина IP-заголовка и длина поля данных в IP-пакете. Так как IP-заголовок имеет минимальный размер в 20 байт (максимальный в 60), то, соответственно, размер передаваемых в одном IP-пакете данных не может превышать 65535 - 20 = 65515 байт. А что будет, если превысить этот максимальный размер IP-пакета?
Тестировать свои программы на минимальных и, самое главное, на максимальных значениях, то есть на предельных критических значениях - стандартный для любого программиста ход. Подобные тесты позволяют выявить такие неприятные ошибки, как всевозможные переполнения (буфера, стека, переменной и т. д.).
Вернемся к IP. В принципе, ничто не мешает атакующему сформировать набор фрагментов, которые после сборки превысят максимально возможный размер IP-пакета. Собственно, в этой фразе и сформулирована основная идея данной атаки.
Итак, 18 декабря 1996 года на информационном сервере CERT появились сообщения о том, что большинство сетевых ОС, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допустимое значение, в этих ОС переполняется буфер или переменная, и система зависает или перезагружается и т. п. - отказ в обслуживании! Также был приведен следующий список потенциально опасных платформ:
Увидев сообщение о подобной атаке и, главное, этот перечень операционных систем на различных платформах, мы с величайшим удивлением долго его перечитывали, а потом принялись за эксперименты. Наше глубочайшее изумление вызвал тот факт, что подобную элементарнейшую ошибку переполнения буфера в модуле IP ядра ОС за почти 20 лет активного функционирования протокола IP в различных ОС разработчики сегодняшних систем, да еще в таком массовом количестве, до сих пор не замечали! Поэтому мы позволили себе не поверить столь уважаемой организации, как CERT. Но прежде, чем начать эксперименты, было решено посмотреть по указанной в CERT ссылке [29] на WWW-сервер, где экспертами проводились подобные исследования на различных ОС. Там, собственно как и в CERT, эта атака называлась "Ping Death" . На этом WWW-сервере предлагалось реализовать такую атаку следующим образом: на рабочей станции с ОС Windows '95 или Windows NT необходимо выполнить следующую команду:
ping -l 65527 victim.destination.IP. address (поэтому - "Ping Death" ).
Так как обычный размер IP-заголовка составляет 20 байт, размер ICMP-заголовка - 8 байт, то подобный ICMP-пакет будет превышать максимально возможный размер IP-пакета на 20 байт
(65527 + 20 +8 - 65535 = 20).
Таким образом эти "эксперты" декларировали, что обычной командой ping якобы можно нарушить работоспособность практически любой сетевой ОС. В завершение на этом сервере приводилась следующая таблица тестирования различных операционных систем, на которые данная удаленная атака якобы произвела необходимый эффект. Далее авторы хотели бы продемонстрировать вам эту таблицу с существенными сокращениями (см. табл. 4.13).
Не правда ли, эта таблица операционных систем, обладающих такой уязвимостью, производит должное впечатление!
Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда ни одна из исследуемых операционных систем, ни IRIX, ни AIX, ни VMS, ни SunOs, ни FreeBSD, ни Linux, ни Windows NT 4.0, ни даже Windows '95 и Windows for WorkGroups 3.11, абсолютно никак не реагировали на подобный некорректный запрос и продолжали нормально функционировать! Тогда были предприняты специальные поиски ОС, которую бы действительно вывела из строя данная атака. Ею оказалась Windows 3.11 с WinQVT - эта ОС действительно зависла.
Таблица 4.13
Уязвимые операционные системы
|
На запрос, посланный этим так называемым "экспертам" , которым столь доверяют CERT и CIAC, где мы попросили прояснить возникшую ситуацию, а также сведения из таблицы 4.13, был получен ответ; в нем говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьютере и, самое главное, от фазы луны. Согласитесь, полный бред! Для полноты картины мы хотели бы далее привести описание exploit'а, созданного для Windows NT 4.0, задача которого, используя ping, завесить собственный компьютер. Первым шагом предлагалось запустить Web Browser (?). На втором шаге требовалось запустить taskmgr (Task Manager) (??). В комментариях к этому шагу говорилось, что так Ping Death работает лучше (еще не хватает шаманского бубна!). И, наконец, требовалось запустить 18 ping-процессов (???) (не больше и не меньше; может быть, лучше сразу 100 - чего мелочиться!). Если вы думаете, что далее ваша ОС немедленно повиснет, то вы ошибаетесь! В комментариях к exploit'у до получения эффекта предлагалось ждать примерно 10 минут, с философским замечанием о том, что ожидание может продлиться несколько больше (интересно на сколько больше - час, месяц, год ?!) или несколько меньше.
В итоге можно сделать вывод, что шумиха,
поднятая в CERT и CIAC по поводу данной атаки,
является безосновательной, и ничего другого нам,
видимо, не остается, как назвать эту атаку
очередной программистской байкой и причислить
ее к разряду практически неосуществимых.
|
|
|