1.3. Удаленные атаки

1.3.1. Классификация удаленных атак. В нашей классификации удаленными атаками называются такие атаки, реа­лизация которых не требует иных контактов злоумышленника с атакуемым объектом, кроме собственно средств реализации самой атаки. Здесь имеется в виду, что злоумышленник не обязан физически присутствовать во время атаки или перед ней на объекте или системе, вступать в контакты с ее поль­зователями и т. д. Теоретически он может вообще не иметь никаких знаний об объекте атаки до ее начала. Также подразумевается, что атакуемая систе­ма (для простоты - компьютер) имеет коммуникационное соединение какого-либо рода (чаще всего подключение к компьютерной сети либо уст­ройство доступа "точка-точка" - модем) и на ней запущены соответствую­щие коммуникационные сервисы.

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

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

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

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

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

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

1.3.1.2. По цели. С точки зрения защиты, атаки можно рассматривать, как направленные на конкретные составляющие безопасности - конфиденциальность, целост­ность и доступность.

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

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

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

1.3.1.3. По характеру взаимодействия с жертвой. Относительно характера взаимодействия злоумышленника с системой все удаленные атаки можно разделить на "интерактивные" и "безусловные".

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

- приглашение зайти на определенную страничку в Интернете, в теле которой злоумышленник заблаговременно разместил зловредную програму, автоматически выполняющуюся на компьютере, с которо­го идет ее просмотр (а ошибок в программном обеспечении (ПО), позволяющих это сделать, на сегодняшний день обнаружено порядка нескольких десятков);

- письмо, с приложенной к нему зловредной программой, но имеющей какое-либо деловое или "соблазнительное" название и описание;

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

Интерактивные удаленные атаки неразрывно связаны с социальной ин-жинерией, описанной ранее.

- безусловная атака совершенно не зависит от действий (или бездействия) оператора. Ее успех определяется только характеристиками установленного в системе аппаратного и программного обеспечения и его настройками.

1.3.2. Удаленный сбор информации о жертве.

1.3.2.1. Выяснение адресов. Известно, что самый надежный корабль - это тот, который стоит на берегу и никогда не выходит в море. Так же и самая безопасная информационная система — это компьютер, не имеющий никаких сетевых соединений, вы­ключенный и запертый в сейф.

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

Основным стандартом сетевой работы де-факто стал набор механизмов и про­токолов, обозначаемых аббревиатурой TCP/IP, поэтому в основном речь идет именно об этой сетевой сфере. Но общие принципы могут быть прозрачно или с небольшими изменениями перенесены и на другие типы сетей.

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

Получение сетевого адреса (IP-адреса) или имени домена/хоста потенци­альной жертвы уже дает злоумышленнику информацию, на основе которой он может начинать строить план атаки. Он может получить дополнительно альтернативным путем (без непосредственного обращения к системам жерт­вы) ряд сведений о ней, например, используя службу WHOIS. Дело в том, что, регистрируясь в Глобальной информационной сети, организация (на­пример, ее провайдер) должна предоставить определенную информацию о себе - название, местоположение, возможно, имена и адреса электронной почты администраторов и т. п. Эту информацию можно найти, обратившись в соответствующую службу Глобальной сети. А это уже может послужить основой для формирования, например, списка типовых паролей на основе имен/фамилий, районов города, где расположена организация, городских телефонов и т. д.

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

1.3.2.2. Поиск уязвимостей. Поскольку на конкретной машине может быть (и почти всегда бывает) за­пущено более одного сервиса, то возникает необходимость после поступле­ния пакета в адрес хоста определить, какой из служб он направлен. Эта функция возложена на операционную систему, которая анализирует не­большой числовой параметр транспортного уровня — логический порт, спе­циально размещаемый в пакете отправляющей стороной для этой цели. Так как за распределение пакетов между службами ответственна операционная система, то она же и занимается простейшими служебными сообщениями по поводу того, функционирует ли в данный момент тот или иной логиче­ский порт или нет. При этом о некоторых служебных пакетах (например, для протокола TCP о самом первом пакете - SYN - запросе на соединение) операционная система заботится сама. Поэтому удаленный субъект, иссле­дующий систему, всегда имеет возможность получить полную информацию о запущенных на ней службах, даже если потенциально имелась бы воз­можность их скрывать - например, отвечать на запрос только в том случае, если его аутентичность проверена с помощью криптографической подписи.

