Курсовая работа: Несанкционированный доступ к терминалам серверов с операционными системами семейства UNIX

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

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

• Berkeley Software Design, Inc. (BSD);

• 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 или WindowsNT следующую команду: ping -l 65527 victim.destination.IP.address (по этой команде атака и получила свое название - PingDeath).

Так как обычный размер IP-заголовка составляет 20 байт, а размер 1СМР-заголовка - 8 байт, то подобный ICMP-пакет будет превышать максималь­но возможный размер IP-пакета на 20 байт: 65 527 +20+8-65 535 = 20.

Основываясь на приведенном расчете, эти «эксперты» декларировали, что обычной командой ping можно нарушить работоспособность практи­чески любой сетевой ОС. В завершение предлагалась следующая табли­ца тестирования различных операционных систем

Операционная система	Версия ПО	Симптомы
Solaris (x86)	2.4, 2.5, 2.5.1	Перезагрузка
Minix	1.7.4, v2.0 и другие	Сбой
HP3000 MPE/iX	4.0, 5.0, 5.5	Сброс системы
Convex SPP-UX	Все версии	Сбой
Apple Mac	MacOs 7.x.x	Сбой
Windows 3.11 with Trumpet winsock	?	Смешанные отчеты
Novell Netware	3.x	Смешанные отчеты
Windows 95	Все версии	Сбой
AIX	3 и 4	Сброс системы
Linux	2.0.23	Спонтанная перезагрузка или зависание (kernelpanic)
DEC UNIX / OSF1	2.0 и выше	зависание (kernel panic)
Open VMS for AXP	Различные	Смешанные отчеты
HP-UX	9.0 по 10.20	Сбой, перезагрузка, зависание.
WindowsNT	3.5.1	Смешанные результаты
Irix	5.3	зависание (kernel panic)
Windows NT	4	Сбой
SCO Openserver	4.2, 5.0.x	Уязвима
DEC TOPS-20, TOPS-10	Все	Ошибки
Digital Firewall	?	Уязвима
AltaVista Firewall for UNIX	?	Уязвима

(здесь она приводит­ся в сокращении), на которые данная удаленная атака якобы произвела необходимый эффект. Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда исследуемые ОС - IRIX, AIX, VMS, SunOs, FreeBSD, Linux, WindowsNT 4.0, даже Windows 95 и WindowsforWorkGroups 3.11- абсолютно не реагировали на подобный некоррект­ный запрос, продолжая нормально функционировать. Тогда были пред­приняты специальные поиски операционной системы, которую бы дей­ствительно вывела из строя данная атака. Ей оказалась Windows 3.11 с WinQVT - эта ОС действительно «зависла».

Этим «экспертам», которым столь доверяют CERT и С1АС, мы послали запрос, где попросили прояснить возникшую ситуацию, а также уточнить сведения из вышеприведенной таблицы. В полученном нами ответе гово­рилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьюте­ре, и, самое главное, от фазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели бы привести описание exploit, созданного для WindowsNT 4.0, задача которого, используя ping, «завесить» собственный компьютер (!). Сначала предлагалось запустить WebBrowser, затем-taskmgr (TaskManager): так PingDeath якобы лучше работает (еще не хва­тает шаманского бубна!). И наконец, требовалось запустить 18 ping-про­цессов (почему не 100?). Если вы думаете, что после всего этого ваша ОС немедленно «повиснет», то ошибаетесь! В комментариях к exploit до по­лучения эффекта предлагалось ждать примерно 10 минут, а может быть, несколько больше или несколько меньше.

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

причины усПЕХА УДАЛЕННЫХ АТАК

«То, что изобретено одним человеком,

может быть понято другим», - сказал Холме.

А. Конан Доил. Пляшущие человечки

·Использование нестойких алгоритмов идентификации

К сожалению, взаимодействие объектов по виртуальному каналу в распре­деленной ВС не является панацеей от всех проблем, связанных с иденти­фикацией объектов РВС. ВК - необходимое, но не достаточное условие безопасного взаимодействия. Чрезвычайно важным в данном случае стано­вится выбор алгоритма идентификации при создании виртуального кана­ла. Основное требование, предъявляемое к этим алгоритмам, состоит в сле­дующем: перехват ключевой информации, которой обмениваются объекты РВС при создании ВК, не должен позволить атакующему получить итого­вые идентификаторы канала и объектов. Однако в базовых алгоритмах идентифика­ции, используемых при создании ВК в большинстве существующих сетевых ОС, это требование практически не учитывается.

·Отсутствие контроля за виртуальными каналами связи

Объекты распределенной ВС, взаимодействующие по виртуальным кана­лам, могут подвергаться типовой атаке «отказ в обслуживании». Особен­ность этого воздействия состоит в том, что, действуя абсолютно легальны­ми средствами системы, можно удаленно добиться нарушения ее работоспособности. В чем причина успеха данной атаки? В отсутствии необхо­димого контроля над соединением. При этом задача контроля распадается на две подзадачи:

• контроль за созданием соединения;

• контроль за использованием соединения.

Если пути решения второй задачи понятны - обычно соединение раз­рывается по тайм-ауту, определенному системой, - так сделано во всех из­вестных сетевых ОС (однако тут возникает серьезная проблема выбора конкретного значения тайм-аута), то контроль за созданием ВК достаточ­но сложен: в системе, где отсутствует статическая ключевая информация обо всех ее объектах, невозможно отделить ложные запросы на создание соединения от настоящих. Очевидно также, что если один субъект сетево­го взаимодействия будет иметь возможность анонимно занимать неогра­ниченное число каналов связи с удаленным объектом, то подобная систе­ма может быть полностью парализована данным субъектом. Таким образом, если лю­бой объект в распределенной системе способен анонимно послать сооб­щение от имени другого объекта (например, в Internet маршрутизаторы не проверяют IP-адрес отправителя), то в подобной распределенной ВС практически невозможен контроль за созданием виртуальных соедине­ний. Поэтому основная причина типовой угрозы «отказ в обслужива­нии» - это отсутствие приемлемого решения задачи контроля за маршру­том сообщений.

·Отсутствие возможности контролировать маршрут сообщений

Если в РВС не предусмотреть контроля за маршрутом сооб­щения, то адрес отправителя сообщения оказывается ничем не подтверж­денным. Таким образом, в системе будет существовать возможность ра­боты от имени любого объекта путем указания в заголовке сообщения чужого адреса отправителя (IPSpoofing). В подобной РВС затруднитель­но определить, откуда на самом деле пришло сообщение, а следовательно - вычислить координаты атакующего (в Internet невозможно найти ини­циатора однонаправленной удаленной атаки).