Текст книги "Атака на Internet"

Автор книги: Илья Медведовский

сообщить о нарушении

Текущая страница: 11 (всего у книги 27 страниц) [доступный отрывок для чтения: 12 страниц]

Превышение максимально возможного размера IP-пакета, или Ping Death

В максимальный размер IP-пакета (65 535 байт) включаются длина IP-заголовка и длина поля данных в IP-пакете. Так как минимальный размер IP-заголовка – 20 байт (максимальный – 60), то соответственно размер данных, передаваемых в одном IP-пакете, не может превышать 65 535 – 20 = 65 515 байт. А что будет, если превысить это число?

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

Но вернемся к IP. В принципе ничто не мешает атакующему сформировать набор фрагментов, которые после сборки превысят максимально возможный размер IP-пакета. Собственно в этой фразе и сформулирована основная идея данной атаки.

Итак, 18 декабря 1996 года на информационном сервере CERT появились сообщения о том, что большинство сетевых операционных систем, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допустимое значение, в этих ОС переполняется буфер или переменная, в результате система «зависает» или перезагружается, то есть налицо отказв обслуживании. Был приведен и список потенциально опасных платформ:

• Berkeley Software Design, Inc. (BSDI);

• Computer Associates, Intl. (products for NCR);

• Cray Research;

• Digital Equipment Corporation;

• FreeBSD, Inc.;

• Hewlett-Packard Company;

• IBM Corporation;

• Linux Systems;

• NEC Corporation;

• Open Software Foundation (OSF);

• The Santa Cruz Operation, Inc. (SCO);

• Sun Microsystems, Inc.

Мы с удивлением прочитали этот перечень операционных систем на различных платформах, а потом принялись за эксперименты. Наше глубочайшее изумление вызвал тот факт, что элементарную ошибку переполнения буфера в модуле 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 байт, а размер ICMP-заголовка – 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 и CIAC, мы послали запрос, где попросили прояснить возникшую ситуацию, а также уточнить сведения из вышеприведенной таблицы. В полученном нами ответе говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьютере, и, самое главное, от фазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели бы привести описание exploit, созданного для Windows NT 4.0, задача которого, используя ping, «завесить» собственный компьютер (!). Сначала предлагалось запустить Web Browser, затем – taskmgr (Task Manager): так Ping Death якобы лучше работает (еще не хватает шаманского бубна!). И наконец, требовалось запустить 18 ping-процессов (почему не 100?). Если вы думаете, что после всего этого ваша ОС немедленно «повиснет», то ошибаетесь! В комментариях к exploit до получения эффекта предлагалось ждать примерно 10 минут, а может быть, несколько больше или несколько меньше.

Можно сделать вывод, что опасения по поводу данного воздействия ни на чем не основаны, и нам остается только назвать эту атаку очередной программистской байкой и причислить ее к разряду практически неосуществимых.

Атаки, использующие ошибки реализации сетевых службАтака Land

Как уже неоднократно подчеркивалось, существует принципиальная возможность отправить IP-пакет от имени (с IP-адреса) любого хоста в Internet. Эта возможность заложена в формате самого IP-заголовка, поскольку в нем не предусмотрено ни одного дополнительного идентифицирующего поля (за исключением поля Source Address). Ничто не мешает кракеру поставить в этом поле то же самое значение, что и в поле Destination Address, то есть сформировать IP-пакет, где адрес отправителя совпадает с адресом получателя пакета. Кроме того, в TCP-заголовке также ничто не мешает установить одинаковые значения в полях Source Port Number и Destination Port Number. Таким образом, формируется обычный IP-пакет, направленный как бы сам на себя. В случае атаки в заголовке такого IP-пакета в качестве адресов назначения и отправления указываются IP-адреса объекта воздействия, а в качестве порта назначения и отправления – любой открытый порт на атакуемой системе.

Однако, как оказалось (первые сведения о данной уязвимости датированы 1997 годом), существуют операционные системы, для которых подобный запрос является нестандартной ситуацией, вызывающей некорректную обработку, – ответ системы самой себе, в результате чего происходит зацикливание.