За огромным количеством различных служб Интернет - сообществом закреп­лены фиксированные значения логических портов по умолчанию. Напри­мер, WWW-сервер, будучи установлен на любой машине, по умолчанию бу­дет ожидать запросов на порт 80. Наиболее известные пары "номер логического порта/служба" для протокола TCP следующие: 21 - FTP, 23 - Telnet, 25 - SMTP, 80 - HTTP, 110 - РОРЗ.

Например, если такое исследование обнаружило подтверждение установле­ния связи с хостом - потенциальной жертвой по порту 23, то с высокой степенью вероятности можно утверждать, что там функционирует сервис Telnet, который обладает для злоумышленника рядом привлекательных свойств. Например, позволяет выполнять команды в режиме удаленного терминала и не шифрует никакие данные (в том числе и пароли) при пере­даче. Почему речь идет только о высокой степени вероятности работы сер­виса? Потому, что на самом деле хост-жертва может быть лишь приманкой для взломщика (англ. honey-pot), и вместо реального Telnet там функциони­рует программа-имитатор.

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

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

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

- как написано программное обеспечение, реализующее работу службы;

- какие настройки работы программного обеспечения установлены.

Указанное означает, что помимо потенциальных ошибок, заложенных в са­мой природе работы протокола или стандарта, уязвимости могут скрываться в некорректной реализации или настройке, т. е., говоря, например, о FTP-сервере, необходимо отметить не только уязвимость самого протокола FTP, но и то, какое конкретно программное обеспечение поддерживает этот сер­вер, а также, какие настройки сервера установлены — например, разрешены ли доступ анонимным пользователям или команда PUT.

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

Без сомнения первой широко известной сетевой уязвимостью явилась не­устраненная функция debug в программе приема/отправления электронной почты sendmail, которую использовал знаменитый червь Моррисона. Уяз­вимость позволяла исполнять код, содержащийся в полученном программой письме. Дата обнаружения уязвимости - ноябрь 1988 года. Одним (но, ко­нечно, не определяющим) из признаков работы программы sendmail на хос­те можно считать функционирование сервиса протокола SMTP.

А вот, например, бюллетень об уязвимости в одном из самых популяр­ных современных почтовых серверов Microsoft Exchange 5.5. Бюллетень имеет номер MS02-037 и уведомляет о том, что ошибка в реализации разбора параметров одной из команд протокола SMTP позволяет при некоторых дополнительных условиях выполнить в потоке почтового сер­вера свой программный код. Это дает возможность получить полное управление над службой почтового сервера и, при неправильно сконфи­гурированных настройках безопасности Microsoft Windows, над всем компьютером.

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

Сообщения об обнаруженных уязвимостях регулярно публикуются упол­номоченными организациями, например CERT - Computer Emergency Response Team (Команда реагирования по вопросам компьютерной безо­пасности), адрес сайта в Интернете — http://www.cert.org, в том числе и с техническими описаниями сущности потенциальной атаки. Озна­комление с такими материалами должно быть задачей одного или даже нескольких технических специалистов из подразделения информацион­ной безопасности. Наиболее опасные сервисы (сервис управления сетевыми устройствами SNMP и сервис удаленного терминала Telnet) являются одновременно и самыми распространенными.

Таблица 11.2. Наиболее уязвимые интернет-сервисы
Рейтинг	Сервис	Уязвимые инсталляции,%
1	RPC	93,4
2	SMTP	61,1
3	Finger	59,6
4	TFTP	57,4
5	HTTP	42,4
6	DNS	35,0
7	FTP	33,0
8	NFC	30,2
9	SNMP	27,1
10	X-Windows	23,0

Предполагая SNMP-сервис наиболее распространенным, a RPC — наиболее уязвимым, и принимая во внимание, что оба этих сервиса предназначены для управления, авторы очень рекомендуют ограничить использование лю­бой организацией этих сервисов через Интернет.

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

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

Другой вариант поиска путей реализации атак — получение данных об опе­рационной системе, установленной на удаленном хосте. Поскольку сетевая операционная система — это набор различных служб, логично предполо­жить, что каждая операционная система, соответственно, имеет набор уязвимостей. Таким образом, достоверное определение операционной системы на хосте потенциальной жертвы позволяет злоумышленнику начать поиск уязвимостей из предопределенного списка, характерного для данной опера­ционной системы. Одним из методов определения операционной системы удаленного хоста является анализ реакции IP-стека системы (набора сервисов обработки сетевых пакетов по уровням) на специальном образом сфор­мированные некорректные пакеты (англ. system IP-footprint или system IP-fingerprint). Различные операционные системы будут по-разному реагировать на получение таких пакетов, в том числе отвечать на них в уникальном для данного семейства стиле. Наиболее известным примером удаленного анали­затора операционной системы, работающим на основе отправки некоррект­ных сетевых пакетов, является программа nmap.

