Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК

Существует ряд программ (например, Glide), которые, используя описанную выше «дырку», мгновенно извлекают из PWL файлов хранящуюся в них информацию, в том числе и пароль доступа в Internet.

Уже в Windows 95 ORS 2 механизм шифрования был существенно усовершенствован. Вместо вращения битов для свертки пароля разработчики использовали алгоритм MD5, с помощью которого получали четыре двойных слова - хеш значения имени и пароля. Поэтому, перебором хеш значений расшифровать PWL файл стало не быстрее, чем перебором исходных паролей. Простой подсчет показывает, что всего существует 2 128возможных хеш-значений, полный перебор которых потребует весьма длительного времени. При скорости 250 000 комбинаций в секунду (ниже объяснено почему) в худшем случае понадобится порядка 15 753 813 283 376 780 715 896 972 566 дней, а в среднем в два раза меньше [183].

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

Скорость же перебора паролей (по сравнению с предыдущей версией Windows) падает приблизительно в два раза, за счет использования более громоздких алгоритмов получения хеш-значений пароля и проверок его подлинности. Подробное описание потребовало бы много места и, поэтому, здесь не приводится. Вся необходимая информация может быть получена путем дизассемблирования файла MSPWL32.PWL. Весьма вероятно, что в реализации механизмов шифрования оказались допущены грубые ошибки, не описанные здесь. Автор не проводил детальных исследований и ни за что поручиться не может.

Отличия Windows 98 от Windows 95 ORS 2 незначительны: снято ограничение на максимальную длину пароля, вот, пожалуй, и все. Однако, простые пароли, выбираемые пользователями, по-прежнему позволяют вскрыть PWL за короткое время, но в целом, защиту можно считать удовлетворительной.

O Протокол telnet

O Протокол rlogin

O Протокол SMTP

O Протокол POP3

O Протокол IMAP4

O Протокол NNTP

O Протокол HTTP

O Протокол CGI

O Атака на telnet-сервер

O Атака на SMTP-сервер

O Атака на POP3-сервер

O Атака на NNTP-сервер

O Атака на HHTP-сервер

O Атака на telnet-клиента

O Атака на SMTP\POP3 клиента

O Атака на NNTP-клиента

O Атака на HTTP-клиента

O Устройство почтового сервера

O Анонимная рассылка корреспонденции

O Анонимное получение корреспонденции

O Постиг сообщений в модерируемые конференции

O Безопасность Java-приложений

В основе межсетевого общения лежат протоколы - соглашения, выполняемые сервером и клиентом. А сетевые атаки, в свою очередь, базируются либо на ошибках реализаций протоколов, либо используют уязвимости самих протоколов. В главах «Атака на Windows NT» и «Атака на Windows 95» уже упоминался прикладной протокол SMB, слабости реализации которого позволяют злоумышленнику подбирать пароль для входа в систему, устанавливать подложный именной канал и т.д.

Реализации других протоколов также порой далеки от совершенства и часто позволяют злоумышленнику выполнять действия никак не запланированные ни разработчиками, ни администратором системы. Следует различать понятия «протокола» от «реализации протокола». Сам протокол - это только набор соглашений, правил и договоренностей, записанный на бумаге [184]. Реализация протокола - «живая» действующая программа, со всеми присущими ей программными ошибками.

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

Собственно, незащищенность UDP протокола еще не повод объявлять этот протокол «плохим», ведь ничто не хорошо и не плохо само по себе. А вот бездумное применение UDP протокола, в ответственных ситуациях, чувствительных к подделке адреса отправителя - плохо, ибо приводит к уязвимости. Так, DNS сервер, работающий на UDP протоколе, позволяет злоумышленнику отправлять ответы от имени DNS, и программное обеспечение жертвы вместо соединения с положенным сервером, неожиданно (и незаметно!) для нее подключается к машине злоумышленника! И жертва, не подозревая подлога, доверчиво передаст свой пароль на «вражеский» узел!