Наши эксперименты показали, что такой уязвимости подвержены все версии ОС Windows NT/95. Причем Service Pack 4.0 в этом случае почти не помогает. После приема одного Land-запроса на некоторое время (45 секунд при установленном Service Pack 3) загрузка системы увеличивается до 100 % и доступ в систему становится невозможным (Windows 95 обычно показывает синий экран). Мы недаром выделили слово «одного». Ведь ничто не мешает атакующему организовать шторм или мини-шторм Land-запросов, а это сделает работу Windows-системы практически невозможной. Например, при тестировании направленным штормом Land-запросов Windows NT 4.0 на платформе Pentium 200 с установленным Service Pack 4 (где серьезно улучшена реакция NT на атаку Land) порог «нормальной» работы был в случае шторма не более 3 500 зап./с. При шторме Land-запросов свыше указанного порогового значения система «замирала» и доступ к ней становился невозможным.

Атаки teardrop и bonk

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

Разработчики ввели проверку на слишком большой объем копируемой информации (чтобы ядро не переносило такой объем данных), но не предусмотрели проверку на копирование слишком маленького фрагмента (фрагмента отрицательной длины). Рассмотрим, к чему приводит отсутствие такой проверки.

Когда фрагмент сообщения помещается в очередь сборки, выполняется поиск его положения в очереди:

end = (offset + total_len) – ihl;

Соответственно, если фрагменты перекрываются, то нужно выровнять их таким образом, чтобы устранить наложение:

if (prev!=NULL && offsetend)

{

i=prev->end-offset;

offset += i;

ptr += i;

}

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

Тогда при заполнении структуры, описывающей копируемый блок данных, возникает следующая ситуация:

fp->offset = offset

fp->end = end

fp->len = end-offset (Отрицательная)

Заключенная в цикл инструкция по сборке фрагментов выглядит следующим образом:

memcpy((ptr+fp->offset), fp->ptr, fp->len),

где: ptr+fp->offset – смещение фрагмента в буфере;

fp->ptr – область данных фрагмента;

fp->len – длина копируемого блока данных.

Попытка скопировать блок данных отрицательной длины (что равносильно копированию очень большого блока данных) приводит к затиранию достаточно большого участка памяти и к «зависанию» или перезагрузке компьютера.

Таким образом, для реализации данной атаки пакеты формируются по следующему правилу (рассмотрим атаку из двух пакетов):

1. Посылается пакет, предполагающий фрагментацию (флаг MF = 1), со смещением фрагмента 0, блоком данных длиной N.

2. Посылается последний фрагмент сообщения (флаг MF = 0) с положительным смещением фрагмента offset < N и блоком данных, длина которого меньше N-offset.

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

Для NT существуют две похожие программы, которые реализуют этот механизм, связанный с наложением IP-фрагментов: teardrop и newtear (с несущественными отличиями в константах). Пакеты посылаются с любого адреса на любой из портов, независимо от того, открыт он или нет.

Есть и другая вариация на тему этой атаки – bonk. В данном случае после сборки фрагментов в пакете остаются «дырки» – пустые, не заполненные данными места, что также может привести к сбою ядра операционной системы и «зависанию» компьютера.

Обе эти уязвимости присутствовали во всех версиях ОС Windows 95/NT до Service Pack 4 включительно и в ранних версиях ОС Linux (например, Linux 2.0.0). На сегодняшний день ошибки, связанные с некорректной сборкой фрагментов, скорее всего, исправлены в большинстве сетевых ОС.

Атака передачей широковещательного запроса от имени «жертвы»

Как известно, протокол IP поддерживает возможность broadcast-адрeсации (широковещательная) пакетов. Например, адрес 194.255.255.255 является широковещательным для сети 194.0.0.0. Особенность широковещательной передачи состоит в том, что такой IP-пакет получат все хосты внутри данной подсети (на канальном уровне в заголовке данного IP-пакета указывается адрес FF-FF-FF-FF-FF-FF, чем, очевидно, и достигается «широковещательность» сообщения).

Одной из функций протокола ICMP является передача по сети тестовых запросов Echo Request/Reply. Атака, получившая название Smurf, состоит в передаче в сеть одиночного широковещательного запроса ICMP Echo Request от имени (с IP-адреса) «жертвы». В результате все операционные системы (а их теоретически может быть очень много), получив этот Echo-запрос, перешлют на IP-адрес «жертвы» ответ, что может привести к перегрузке ОС компьютера этими ответами. На практике, однако, оказывается, что, во-первых, большинство роутеров не передает в сеть полученный широковещательный IP-запрос, а, во-вторых, ОС, отличные от UNIX-совместимых (например, MS Windows), не воспринимают широковещательный IP-трафик и, соответственно, не отвечают на подобные запросы.