1.3.3. Наиболее распространенные классы удаленных атак.

1.3.3.1. Вирусы и троянские программы. Как уже указывалось в главе 2, вирусы и троянские программы (трояны) функционально похожи, и многие из зловредных программ в настоящее время несут в себе черты и тех и других, поэтому как пример удаленной атаки рассмотрим их совместно. Теоретически и вирус и троянская про­грамма могут быть примером и локальной атаки (когда злоумышленник сам находится за консолью управления атакуемой системы), но этот случай не так интересен, как удаленная атака "в чистом виде".

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

- Внедрение вируса/троянской программы произойдет только после неко­торых действий пользователя.

- Внедрение произойдет автоматически, используя уязвимость одного из работающих сервисов.

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

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

Пользователь может выступать либо активной, либо пассивной стороной. Яркий пример активных действий — ситуация, когда пользователь сам за­гружает на свой хост программное обеспечение или другой объект, который может скрывать деструктивный код — с дискеты, компакт-диска, по сети. Пассивный вариант действий атакуемого пользователя — он получает пред­ложение от некоего субъекта к загрузке кода (письмо, переданная дискета, диск и т. п.). В этом случае успех или неуспех реализации атаки будет зави­сеть от того, насколько легкомысленно пользователь отнесется к такой за­грузке.

Теперь попробуем еще раз перечислить возможные причины потенциально­го успеха атаки вируса/троянской программы и дать общие рекомендации (рис. 11.1).

1. Ошибки в работе сервиса. Наиболее сложный вид атак, так как может быть произведен без участия самого пользователя. Решение — быть по­стоянно осведомленным о новостях по безопасности производителя сер­виса, о новостях с основных форумов и он-лайн служб безопасности.

2. Несвоевременное обновление ПО. Различают два вида таких ошибок.

• Несвоевременное обновление соответствующих модулей самого сер­виса. Решение — подписка на регулярную рассылку информации об имеющихся обновлениях сервиса.

• Несвоевременное обновление модулей системы защиты сервисов (например, антивирусного программного обеспечения). Решение — приобретать лицензионные системы защиты с соответствующей под­держкой производителем обновления систем.

3. Ошибки в конфигурации. Подобные ошибки довольно трудно преду­преждать, так как они требуют серьезной квалификации администратора сервиса. В качестве общей рекомендации можно высказать следующее:

не давать сервису в функционировании больше прав и возможностей, чем это нужно для выполнения работы. Скажем, если FTP-сервер предназначен только для публикации материалов, нет необходимости остав­лять поддержку команды PUT.

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

• Служба безопасности должна иметь отдельный "полигон" (компью­тер или набор компьютеров) для проверки посторонних информаци­онных объектов. На этот "полигон" пользователи соответственно на­правляют подозрительные или незнакомые информационные объекты.

• Если создание подобного "полигона" невозможно, то его аналог при­дется создать на своем хосте. Последовательность действий в этом случае такова. Следует обеспечить ограничение распространения возможного ущерба — отключить компьютер от сети. Затем создать учетную запись тестового пользователя с минимальными при­вилегиями, необходимыми для исследования информационного объекта. При этом особое внимание обратить на то, чтобы права этой учетной записи на доступ к критическим разделам (системные каталоги и файлы, другие важные объекты) были минимальными — скажем, только на чтение, а полный контроль или даже право на за­пись на жесткий диск имелось бы только для ограниченного (проще всего, одного) каталога, в котором и проводить исследование. Далее, необходимо зарегистрироваться на хосте от имени этого тестового пользователя и получить доступ к исследуемому объекту (переписать его на жесткий диск, вставить дискету и т. д.), произвести его про­верку имеющимися средствами защиты — скажем, антивирусным программным обеспечением. Перед запуском исполняемой части объекта на выполнение рекомендуется посчитать и записать все процессы, выполняемые в текущий момент на хосте, с тем чтобы можно было обнаружить новые несанкционированные процессы. Кроме того, если есть возможность, запустить службу аудита — ре­гистрации попыток записи и другой работы с критическими разде­лами, либо сосчитать и сохранить на независимом устройстве кон­трольные суммы системных и наиболее важных пользовательских файлов. После этого можно произвести запуск исполняемой части и протестировать ее функциональность, получить и скопировать необ­ходимую информацию и т. д. Затем остановить выполнение модуля и проанализировать имеющиеся результаты (новые процессы, новые и модифицированные файлы на диске, журнал аудита). По указан­ным источникам можно сделать определенные выводы об опасности или безопасности исследуемого объекта.

