Создать форум бесплатно: ixbb.ru :: Календарь на Апрель 2024 года: calendar2008.ru/2024/aprel/

  Closed TopicStart new topicStart Poll

Как казаки TCP/IP-стек портили,или Краткий обзор DoS-атак для Windows-систем - 4

Лена
Отправлено: Apr 11 2006, 09:54 AM
Quote Post


  Главный администратор
*

Группа: Members
Сообщений: 311
Пользователь №: 1
Регистрация:
6-May 06



Автор: Максим Степин

Источник: Мир Internet

TEARDROP

Найденный в том же многострадальном 97-м году метод атаки TEARDROP основан на ошибках в реализации TCP/IP-стека. Подверженными такой атаке оказались WINDOWS-системы, а также компьютеры с установленным LINUX.

"Заплатка" MICROSOFT для WINDOWS NT, появившаяся достаточно быстро, - ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp3/simptcp-fix/. Строго говоря, эта "заплатка" предназначалась для защиты от другого типа атак. Метод заключался в посылке большого количества udp-пакетов с искаженным адресом отправителя на 19-й порт, что приводило к повышению udp-трафика. Фурора, подобного появлению winnuke, произведено не было, возможно потому, что общественное мнение свыклось с регулярным возникновением новых dos-атак. Тем не менее teardrop отличается тем, что стал первым в семействе себе подобных клонов (об этом будет рассказано ниже). Также teardrop является прекрасной демонстрацией того, что любые программы, даже состоящие из нескольких строчек, содержат ошибки. Совершим небольшой экскурс в тайны реализации tcp/ip-стека.

Поскольку передача данных в IP-сетях производится не в идеальной среде, а по вполне реальным каналам различного качества, то естественно, что в стандарт заложили возможность передачи больших пакетов фрагментами, которые на принимающей стороне преобразуются в исходный пакет. Речь идет о том, что некий единый пакет на уровне TCP- или UDP-протоколов может быть фрагментирован на уровне IP - протокола более низкого уровня. При этом каждый фрагмент будет характеризоваться смещением от начала исходного пакета и своей длиной. Драйвер TCP/IP-стека собирает все фрагменты на принимающей стороне до тех пор, пока не получит их все (или, во всяком случае, пока не решит, что принял их все). Безусловно, при передаче возможны различные ситуации, которые "умная" реализация TCP/IP должна понимать. В частности, может оказаться, что несколько полученных фрагментов будут пересекаться. Нас интересует ситуация, когда очередной фрагмент имеет смещение, лежащее внутри уже полученного фрагмента. Что же происходит в этом случае? Прежде всего вычисляется размер пересечения. А затем в буфер копируется только та часть нового фрагмента, которая "выступает за границу" старого фрагмента. Все просто и очевидно, за исключением того, что возможна еще одна нестандартная ситуация. А именно - когда новый фрагмент не только начинается внутри старого, но и оканчивается в нем же. По идее, такой фрагмент должен быть просто пропущен, но как раз такую возможность программисты, писавшие WINDOWS NT и LINUX, и не предусмотрели. Что же происходит в результате? Пусть у нас есть уже полученный фрагмент A, начинающийся с A_OFFS и имеющий длину A_LEN. Затем пришел новый фрагмент B, начинающийся с B_OFFS и с длиной B_LEN. Причем A_OFFS (A_OFFS + A_LEN), то есть фрагмент B лежит внутри фрагмента A. проследим действия принимающей стороны по шагам. начало нового фрагмента лежит внутри имеющегося. хорошо! пересекающаяся часть: ((A_OFFS + A_LEN) - B_OFFS). а тот кусочек, что нужно добавить в буфер, начинается с (A_OFFS + A_LEN) и имеет длину ((B_OFFS + B_LEN) - (A_OFFS + A_LEN)). о-ля-ля! длина-то меньше нуля! если вспомнить о машинной зацикленной арифметике, легко понять, что в результате будет скопирован очень большой блок памяти. при этом будет уничтожено все попадавшееся на пути (обычно на пути попадается операционная система). собственно, вышеописанное и есть TEARDROP ("слезинка", англ.). объяснение, приведенное выше, абсолютно верно для LINUX, поскольку его исходный код открыт. но, вероятно, аналогичный механизм делает и WINDOWS NT потенциальной жертвой для TEARDROP-атаки.

Позже возникло несколько модификаций TEARDROP, которые были способны пробивать WINDOWS NT с установленной против обычного TEARDROP "заплаткой". Известность получили BONK (BOINK), NEWTEAR, SYNDROP. Все эти атаки закрываются одной "заплаткой": ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp3/teardrop2-fix/. Наиболее оригинальным оказался метод syndrop. По сути, он представляет собой оригинальный teardrop, с тем отличием, что в посылаемых фрагментах устанавливается syn-флаг (снова этот излюбленный флаг).

После TEARDROP наступило достаточно продолжительное затишье. То ли ошибок стало меньше, то ли сообщать о них не торопились... Но вот осенью 98-го возникла очередная волна атак на WINDOWS-системы. Наиболее нашумевшим фактом, конечно, стало появление BACKORIFICE. Описание сего продукта не совпадает с темой статьи, но эту новость тяжело обойти.

Новая атака не влечет за собой фатальных последствий типа "зависания" или перезагрузки, но способна вызвать существенную загрузку процессора и повышенный сетевой трафик. На сей раз объектом нападок стала реализация RPC-протокола в WINDOWS NT. Идея чрезвычайно проста: в 135-й порт посылается некая "левая" датаграмма с адресом отправителя, измененным на адрес другой NT-машины. Реакцией атакуемой машины будет посылка REJECT-пакета на подмененный адрес.

Другая NT-машина ответит не менее гневным REJECT-пакетом, после чего такой пинг-понг будет продолжаться некоторое время, до тех пор, пока неправильный пакет не будет уничтожен как устаревший. Понятно, что посылая совсем небольшой поток фальшивых датаграмм, можно практически парализовать работу сети и заставить компьютеры тратить значительную долю своих вычислительных ресурсов на обработку RPC-ошибок. Изощренный злодейский ум может легко додуматься до простой модификации метода, при которой на несколько компьютеров посылаются поддельные UDP-пакеты с одинаковым адресом отправителя. В этом случае пинг-понг превращается в массированную артиллерийскую атаку несчастной жертвы.

Доступно исправление, после которого WINDOWS NT внимательнее относится к ошибочным RPC-пакетам и не спешит с ответной реакцией на них (FTP://FTP.MICROSOFT.COM/BUSSYS/WINNT/WINNT-PUBLIC/FIXES/USA/NT40/HOTFIXES-POSTSP3/SNK-FIX/SNK-FIXI.EXE).

135-й порт довольно давно зарекомендовал себя в качестве слабого места NT-платформы. Известна очень старая атака, заключавшаяся в посылке в этот порт нескольких строчек текста, что приводило к постоянной стопроцентной загрузке процессора. Спасал только перезапуск операционной системы. К счастью, эта "дырка" была закрыта в SERVICE PACK 3.

Идея же небольшого потока фальшивых пакетов используется во многих методах атаки. Например, знаменитый SMURF, который, по слухам, был использован против крупнейшего украинского Интернет-провайдера. Некий "веселый" сотрудник одного из московских провайдеров смог на несколько дней парализовать работу практически всего украинского сегмента Интернета. Описание механизма работы SMURF в этой статье приводить не будем.
PMEmail Poster
Top

Topic Options Closed TopicStart new topicStart Poll

 



[ Script Execution time: 0.0271 ]   [ 10 queries used ]   [ GZIP выключен ]