Таким образом, можно сделать вывод, что атака Smurf является практически (но не принципиально!) неосуществимой.

Атака Windows-систем передачей пакетов TCP/IP на открытый порт

Такая атака, называемая Out of Band (OOB), на сегодняшний день абсолютно устарела: она заключалась в передаче на атакуемую Windows-систему пакета TCP/IP с флагом OOB на открытый (обычно 139-й) TCP-порт и эффективно «подвешивала» Windows NT/95 до выхода Service Pack 3.

Глава 5
Методы удаленного сканирования портов

Все тайное становится явным.

Рассмотрим существующие на сегодняшний день различные методы сетевого сканирования. Для этого необходимо ответить на следующий вопрос: «Что такое сканирование портов, и для чего оно применяется?»

Прежде чем переходить к ответу, вспомним, что представляют собой сетевые службы предоставления удаленного сервиса (серверные приложения), такие как WWW, FTP, TELNET и т. д. Эти программы (в UNIX-средах они обычно запускаются в режиме демона) после загрузки ожидают получения удаленных запросов на подключение от клиентов на определенных, заранее для них зарезервированных TCP– или, значительно реже, UDP-портах.

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

Таким образом, список открытых (активных) портов на сервере означает наличие запущенных на нем серверных приложений, предоставляющих удаленный доступ. Ниже приводится текст файла /etc/services из ОС Linux, где есть список портов, зарезервированных для основных служб.

#

# Network services, Internet style

#

# Note that it is presently the policy of IANA to assign a single well-known

# port number for both TCP and UDP; hence, most entries here have two

# entries even if the protocol doesn’t support UDP operations.

# Updated from RFC 1340, “Assigned Numbers” (July 1992). Not all ports

# are included, only the more common ones.

#

# from: @(#)services 5.8 (Berkeley) 5/9/91

# $Id: services,v 1.9 1993/11/08 19:49:15 cgd Exp $

#

tcpmux 1/tcp # TCP port service multiplexer

echo 7/tcp

echo 7/udp

discard 9/tcp sink null

discard 9/udp sink null

systat 11/tcp users

daytime 13/tcp

daytime 13/udp

netstat 15/tcp

qotd 17/tcp quote

msp 18/tcp # message send protocol

msp 18/udp # message send protocol

chargen 19/tcp ttytst source

chargen 19/udp ttytst source

ftp 21/tcp

# 22 – unassigned

telnet 23/tcp

# 24 – private

smtp 25/tcp mail

# 26 – unassigned

time 37/tcp timserver

time 37/udp timserver

rlp 39/udp resource # resource location

nameserver 42/tcp name # IEN 116

whois 43/tcp nicname

domain 53/tcp nameserver # name-domain server

domain 53/udp nameserver

mtp 57/tcp # deprecated

bootps 67/tcp # BOOTP server

bootps 67/udp

bootpc 68/tcp # BOOTP client

bootpc 68/udp

tftp 69/udp

gopher 70/tcp # Internet Gopher

gopher 70/udp

rje 77/tcp netrjs

finger 79/tcp

www 80/tcp http # WorldWideWeb HTTP

www 80/udp # HyperText Transfer Protocol

link 87/tcp ttylink

kerberos 88/tcp krb5 # Kerberos v5

kerberos 88/udp

supdup 95/tcp

# 100 – reserved

hostnames 101/tcp hostname # usually from sri-nic

iso-tsap 102/tcp tsap # part of ISODE.

csnet-ns 105/tcp cso-ns # also used by CSO name server

csnet-ns 105/udp cso-ns

rtelnet 107/tcp # Remote Telnet

rtelnet 107/udp

pop2 109/tcp postoffice # POP version 2

pop2 109/udp

pop3 110/tcp # POP version 3

pop3 110/udp

sunrpc 111/tcp

sunrpc 111/udp

auth 113/tcp tap ident authentication

sftp 115/tcp

uucp-path 117/tcp

nntp 119/tcp readnews untp # USENET News Transfer Protocol

ntp 123/tcp

ntp 123/udp # Network Time Protocol

netbios-ns 137/tcp # NETBIOS Name Service

netbios-ns 137/udp

netbios-dgm 138/tcp # NETBIOS Datagram Service

netbios-dgm 138/udp

netbios-ssn 139/tcp # NETBIOS session service

netbios-ssn 139/udp

imap2 143/tcp # Interim Mail Access Proto v2

