Защита от хакеров корпоративных сетей

Создание вредоносного кода

Нет никого ужаснее человека, тратящего свое время на обдумывание и конструирование «идеального» вируса или червя. Существовавшие до сих пор черви и вирусы (например, червь Морриса и вирус Melissa) были не раз подвергнуты критике, потому что имели изъяны кода и, следовательно, не были настолько эффективными, как могли бы быть.

Давайте представим вирус, код которого не имеет изъянов. Конечно, вы думаете, что никогда не смогли бы создать ничего подобного. Вы будете удивлены, но в статье, опубликованной в «Вашингтон пост» с заголовком «No Love for Computer Bugs», Джон Шварц (John Schwartz) рассказывает о Фреде Коэне (Fred Cohen), студенты которого выполняли задания по разработке различных вирусов. Это не опечатка. Фред Коэн действительно требует создания вирусов от студентов, обучающихся компьютерной безопасности. Эту статью можно прочитать на сайте: www.washingtonpost.com/wp-dyn/articles/A47155-2000Jul4.html.

Новые методы доставки

Для начала нужно определиться с методом доставки вредоносного кода конечному пользователю. Использование макросов в электронной почте является эффективным решением только при наличии единого для всех пользователей почтового клиента. Впрочем, если вы решите попробовать подобный путь, рекомендую взять за основу почтовую программу Microsoft Outlook. Хотя можно подумать и о реализации множественных сценариев, каждый из которых предназначен для своего почтового клиента. Также имеет смысл присоединить вирус к пересылаемому по электронной почте сообщению, хотя это и не снимет ограничений, связанных с разными платформами (например, файлы с расширением. exe действуют только в операционной системе Windows). Кроме того, нужно как-то убедить пользователя открыть вложенный файл. Впрочем, иногда это совсем не сложно…

Мы уже упоминали про внезапный всплеск популярности рассылаемых по электронной почте анимированных поздравительных открыток. Большинство из них представляет собой присоединенные исполняемые файлы. Это позволяет замаскировать вирус под поздравительную открытку от друга. Многие пользователи немедленно открывают присоединенный файл, ведь они даже не подозревают, что он может содержать вирус. Чтобы поддержать это заблуждение, действительно вложения должны включать в себя поздравление, как, к примеру, червь Pokemon, показывающий анимированную фигурку Пикачу. После выполнения червю необходимо внедриться в почтовый ящик пользователя и/или его адресную книгу и разослать себя по всем найденным адресам. Именно этот прием позволяет создать иллюзию, что сообщение является поздравлением от знакомого. Особо изобретательные злые гении прилагают немалые усилия для имитации методов доставки, используемых крупными серверами, отправляющими открытки (имитируются даже подписи, логотипы, исходный адрес и т. п.). Зачем это делается? Предположим, червь имитирует открытку, посланную с сервера компании AOL. Должен ли AOL заблокировать свой собственный сервис поздравительных открыток? Это, конечно, можно сделать, но принятие подобного решения возможно только после обсуждения, а это даст червю дополнительное время для распространения.

Также стоит обратить внимание на психологическую тактику «доверия», используемую червем Melissa для своего распространения. Червь, просматривая почтовый ящик пользователя, формирует ответы на найденные сообщения электронной почты. Ведь люди, написавшие жертве вируса, в большинстве случаев ждут ответа на свое послание. Если в строке, содержащей тему сообщения, будет указано, что это ответ, большинство пользователей захотят его посмотреть. А так как текст внутри будет состоять всего из одной строки «see attached» («смотрите вложенный файл»), пользователь, скорее всего, откроет вложение, думая, что там-то и содержится основная информация.

Разумеется, существуют способы распространения и помимо электронной почты. Например, для этой цели можно использовать Интернет. Создается впечатление, что очередное уязвимое место в JavaScript, через которое вредоносный код может воздействовать на компьютеры пользователей, обнаруживается каждую неделю. Не стоит забывать также про Java-апплеты, запускаемые на виртуальных машинах, хотя и с ограниченными полномочиями. Можно сделать шаг назад и использовать ActiveX, который не имеет подобных ограничений, а всего лишь предупреждает пользователя о появлении элемента управления ActiveX неизвестного происхождения. Ведь согласно теории вероятности обязательно найдется пользователь, который нажмет кнопку Proceed (Продолжить), так что этот метод тоже не стоит сбрасывать со счетов.

Ускоренные методы распространения

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

Интересный анализ был опубликован студентом Беркли Николасом Вивером (Nicholas Weaver). Он внимательно изучил основные методы поиска червями новых серверов для заражения и сделал заключение, что новый метод, названный им «списком целей», может значительно ускорить процесс распространения червей. Сущность метода заключалась в том, что вместо хаотичного поиска новых мишеней первая волна червей использует заранее созданный список уязвимых серверов. От размера списка зависит, насколько быстро червь проникнет на все указанные в нем серверы и достигнет своей цели. Для дальнейшего распространения он может уже воспользоваться случайным сканированием. По оценкам Вивера, все серверы, находящиеся в исходном списке довольно большого размера, будут заражены за 15 мин. Другой профессионал в области безопасности считает, что если список (полученный массированным сканированием Интернета) составлен только из уязвимых серверов, время распространения червя уменьшится до минут или даже секунд.

Детальный анализ этого метода можно найти по адресу www.csua.berkeley.edu/~nweaver/warhol.html.

Дополнительные аспекты создания вредоносного кода

Михаил Залевский (Michal Zalewski), также известный как «lcamtuf» (смотрите его сайт http://lcamtuf.coredump.cx), написал потрясающую статью «I Don\'t Think I Really Love You». В ней рассматривались последствия деятельности червя I love you, а также анализировались способы создания максимально эффективного червя. Оригинал статьи можно найти на сайте http://archives.neohapsis.com/archives/vuln-dev/2000-q2/0486.html.

В статье рассматривается проект автора «Samhain», посвященный исследованию и разработке идеального червя. Его свойства описываются следую – щим образом.

1. Транспортабельность – червь должен быть независимым от архитектуры компьютера и функционировать в различных операционных системах (в действительности мы рассматриваем UNIX и подобные ему системы, но существует код, работающий даже в DOS/Win).

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

3. Независимость – червь должен быть в состоянии распространяться без помощи пользователя. Для этого служит встроенная база данных.

4. Обучаемость – червь должен непрерывно обучаться новым действиям и техникам. При выпуске более новой версии червя все остальные черви должны ее загрузить через специальные коммуникационные каналы (wormnet).

5. Целостность – структура отдельных червей и их коммуникационных каналов должна быть такой, чтобы ее было сложно отследить, изменить или уничтожить (для этой цели используется шифрование и цифровая подпись).

6. Полиморфизм – чтобы избежать распознавания, червь должен быть полностью полиморфным. Другими словами, у него не должно быть ни одного куска постоянного кода.

7. Эффективность – червь должен быть в состоянии выполнить возложенные на него задачи, например заразить указанную систему, загрузить инструкции и после завершения миссии просто исчезнуть из всех систем.

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