Вернемся все-таки к теме статьи. Начнем, конечно же, с широко известного WINNUKE, дата появления которого - 7 мая 1997 года. Автор метода поместил его описание и исходный текст программы в несколько NEWS-конференций. Ввиду крайней простоты метода каждый человек с IQ немногим большим единицы мог вооружиться новейшим оружием и пойти крушить направо и налево. Первой жертвой был www.microsoft.com. Этот сервер "лежал" более двух суток - в пятницу вечером (9 мая) он прекратил откликаться на обращения и только к обеду в понедельник вновь обрел устойчивость. Приходится только пожалеть его администраторов, которые на протяжении всего уик-энда регулярно нажимали волшебную комбинацию трех клавиш, после чего реанимированный сервер падал вновь. А может быть, после первых нескольких попыток оживить сервер их прекратили, кто знает... Конечно же, наряду с жертвой номер один в мае 97-го пали многие серверы, на которых красовалась надпись "windows nt powered", а также серверы и без оной надписи, но все-таки построенные на windows nt. К чести microsoft, следует отметить, что "заплатки" (patch) появились и стали доступны довольно быстро. Дадим краткое техническое описание WINNUKE. Наряду с обычными данными, пересылаемыми по TCP-соединению, стандарт предусматривает также передачу срочных (OUT OF BAND, OOB) данных. Предназначаются они для передачи различной срочной информации по соединению, используемому для передачи обычных данных. На уровне форматов TCP-пакетов это выражается в ненулевом URGENT POINTER. На большинстве компьютеров с операционной системой WINDOWS, установленных в локальной сети, присутствует сетевой протокол NETBIOS, который использует для своих нужд три IP-порта: 137, 138, 139. Как выяснилось, если соединиться с WINDOWS-машиной через 139-й порт и послать туда несколько байтов OOB-данных, то первоначальная реализация NETBIOS, не зная, что делать с этими данными, попросту подвешивает или перезагружает машину. Для WINDOWS 95 это обычно выглядит как синий текстовый экран, сообщающий об ошибке в драйвере TCP/IP и невозможности работы с сетью до перезагрузки операционной системы. WINDOWS NT 4.0 без установленных SERVICE PACK перезагружается, NT 4.0 со вторым SERVICE PACK выпадает в синий экран (синий экран, говорящий о необработанном исключении в коде ядра, нередко называют "BSOD" - BLUE SCREEN OF DEATH). Судя по информации из Сети, такая атака фатальна и для WINDOWS NT 3.51, и для WINDOWS 3.11 FOR WORKGROUPS, и для WINFRAME (в основе находится WINDOWS NT 3.51). Официальные "заплатки" от MICROSOFT можно найти по адресам: ftp://ftp.microsoft.com/bussys....oob-fix - для nt 4.0 с service pack 2; ftp://ftp.microsoft.com/bussys....oob-fix - для nt 3.51 с установленным service pack 5; support.microsoft.com/download/support/mslfiles/vipup11.exe - для windows 95 с winsock версии 1.1; support.microsoft.com/download/support/mslfiles/vipup20.exe - для window95 с winsock 2.0 (service pack 3 для nt 4.0 уже содержит в себе исправление данной ошибки).
Хочется вспомнить достаточно забавную историю. Как выяснилось, вскоре после выпуска SERVICE PACK 3 для WINDOWS NT 4.0, WINNUKE, запущенный с компьютеров APPLE, легко пробивал защиту сервис-пака. Причиной тому послужило существование двух разных стандартов на IP-пакеты, содержащие OOB-данные. Есть стандарт от BERKLEY, а есть стандарт, описанный в RFC. Различие их состоит в том, что URGENT POINTER в двух реализациях вычисляется по-разному, и результаты отличаются друг от друга на единицу. SERVICE PACK 3, защищающий от "своих" OOB-пакетов, оказался беспомощным против пакетов другого стандарта. Поэтому почти сразу вышло дополнительное исправление.
Следует заметить: если для написания оригинального WINNUKE достаточно самых тривиальных функций работы с TCP/IP (программа на PERL занимает 7 строк), то для того, чтобы пробить защиту SERVICE PACK 3, требуется работать с TCP на низком уровне, либо запускать стандартный WINNUKE с платформы, поддерживающей другую реализацию OOB. Само существование OOB-данных, безотносительно к WINNUKE, вызывает достаточно много проблем именно из-за существования двух стандартов, вернее, из-за отсутствия стандарта. Поэтому гарантировать правильную работу программы, использующей OOB, не может никто. Многие умные люди рекомендуют вообще не использовать OOB-данные в своих программах. Собственно, обычно так и поступают. Поэтому весь смысл OOB сегодня - это наличие потенциальных "дыр", позволяющих злоумышленникам изобретать все новые и новые методы атак. Попросту постреляв OOB-данными по открытым TCP-портам, можно попытаться найти какую-либо новую "дырку" в очередной программе. Некоторым, говорят, это удается...
