CC BY
233
№ 1(19)2009 Н. О. Андреев
Перспективы развития антивирусных продуктов
Сегодня как никогда остро стоят проблемы информационной безопасности в корпоративных сетях. Одной из наиболее существенных здесь видится угроза компьютерных вирусов и прочих вредоносных программ. В статье приводятся некоторые оценки относительно дальнейшего развития ситуации.
Производители антивирусного программного обеспечения не стараются делать принципы функционирования своих продуктов прозрачными, и на то есть серьезные причины. Во-первых, раскрытие механизмов работы влечет за собой появление новых разновидностей вредоносных программ, содержащих средства обхода этих механизмов. Во-вторых, маркетинговая политика требует придания антивирусному продукту имиджа, как можно менее открытого, но при этом выполняющего свои функции эффективнее аналогичных продуктов. Постулат, положенный в основу закрытого программного кода «как именно работает программа — пользователя волновать не должно», наиболее полно раскрывается как раз в антивирусной индустрии. Приведем основные принципы, заложенные в организацию работы этих продуктов:
• сигнатурный анализ;
• эвристический анализ;
• эмуляция выполнения кода;
• постоянный мониторинг операций.
Сигнатурный анализ. Самый примитивный
вид поиска вируса по известным последовательностям кодов — сигнатурам. Используется с самого появления антивирусных программ. На сегодняшний день его эффективность под сомнением.
Эвристический анализ является продолжением сигнатурного, но работает в тех случаях, когда по последовательности кодов нельзя точно определить наличие вируса в файле, когда данные признаки присущи, в том числе, и обычным программам. В связи с этим анализируются подозрительные участки, их порядок и количество. Зачастую эвристический анализ используют в комбинации с сигнатурным, ко-
гда база сигнатур достаточно велика, и недосуг перебирать весь файл в поисках одной из них. В этом случае на совпадение с базой сигнатур проверяются только участки кода, специально подобранные модулем-эвристиком.
Эмуляция выполнения кода. Довольно прогрессивный метод. Здесь подозрительный код запускается в рамках виртуальной машины, в так называемой песочнице. После этого виртуальная машина останавливается для анализа состояния на предмет признаков заражения. Довольно прогрессивный метод, однако существуют антиотладочные приемы (они же используются при разработке систем защиты программного обеспечения), которые определяют истинную среду выполнения и блокируют выполнение вредоносного кода на виртуальных машинах. Кроме того, логика вредоносного программного кода может предполагать условное его выполнение, например, первого числа каждого месяца, либо выбором — по генератору случайных чисел. В этом случае эмуляция бессмысленна, т. к. анализатор не знает всех условий и особенностей работы вируса.
Постоянный мониторинг операций. Наиболее прогрессивный метод, который теоретически позволяет избежать большинства угроз, исходящих от компьютерных вирусов. На практике реализуется следующим образом. Например, некоторая программа пытается установить соединение по сетевому протоколу. Пользователю на экран выдается сообщение об этом, после чего он может либо разрешить данное действие, либо запретить и отослать данную программу в антивирусную лабораторию. То же самое относится и к операциям с системными файлами, а также специфическими ключами
75
№ 1(19)2009 ^
реестра windows / конфигурационными файлами unix.
Кроме того, обработчики-ловушки ставятся и на разнообразные действия высокого уровня, когда, например, при отсылке почты, сервисом предварительно проверяется каждое письмо. Минусом данного подхода является существенное замедление работы при мониторинге файловой системы в реальном времени, а если ресурсы компьютера на 70% используются системой безопасности, это может вызвать недовольство пользователей. К тому же пользователи могут не обладать достаточной квалификацией для самостоятельной оценки степени опасности и разрешать любые действия, сводя на нет все усилия антивирусного продукта [1].
Обратимся к истории развития вредоносных программ. На начальном этапе развития основным инструментом для их создания являлся язык ассемблера, который непосредственно компилируется в машинные коды. Понятно, что любая программа, запущенная на рабочей станции, может быть остановлена в отладчике и исследована при помощи дизассемблера. Таким образом, разработчику антивируса нужно было только найти вредоносный код, скопировать его в базу сигнатур, и на этом жизненный цикл вируса можно было считать законченным.
Однако авторы вирусов, дабы осложнить жизнь своим оппонентам (рис. 1), стали выпускать конструкторы вирусов, с помощью которых любой желающий мог создать вирус, не содержащийся пока в сигнатурной базе какого-g либо антивируса. Принцип действия таких кон-§ структоров заключается в перестановке незначимых участков, а также разбавлении его все-& возможным мусором. Характерные признаки | продуктов таких конструкторов и являются предметом поиска эвристических анализаторов.
Но и этого оказалось мало. Создатели вредоносного программного обеспечения сумели разместить конструктор вируса в его собственном теле. Результаты такого творчества сейчас называют полиморфик-генераторами. Продвинутым может служить продукт деятельности киевской группы вирмейкеров (создателей вирусов) infected voice, выпускавших в конце прошлого века электронный журнал с одноименным названием.
Смысл такой работы в том, чтобы каждую новую копию вируса сделать не похожей на предыдущую. Однако даже интеграция в свой вирус этого полиморфик-генератора требовала высокой квалификации программиста, а с получением такой квалификации желание заниматься преступной деятельностью пропадает. К тому же вирмейкерство тогда не приносило какой-либо прибыли. Но сейчас оно расцвело буйным цветом в связи с распространением сети Internet [2].
Несложно понять, что основная идея регулярного поиска чего-либо на жестких дисках компьютера (общий объем которых в средней рабочей станции сейчас подбирается к терабайту) путем сравнения с шаблоном — по сути своей, ущербна. Соответствие последовательности двоичных кодов какому-либо шаблону, или сигнатуре, а также регулярное обновление баз данных являются определяющими условиями работы антивирусов, и это создает противоречивую ситуацию в среде разработчиков таких программных продуктов.
С одной стороны, чем шире антивирусная база сигнатур, сложнее и, следовательно, эффективнее эвристические алгоритмы, тем больше ресурсов требуется такому программному продукту. С другой, технологии создания вирусов не стоят на месте, и, чтобы отловить
Рис. 1. Технологии защиты вредоносного программного обеспечения от антивирусов
76
№ 1(19)2009
полиморфные вирусы новых видов, требуется все более сложная эвристика. Ведь ни один вирмейкер не выпустит свое творение в свет, пока не убедится, что эвристическому определению популярных антивирусных продуктов оно не подвержено.
В то же время антивирусные продукты рей-тингуются (например, журналом Virus Bulletin) по количеству отловленных свежих образцов вирусов, а старые вирусы из сигнатурных баз никуда не исчезают. Соответственно, с покупкой новой версии антивирусного продукта общая производительность системы будет падать, т. к. даже эвристические алгоритмы обрастают новыми ветками гораздо быстрее, чем оптимизируются [3].
Относительно сигнатурного и эвристического анализа существует мнение, что этот путь, пришедший на смену сигнатурному поиску, все равно ведет в тупик. Многие помнят, как на олимпиадах по программированию в вузах предлагалось задание написать «Куайн» (программу, выводящую на экран самое себя). С этим заданием управлялось довольно большое количество студентов, используя при этом самые разные языки программирования как низкого, так и высокого уровня, вплоть до PHP, Java, C#. Понятно, что прямое обращение к файлу на жестком диске, по условиям задачи, использоваться не могло.
По сути, такая программа представляет собой некое подобие фрактала: если подать ее вывод на вход компилятора или интерпретатора, результатом выполнения все равно останется то же самое. Однако никто не задумывался, что это есть практически готовый шаблон для полиморфик-генератора. Помимо всего прочего, в программу можно добавить функцию, которая бы случайным образом «разбавляла» рабочий код случайными «мусорными» инструкциями, не влияющими на логику программы, но сильно затрудняющими автоматизированное сравнение с шаблоном. Далее полиморфик-генераторы используют перемену мест участков кода, выполнение которых логически между собой не связано.
Для червей остро стоит проблема сокрытия от антивируса боевого кода. Речь идет о пакете данных, который выводит уязвимый сервис
«о
Ol
в нештатный режим работы, после чего происходит перехват управления станцией. В состав Ц боевого кода обычно выходит шелл-код (для за- ^ пуска командного интерпретатора на задан- а£ ном порту), либо connect-back инструкции, для установки обратного соединения с атакующей станцией. Если эти части попадут в сигнатурную базу антивируса, часы червя сочтены. Что может противопоставить этому программист? Меняющийся от версии к версии алгоритм шифрования и ключи.
В итоге мы приходим к следующему. Фрак-талоподобную, самомодифицирующуюся программу на языке высокого уровня очень сложно идентифицировать как вирус путем разбора ее кода. Единственная возможность — запустить ее на реальном процессоре или же в оболочке-эмуляторе и по ее поведению определить, не содержит ли она каких-либо вредоносных инструкций. Но и это не панацея.
Во-первых, существуют методы, позволяющие определить наличие отладчиков, даже работающих в нулевом кольце защиты. В свое время, подобным образом от отладки (на самом деле — от взлома) пытались защититься разработчики платного программного обеспечения. Наконец экспертами было подтверждено, что на разработку защиты так или иначе уходит больше усилий, нежели на ее нейтрализацию опытным аналитиком. Но, тем не менее, следует помнить, что в коде легко может стоять некая проверка на популярный отладчик или эмулятор, и работа программы пойдет совершенно по другой логической ветке, успешно пройдет все тесты и будет признана безопасной.
Во-вторых, даже без хитроумных проверок работа по саморепликации, равно как и другие вредоносные действия, может быть отсрочена до определенной даты или же выполнения неких особых благоприятных условий. В этом случае программа опять-таки пройдет проверку в эмуляторе. А последствия (много позже) могут быть такими, что знаменитый «чернобыльский» вирус winCIH, который уничтожал все данные на жестком диске и в BIOS 26 апреля, покажется детской шалостью.
Таким образом, следует признать, что современные попытки как-то решить проблему безопасности ОС с закрытым программным кодом
77
№ 1(19)2009
выглядят не выигрышно: разработчики, не осязая планов здания, пытаются подпереть то одну, то другую стену (по факту поступления нового вируса, пытаются поскорее внести его в свою базу). Какая из стен «поплывет» в будущем, пользователи и разработчики могут только догадываться, уповая на архитектора, который должен выпускать исправления, пока не надоест...
Помимо всего прочего, системные ошибки зачастую вкрадываются и в сами антивирусы. Так, совсем недавно (летом 2008 года) был опубликован отчет IT консалтинговой фирмы n.runs AG1, занимающейся проблемами безопасности, где сообщалось о нахождении 800 ошибок в антивирусных продуктах различных компаний, по большей части в модулях пар-синга, т. е. анализаторах, за технологичность и эффективность которых платят клиенты. Найденные ошибки позволяли выполнять произвольный код, т. е. программное обеспечение, призванное защищать рабочую станцию или сервер от посягательств, фактически подвергало их дополнительным угрозам. А причины этого кроются в том, что создатели подобных продуктов гонятся за количеством вирусов в сигнатурных базах, а качеству программного кода парсеров уделяют недостаточно внимания. Кроме того, надо понимать, что некоторые приемы оптимизации, позволяющие ускорить выполнение программы, оказывают пагубное влияние на безопасность (и наоборот, комплексные решения распространенных проблем безопасности, как правило, снижают просо изводительность). Наиболее эффективный код § можно писать на низком уровне, используя такие языки программирования как С, С++, даже & ассемблер, но здесь риск ошибки возрастает | в разы по сравнению с прикладными языками.
Что касается способностей вирусов, троя-| нов, руткитов (root kit — средство скрытого § управления) осуществлять вредоносныедейст-| вия, оставаясь незамеченными, и сохранять § неуязвимость от антивирусного программного g обеспечения, то здесь причина — в недоку-^ ментированных функциях операционных сис-а тем, а также ошибках в них. Недокументиро-
I
ванные функции, как правило, позволяют вирусу скрытно стартовать при запуске сеанса, а ошибки помогают повысить привилегии среды окружения, или же дают возможность удаленно заразить другую машину (без непосредственного запуска пользователем зараженных исполняемых файлов, писем, документов). Зачастую одна такая ошибка в несколько секунд поражает целый сегмент ЛВС, и сетевые экраны, к сожалению, малополезны в таких случаях, т. к. защищают от угрозы извне, а внутри сегмента сервисы должны быть доступны.
Администратору остается только оперативно ставить патчи, обновлять антивирусные базы и надеяться, что эксклюзив, еще не попавший в базы,обойдет его сеть стороной.
Если нет надежды на соблюдение разработчиками ПО-требований к безопасности кода, антивирусные базы растут в размерах, производительность, соответственно, падает (к тому же в них самих полно уязвимостей), то какже быть администраторам? Ведь на них возложена ответственность за сохранность данных в корпоративной сети, и в случае чего возможна потеря профессиональной репутации. Как можно уберечься от внезапного заражения сети и потери ею работоспособности, если производители озабочены лишь получением прибыли, исходный код закрыт и лицензия пользователя не дает никаких гарантий?
Может быть, обратиться к системам на основе открытого исходного кода (рис. 2), набирающего сейчас популярность? Например, по данным CNews.ru2, Linux в рамках пилотного проекта внедрен уже в 1092 школах Российской Федерации. Какже с безопасностью там, насколько подвержены эпидемиям эти ОС?
В Unix-системах с заражением вредоносным ПО все несколько сложнее — слишком много дистрибутивов с различными реализациями компиляторов, на которых переполнения, к примеру, происходят по-разному, а также слишком много версий демонов (аналог понятия сервис в Windows). Зачастую администраторы меняют баннер, идентифицирующий демон. Это затрудняет подбор эксплойта и фак-
1 См., например, www.securitylab.ru (прим. ред.).
2 http://www.cnews.ru/news/top/index.shtml?2008/09/04/316 080
78
№ 1(19)2009
«о
01 &
%
О
as
Рис. 2. Методы усиления защиты в Open Source
тически делает невозможным создание многоплатформенного универсального червя.
И это еще не все. Наряду с антивирусным ПО, под Unix распространяются специальные утилиты и патчи (Stack Guard, ProPolice, CCured), системно решающие проблемы безопасности и перекрывающие путь сразу целым классам угроз.
Stack Guard использует чувствительные индикаторы, которые находятся рядом с адресом возврата из функции (и неизбежно затираются при переполнении), что позволяет перед выходом из функции определить попытку взлома и завершить работу программы, если таковая имела место. ProPolice является продолжением идеи Stack Guard, переопределяет локальные переменные и опять-таки добавляет проверок при выполнении программ. Обе программы оформлены как заплатка к компилятору GCC.
Утилита Memwatch, замещающая стандартные библиотеки работы с памятью, также основывается на принципе облачения функций распределения памяти в своеобразную скорлупу, также содержит разнообразные проверки.
CCured по принципу действия напоминает предыдущие разработки, однако работает с исходными кодами, оставляя возможность редактирования их пользователем после добавления собственных проверок. Зачастую это просто необходимо, т. к. после прохода CCured в автоматическом режиме закономерно наступает серьезное падение производительности.
Таким образом, «либо безопасность, либо быстродействие».
Non-executable Stack Patch делает невозможным исполнение кода в сегменте стека (что понятно из названия), опять-таки не спасая от переполнения как такового, что означает отказ в обслуживании, однако получить контроль над машиной уже не удастся. Это патч к ядру Linux.
ITS4 Software Security Tool и Flawfinder являются анализаторами исходных текстов. Они осуществляют поиск ошибок, и дают некие рекомендации на предмет усиления безопасности кода [4].
Можно сделать вывод, что использование подобных утилит и патчей при сборке и компиляции ядра ОС и прикладного ПО намного эффективнее самых дорогих и сложных эвристических анализаторов: вместо «лоскутного» определения тех или иных образцов вредоносных программ по сигнатуре или паттерну мы отсекаем целые классы угроз с потенциалом к заражению станции.
В заключение хотелось бы отметить, что, в отличие от функций антивирусных продуктов, такие методики защиты часто включаются в состав дистрибутивов (например, ProPolice по умолчанию включен в Trusted Debian и OpenBSD), избавляя от необходимости перекомпиляции ядра ОС, а также появляются в компиляторах в качестве режима (задействуются путем установки специальных флагов), что позволяет администратору самостоятельно находить компромиссы в дилемме «производительность — защищенность».
СПИСОК ЛИТЕРАТУРЫ
1. Прокди Р. Г., Алексеев П. П., Козлов Д. А. Антивирусы: Настраиваем защиту компьютеров от вирусов. М.: Наука и техника, 2008.
2. Кузнецов А. А. Защита деловой переписки: Секреты безопасности, защищенности. М.: Экзамен, 2008.
3. Ложников П. С, Михайлов ЕМ. Обеспечение безопасности сетевой инфраструктуры на основе операционной системы Microsoft. М.: Бином, 2008.
4. Манн С., Митчелл Э. Л., Митчелл К. Безопасность Linux. М.: Вильямс, 2003.
79