Чтобы отвлечься от теоретических рассуждении, приведем примеры некото­рых нашумевших вирусов 2001 года по бюллетеням CERT.

Вирус Курниковой {Anna Kournikova VBS malicious code) — февраль 2001 года. В качестве основных жертв названы пользователи Microsoft Outlook, кото­рые не произвели соответствующих обновлений по безопасности для своего приложения.

Пользователи получали письмо следующего формата:

SUBJECT: "Here you have, ;o)"

BODY:

Hi:

Check This! ATTACHMENT: "AnnaKournikova.j pg.vbs"

Самое неприятное заключалось в том, что письмо приходило от адресата, с которым пользователь обычно состоял в переписке и которого более или менее знал. Кроме того, если в настройках системы был установлен флажок Скрыть расширения файлов, то пользователь мог не увидеть, что вложенный в письмо файл — это скрипт на языке Visual Basic. Если пользователь пы­тался открыть присоединенный файл, то происходило следующее.

Код создавал в реестре следующий ключ:

HKEY_CURRENT_USER\Software\OnTheFly="Worm made with Vbswg 1.50b"

Далее копировал себя в c:\wiNDOws\AnnaKournikova.jpg.vbs

После этого он пытался послать отдельное письмо с тем же скриптом по всем адресам, обнаруженным в адресной книге. Затем, чтобы предотвратить повторную рассылку, вирус создает ключ:

HKEY_CURRENT_USER\Software\OnTheFly\mailed=l

Широкое распространение вируса может привести к сбоям в работе почто­вых серверов.

Вирусу Красный Код (Code Red worm) посвящено несколько сообщений CERT, так как вирус модифицировался злоумышленниками. Первые сооб­щения датируются июлем 2001 года. Основное воздействие вирус оказал на веб-серверы IIS 4.0 и IIS 5.0, используя атаку на переполнение буфера в динамической библиотеке (DLL) службы индексирования (IIS Indexing Service). Деструктивное действие развивалось следующим образом.

Производилось сканирование хоста-жертвы на наличие открытого порта 80 (протокол HTTP). При обнаружении высылалась соответствующим образом сформированная строка (HTTP GET-запрос), которая и приводила к пере­полнению буфера в обрабатывающем ее сервисе, в результате чего атакуе­мый хост исполнял деструктивный код.

Код проверял на хосте наличие каталога с: \notworm, при обнаружении пре­кращал выполнение, в противном случае начинал порождать процессы по сканированию случайного набора IP-адресов других жертв. Если на атако­ванном хосте по умолчанию был установлен английский язык, то после за­пуска 100 процессов сканирования и установленного промежутка времени, все страницы на сервере заменялись на сообщение:

HELLO! Welcome to http://www.worm.com! Hacked By Chinese! (Привет! Добро пожаловать на http://www.worm.com!. Взломано Китайцем).

Если же английский не являлся языком по умолчанию, то вирус просто продолжал сканирование.

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

Вторая версия вируса Code Red II появилась в августе 2001 года и требовала на хосте-жертве, кроме IIS, еще и установленный Indexing Server 2.0. Вирус использовал тот же механизм переполнения буфера, однако дальнейшее развитие атаки происходило по-другому. Вирус сканировал тот же 80 порт, предполагая наличие веб-сервера. Если устанавливалось успешное соедине­ние, тогда посылался специально сформированный HTTP GET-запрос для переполнения буфера в Службе индексирования (Indexing Server). При успешной реализации, атака имела следующие результаты в зависимости от конфигурации хоста-жертвы.

О Windows 2000 с US 4.0 или US 5.0 и Indexing Server был скомпрометиро­ван на системном уровне и оставлял лазейку для дальнейшего управле­ния системой злоумышленником.

П На NT с IIS 4.0 или US 5.0 с Indexing Server останавливалась работа веб-сервера.

D DSL-маршрутизаторы Cisco 600-й серии прекращали форвардинг паке­тов.

Во всех случаях попытка проникновения вируса могла быть идентифициро­вана при наличии в регистрационном журнале IIS следующих строк.

Для первой версии:

GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN N^WNNNNN^ЩNNNNNNNNN^таNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNШNNNNNNNNNNNNNNNNNNNNNN^TO№^NNNN^INNNNNNNNNNNNNNNNNNNNNNNN^Л^ГNNN NNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9 090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u00 78%u0000%u00=a

Для второй версии:

GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

XXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9 090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u00 78%u0000%u00=a

Вирус Нимда (Админ наоборот) (\V32/Nimda worm), сентябрь 2001 года. Ви­рус распространялся одним из следующих способов:

О от клиента клиенту через электронную почту;

П от клиента клиенту через незащищенные разделенные сетевые ресурсы;

О от веб-сервера клиенту через скомпрометированные веб-сайты;

О от клиента веб-серверу путем сканирования уязвимостей в IIS 4.0/5.0;

П от клиента веб-серверу через использование лазеек, оставленных други­ми вирусами (например, Code Red II).

Основной результат деятельности вируса — изменение веб-документов (htm, html, asp и др.) и исполняемых файлов, а также потенциально возможный отказ в обслуживании по причине массовой рассылки электронных писем и масштабного сканирования сети.

Распространение вируса через электронную почту происходит следующим образом. Клиент получает письмо, состоящее из двух частей (MIME тип "multipart/alternative"). Первая часть определена, как MIME тип "text/html", но не содержит текста, вторая часть определена, как MIME тип "audio/x-wav", но содержит присоединенный бинарный исполняемый файл readme, exe . Некоторые почтовые приложения автоматически запус­кают на выполнение присоединенный файл с таким МШЕ-типом при от­крытии или предварительном просмотре письма. Также вирус может быть инициирован неосторожным пользователем, запустившим присоединенный файл. Обычно длина этого файла была 57 344 байта.

Адреса, по которым рассылался вирус, собирались автоматически из сле­дующих источников: из файлов htm и html в каталоге для веб-кэша пользо­вателя, из содержимого электронных писем пользователя через службу MAPI.

Кроме того, вирус сканировал IP-адреса хостов в поиске уязвимых серве­ров US — лазеек, оставленных другими вирусами и не закрытых соответст­вующими обновлениями уязвимостей. Адреса для сканирования выбирались следующим образом по отношению ко времени сканирования:

О 50% времени сканировались адреса с теми же двумя первыми октетами, что и скомпрометированный хост;

П 25% времени сканировались адреса с тем же первым октетом;

D 25% времени сканировались случайно выбранные адреса.

Зараженный хост пытался отправить копию кода по протоколу TFTP (69 порт протокола UDP) на обнаруженный сервер IIS. Запущенный на сервере вирус в каждой доступной директории размещал свою копию с расширени­ем emi или nws, а к html или asp файлам добавлял JavaScript код.

Дополнительно он открывал доступ по сети к диску С (разделенный ре­сурс — sharing — для "с: \"), создавал учетную запись guest и добавлял ее в группу администраторов. Кроме того, он изменял копии исполняемых би­нарных файлов, добавляя в них троянскую программу, вызывающую код вируса на исполнение.

Сканирующую активность вируса возможно было определить по наличию в регистрационном журнале веб-сервера для порта 80 TCP следующих за­писей:

GET /scripts/root.exe?/c+dir

GET /MSADC/ root. exe ? / c+di r

GET /c/winnt/systeni32/cmd.exe?/c+dir

GET /d/winnt/system32/cmd.exe?/c+dir

GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir

GET /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir

GET / mem bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir

GET /msadc/..%5c../..%5c../..%5c/..\xcl\xlc../..\xcl\xlc../..\xcl\xlc../w innt/system32/cmd.exe?/c+dir

GET /scripts/..\xcl\xlc../winnt/system32/cmd.exe?/c+dir

GET /scripts/..\xc0/../winnt/system32/ond.exe?/c+dir ;E:7 scripts/. .\xc0\xaf. ./winnt/systein32/cmd.exe?/c+dir GET /scripts/.,\xcl\x9c../winnt/system32/cmd.exe?/c+dir GET /scripts/.Л35с../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%2f../winnt/system32/cmd.exe?/c+dir Вирус Покойник. (W32\Goner worm), декабрь 2001 года. Уязвимые системы — Windows системы с установленными приложениями MS Outlook, MS Office, ICQ. Распространяется по электронной почте или при передаче ICQ файла. Представляется в виде программы-заставки (screen saver) — gone.scr, ини­циируется при запуске на исполнение. Электронное письмо имеет следую­щий вид:

Subj ect: Hi! Body: How are you ?

When I saw this screen saver, I immediately thought about you