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

Так как обычный размер 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
    Спонтанная перезагрузка или зависание (kernel panic)
    DEC UNIX / OSF1
    2. 0 и выше
    зависание (kernel panic)
    Open VMS for AXP
    Различные
    Смешанные отчеты
    HP-UX
    9. 0 по 10. 20
    Сбой, перезагрузка, зависание.
    Windows NT
    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, Windows NT 4. 0, даже Windows 95 и Windows for WorkGroups 3. 11- абсолютно не реагировали на подобный некорректный запрос, продолжая нормально функционировать. Тогда были предприняты специальные поиски операционной системы, которую бы действительно вывела из строя данная атака. Ей оказалась Windows 3. 11 с WinQVT эта ОС действительно“зависла”.

Этим “экспертам”, которым столь доверяют CERT и С1АС, мы послали запрос, где попросили прояснить возникшую ситуацию, а также уточнить сведения из вышеприведенной таблицы. В полученном нами ответе говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьютере, и, самое главное, от фазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели бы привести описание exploit, созданного для Windows NT 4. 0, задача которого, используя ping, “завесить” собственный компьютер(! ). Сначала предлагалось запустить Web Browser, затем-taskmgr (Task Manager): так Ping Death якобы лучше работает (еще не хватает шаманского бубна! ). И наконец, требовалось запустить 18 ping-процессов (почему не 100? ). Если вы думаете, что после всего этого ваша ОС немедленно“повиснет”, то ошибаетесь! В комментариях к exploit до получения эффекта предлагалось ждать примерно 10 минут, а может быть, несколько больше или несколько меньше.

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

    причины усПЕХА УДАЛЕННЫХ АТАК
    “То, что изобретено одним человеком,
    может быть понято другим”, - сказал Холме.
    А. Конан Доил. Пляшущие человечки
    · Использование нестойких алгоритмов идентификации

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

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

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

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

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

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

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

    · Отсутствие полной информации об объектах РВС

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

     
    · Отсутствие криптозащиты сообщений

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

· Отсутствие выделенного канала связи между объектами сети Internet Глобальная сеть не может быть построена по принципу прямой связи между объектами, поскольку для каждого объекта невозможно обеспечить вы деленный канал связи с любым другим объектом. Поэтому в Internet связь осуществляется через цепочку маршрутизаторов, а следовательно, сообщение, проходя через большое количество промежуточных подсетей, может быть перехвачено. Также к Internet подключено большое число локальных Ethernet-сетей, использующих топологию“общая шина”; в сетях с такой

топологией несложно программно осуществлять перехват сообщений. · Недостаточные идентификация и аутентификация

В базовых протоколах обмена идентификация и аутентификация объектов практически отсутствуют. Так, например, в прикладных протоколах . FTP, TELNET, РОРЗ имена и пароли пользователей передаются по сети в виде открытых незашифрованных сообщений.

· Использование нестойких алгоритмов идентификации объектов при создании виртуального TCP-соединения

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

    · Отсутствие криптозащиты сообщений

В существующих базовых протоколах семейства TCP/IP, обеспечивающих взаимодействие на сетевом и транспортном уровнях, не предусмотрена возможность шифрования сообщений, хотя очевидно, что добавить ее в протокол TCP не составляло труда. Разработчики решили переложить задачу криптозащиты на протоколы более высоких уровней, например прикладного уровня. При этом базовые протоколы прикладного уровня (FTP, TELNET, HTTP и др. ) также не предусматривали никакого шифрования сообщений. Только не так давно появился общедоступный прикладной протокол SSL, встроенный в Netscape Navigator, позволяющий как надежно зашифровать сообщение, так и подтвердить его подлинность. В заключение хотелось бы заметить, что все описанные выше причины, по которым возможна успешная реализация угроз безопасности РВС, делают сеть Internet небезопасной. А следовательно, все пользователи сети могут быть атакованы в любой момент.

    Подведем итоги.

Страницы: 1, 2, 3