imap2 143/udp

snmp 161/udp # Simple Net Mgmt Proto

snmp-trap 162/udp snmptrap # Traps for SNMP

cmip-man 163/tcp # ISO mgmt over IP (CMOT)

cmip-man 163/udp

cmip-agent 164/tcp

cmip-agent 164/udp

xdmcp 177/tcp # X Display Mgr. Control Proto

xdmcp 177/udp

nextstep 178/tcp NeXTStep NextStep #NeXTStep window

nextstep 178/udp NeXTStep NextStep # server

bgp 179/tcp # Border Gateway Proto.

bgp 179/udp

prospero 191/tcp # Cliff Neuman’s Prospero

prospero 191/udp

irc 194/tcp # Internet Relay Chat

irc 194/udp

smux 199/tcp # SNMP Unix Multiplexer

smux 199/udp

at-rtmp 201/tcp # AppleTalk routing

at-rtmp 201/udp

at-nbp 202/tcp # AppleTalk name binding

at-nbp 202/udp

at-echo 204/tcp # AppleTalk echo

at-echo 204/udp

at-zis 206/tcp # AppleTalk zone information

at-zis 206/udp

z3950 210/tcp wais # NISO Z39.50 database

z3950 210/udp wais

ipx 213/tcp # IPX

ipx 213/udp

imap3 220/tcp # Interactive Mail Access

imap3 220/udp # Protocol v3

ulistserv 372/tcp # UNIX Listserv

ulistserv 372/udp

#

# UNIX specific services

#

exec 512/tcp

biff 512/udp comsat

login 513/tcp

who 513/udp whod

shell 514/tcp cmd # no passwords used

syslog 514/udp

printer 515/tcp spooler # line printer spooler

talk 517/udp

ntalk 518/udp

route 520/udp router routed # RIP

timed 525/udp timeserver

tempo 526/tcp newdate

courier 530/tcp rpc

conference 531/tcp chat

netnews 532/tcp readnews

netwall 533/udp # -for emergency broadcasts

uucp 540/tcp uucpd # uucp daemon

remotefs 556/tcp rfs_server rfs #Brunhoff remote filesystem

klogin 543/tcp # Kerberized “rlogin” (v5)

kshell 544/tcp # Kerberized “rsh” (v5)

kerberos-adm 749/tcp # Kerberos “kadmin” (v5)

#

webster 765/tcp # Network dictionary

webster 765/udp

Рассмотрим подробнее процесс подключения к серверному приложению, ожидающему запросы на каком-либо TCP-порту. Данный процесс состоит из двух этапов. На первом этапе клиенту необходимо создать обычное TCP-соединение с указанным TCP-портом сервера. Для этого по схеме, описанной в разделе «Подмена одного из субъектов TCP-соединения в сети Internet», клиент передает на сервер TCP SYN-запрос на необходимый порт.

Сокращение TCP SYN означает TCP-пакет с установленным битом SYN.

Если клиент получает ответ на этот запрос (TCP SYN ACK), то порт открыт и TCP-соединение будет создано. Если же ответ за определенный промежуток времени так и не пришел, то это означает, что либо порт закрыт и соответствующий сервер не запущен, либо имеют место физические проблемы со связью с данным IP-адресом (это достаточно легко проверить, используя утилиты ping или traceroute). На втором этапе, после создания TCP-соединения, клиент и сервер обмениваются специфичными для данных приложений командами, создавая соединение уже на уровне приложения (в терминах модели OSI – на прикладном уровне).

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

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

Все известные на сегодняшний день основные методы сканирования портов в зависимости от возможности определения объектом непосредственного инициатора сканирования (хоста, откуда осуществлялся удаленный анализ) можно разделить на две группы:

1. Методы открытого сканирования: непосредственный инициатор однозначно определяется объектом сканирования по IP-адресу приходящих запросов.

2. Методы «невидимого» анонимного сканирования. Непосредственный инициатор не определяется объектом сканирования (однозначно определяется только «промежуточный» источник сканирующих запросов), таким образом, гарантируется анонимность инициатора сканирования.

Методы открытого сканированияСканирование TCP SYN

Очевидный метод, основанный на принципах создания TCP-соединения и состоящий в последовательной передаче на объект сканирования TCP SYN-запросов на создание соединения на различные порты. Если порт открыт, то на данный сканирующий запрос будет получен ответ TCP SYN ACK; если же порт закрыт – ответом будет TCP RST.