Механизмы распространения червей

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

И хотя теоретики от безопасности упорно отмахиваются от дыр как от досадных случайностей, нарушающих стройность воздушных замков абстрактных защитных систем, даже поверхностный анализ ситуации показывает, что ошибки проектирования и реализации носят сугубо закономерный характер, удачно обыгранный хакерами в пословице: «Программ без ошибок не бывает. Бывает - плохо искали». Особенно коварны ошибки переполнения, вызываемые (или даже можно сказать -провоцируемые) идеологией господствующих языков и парадигм программирования. Подробнее об этом мы поговорим в следующей статье этого цикла; пока же отметим, что ни одна коммерческая программа, насчитывающая более десяти-ста тысяч строк исходного текста, не смогла избежать ошибок переполнения. Через ошибки переполнения распространялись Червь Морриса, Linux.Ramen, MWorm, Code Red, Slapper, Slammer, Love San и огромное множество остальных менее известных вирусов.

Список свежих дыр регулярно публикуется на ряде сайтов, посвященных информационной безопасности (крупнейший из которых - www.bugtraq.org) и на веб-страничках отдельных хакеров. Заплатки на дыры обычно выходят спустя неделю или даже месяц после появления открытых публикаций, однако в некоторых случаях выход заплатки опережает публикацию, т.к. правила хорошего тона диктуют воздерживаться от распространения информации вплоть до того, пока противоядие не будет найдено. Разумеется, вирусописатели ведут поиск дыр и самостоятельно, однако за все время существования Интернета ни одной дыры ими найдено не было.

Слабые пароли - это настоящий бич всякой системы безопасности. Помните анекдот: «Скажи пароль! Пароль!»? Шутки шутками, но пароль типа «password» не так уж и оригинален. Сколько пользователей доверяют защиту системы популярным словарным словам (в стиле Супер-Ниндзя, Шварценеггер-Разбушевался и Шварценеггер-Продолжает-Бушевать) или выбирают пароль, представляющий собой слегка модифицированный логин (например, логин с одной-двумя цифрами на конце)? Про короткие пароли, пароли, состоящие из одних цифр, и пароли, полностью совпадающие с логином, мы вообще умолчим. А ведь немалое количество систем вообще не имеют никакого пароля! Существуют даже специальные программы для поиска открытых (или слабо защищенных) сетевых ресурсов, львиная доля которых приходится на локальные сети мелких сЬи м и гос да ственных организаций. В силу ограниченных финансов содержать более или менее квалифицированного администратора они не могут и о необходимости выбора надежных паролей, судя по всему, даже и не догадываются (а может быть, просто ленятся - кто знает).

Первым (а на сегодняшний день и последним) червем, использующим механизм подбора паролей, был и остается Вирус Морриса, удачно комбинирующий словарную атаку с серией типовых трансформаций имени жертвы (исходное имя пользователя, удвоенное имя пользователя, имя пользователя, записанное задом наперед, имя пользователя, набранное в верхнем/нижнем регистре и т. д.). И эта стратегия успешно сработала! Червь Nimda использует намного более примитивный механизм распространения, проникая лишь в незапароленные системы, что удерживает его от безудержного распространения, поскольку пустые пароли занимают незначительный процент от всех слабых паролей вообще.

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

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

Человеческий фактор: о пресловутом человеческом факторе можно говорить много. Но не буду. Это вообще не техническая, а сугубо организационная проблема. Как бы не старалась Microsoft и конкурирующие с нею компании защитить пользователя от себя самого, не урезав при этом функциональность системы до уровня бытового видеомагнитофона, еще никому это не удалось. И никогда не удастся. Паскаль, известный тем, что не позволяет вам выстрелить себе в ногу, значительно уступает по популярности языкам Си и Си++, тем, которые отстреливают вам обе ноги вместе с головой в придачу, даже когда вы этого не планировали.

Для решения этой проблемы Червь Морриса использовал несколько независимых механизмов. Во-первых, из каждой зараженной машины он извлекал список доверенных узлов, содержащихся в файлах /etc/hosts.equiv и /.rhosts, а также файлы .forward, содержащие адреса электронной почты. То есть целевые адреса уже не были случайными - это раз. Отпадало большое количество несуществующих узлов - это два. Количество попыток повторного инфицирования сводилось к разумному минимуму - и это три. Подобную тактику используют многие почтовые черви, обращающиеся к адресной книге Outlook Express. И эта тактика очень неплохо работает!

На сайте корпорации Symantec имеется любопытная утилита - VBSim (Virus and Worm Simulation System), выполняющая сравнительный анализ эффективности червей различных типов.

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

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

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

В этом свете весьма показателен процесс распространения вируса Code Red, в пике своей эпидемии заразившего свыше 359 000 узлов в течении 24 часов. Как были получены эти цифры? Программа-монитор, установленная в локальной сети Лаборатории Беркли, перехватывала все проходящие через нее IP-пакеты и анализировала их заголовки. Пакеты, адресованные несуществующим узлам и направляющиеся на 80-й порт, были, очевидно, отправлены зараженным узлом (Code Red распространялся через уязвимость в MS US-сервере). Подсчет уникальных IP-адресов узлов-отправителей позволил надежно установить нижнюю границу численности популяции вируса. При желании процесс расползания вируса по всемирной сети можно увидеть и в динамике - www.caida.org/analysis/security/code-red/newframes-small-log.mov. Там же, на странице http://www.caida.org/ analysis/security/code-red/coderedv2_analysis.xml, содержится текст, комментирующий происходящее зрелище. А зрелище и впрямь получилось впечатляющим и... поучительным. Всем, особенно разработчикам вирусов, настоятельно рекомендую посмотреть. Быть может это научит кое-кого не ронять сеть своим очередным... ммм... творением.

   Предыдущая                                  следующая