Актуальные разработки в области макровирусов
1999 Stefan Kurtzhals / VHM
*************************** Перевод by Redarc *************************
Вирусы VBScript наступают?
VBScript - это облегчённый вариант VBA (Visual Basic for
Applications), который был введён в использование с Windows Scripting
Host (WSH) в Microsoft Windows 98 и Internet Explorer 5.0. VBS обладает
той же функциональностью, что и та часть VBA, которую использовали до
сих пор макровирусы. Однако код программы существует в виде
ASCII-текста, который исполняется непосредственно Windows Scripting
Host. Так как файлы VBScript можно просто просматривать в редакторе
ASCII-файлов, Microsoft предлагает инструмент, который позволяет
кодировать так файлы VBScript, что редактируемый сценарий остается
полностью дееспособным. Программисты вирусов использовали этот
инструмент непосредственно для того, чтобы затруднить распознавание
вирусов VBS. К счастью, можно без проблем отключать это шифрование (для
этого нужно найти необходимые таблицы в файле VBSCRIPT.DLL, что не
составляет большой проблемы). HTML-документы также могут содержать
вставки на VBScript. Код этих вставок активируется при просмотре
документа в Microsoft Explorer - этим Microsoft позволила сделать
возможным существование HTML-вирусов.
Используя VBS можно без проблем изменять Registry или файлы, что
является достаточным для создания вируса. В особенности, с помощью
команды CreateObject можно на VBScript создавать множество различных
объектов, как например, объект файловой системы или документ Word и
манипулировать ими. Таким образом возможно создание
Cross-Application-вирусов, которые одинаково успешно могут инфицировать
несколько разных офисных приложений. Пример - это вирусы O97M/Hopper.E
и W97M/Coldape, которые инфицируют VBS-файлы и документы Word. Во время
перехода из VBScript в документ Word вирус может без проблем отключать
встроенную в Microsoft Office защиту от вирусов посредством манипуляций
с Registry. Впрочем, при выполнении VBScrip-программ, создающих
FileSystemObject, обычно показывается предупреждающее сообщение при
установке стандартной безопасности. Однако такой однажды активированный
VBScript может постоянно в будущем отключать эту защиту.
До сих пор вирусы VBS практически не имели распространения.
Ситуация изменилась в последнее время, так как с появлением Microsoft
Office 2000, Internet Explorer 5.0 и Windows 2000 (релиз кандидат)
автоматически соинсталлируется Windows Scripting Host и позволяет
вирусам VBS получить большее распространение, чем это было до сих пор.
VBS/Freelink является до сих пор первым вирусом VBS, который появился в
огромном количестве у пользователей. VBS/Freelink использует простое
шифрование для всех строк (очевидно автор не был знаком с Microsoft VBS
-Encryptor). Вирус создаёт свою копию под именем "RUNDLL.VBS" в
системном каталоге и заносит этот файл в Registry для того, чтобы вирус
выполнялся при каждой загрузке компьютера. Как и W97M/Melissa, этот
вирус содержит функцию массовой рассылки почты и рассылает себя как
Attachment (файл с именем "LINK.VBS") по всем записям, найденным в
адрессной книге пользователя. Дополнительно VBS/Freelink ищет активные
сетевые соединения и создаёт в корневых каталогах этих дисководов свои
копии. Кроме того инфицируются IRC-чат клиенты mIRC и pIRCH
соответствующими INI-файлами, которые распространяют VBS/Freelink как
только пользователь входит в IRC-канал.
Следующий известный VBS-вирус - это VBS/BubbleBoy, который несмотря
на заявления некоторых антивирусных фирм до сих пор не является In The
Wild. Собственно, VBS/BubbleBoy не является никаким особенно интересным
макровирусом - однако, он использует брешь в защите Microsoft Outlook и
Microsoft Outlook Express, которая позволяет активироваться VBScript
без какого-либо предупреждающего сообщения. Этот вирус активируется уже
при просмотре электронной почты, а не при запуске Attachment, как это
было характерно до сих пор для подобных вирусов. Причём Microsoft
Outlook Express позволяет активироваться вирусу даже при просмотре
электронной почты в окне предварительного просмотра. Если это
происходит, вирус через компонент ActiveX (который, очевидно, считается
безопасным) создаёт инфицированный HTA-файл в папке автозапуска. При
этом имя каталога задано твёрдо (инсталляция в "C:\WINDOWS"), поэтому
VBS/BubbleBoy работоспособен только в английском варианте Windows 9x.
Вирус VBS/BubbleBoy, как и вирус VBS/Freelink, содержит функции
массовой рассылки почты и рассылает себя посредством EMail другим
пользователям. Однако он использует способ распространения через
электронную почту только один раз при инфицированнии системы.
Оба вируса созданы одним и тем же автором. Эти вирусы можно найти
на его домашней странице, что к сожалению, после газетных сообщений о
VBS/BubbleBoy, приведёт к тому, что много других вирусописателей также
будут использовать упомянутую брешь в защите. Заплатка от Microsoft,
которая эту брешь в защите устраняет, существует уже очень давно,
однако она установлена не на каждую систему.
Проблемы при распознавании макровирусов для Office 97/2000.
С переходом от Office95 к Office97 Microsoft ввела совместный
макроязык VBA5 и заменила им WordBasic (Word95) и VBA3 (Excel95).
Внутренняя структура VBA5 более сложная, чем в WordBasic и сильно
отличается, к сожалению, от VBA3. Фирма Microsoft не разглашает никакие
полезные сведения о внутреннем формате файла, так что до сегодняшнего
дня ни одна антивирусная прграмма не может действительно правильно
распознавать и обрабатывать макрокоманды VBA5.
Все документы Office (исключая банк данных Access) сохраняются в
так называемом OLE COM-формате (Compound Object Model). OLE COM-файлы
имеют внутреннюю структуру схожую с FAT жёсткого диска и разделены на
секторы, FAT, потоки (Stream) и подкаталоги (Storage). Антивирусные
фирмы нуждались в большом количестве времени, чтобы понять этот формат,
но к сожалению старые версии системного файла "OLE32.DLL",
ответственного за OLE-файлы, содержали ошибки. Из-за этих ошибок
макрокоманды незначительно повреждались в Word95 при до сих пор не
выясненных обстоятельствах. Это приводило к большому количеству
"естественных" мутаций вирусов, как на то указывают многие сотни
вариантов WM/CAP и семейство WM/NPAD. С Windows 2000 Microsoft
расширила OLE COM-формат и позволило создавать переменный размер
секторов - с чем многие антивирусные прграмм до сих пор еще не могут
правильно работать.
Основное построение документа Word95 с макрокомандами показано на
рисунке 1. Все необходимые сведения находятся в Stream ("WordDocument")
и относительно легко интерпретируются. WordBasic использует лексемы и
поэтому документы можно легко анализировать и "декомпилировать".
+---------------+---------------------------+-----------------+
|FIB (заголовок)| 1Table | Заголовок |
|Текст документа| VBA | Таблицы объектов|
|Код макроса | dir | Таблица строк |
|TDT | Thisdocument | P-Code |
| | Modul | Сжатый исходник |
| | __Srp_ | |
| | _VBA_PROJECT | |
| | PROJECT | |
| | PROJECTwm | |
| | WordDocument | |
| | DocumentSummaryInformation| |
+---------------+---------------------------+-----------------+
а) Макросы в Word 95 b) Потоки в Word 97 с) Поток с макросами
Рисунок 1
Заголовок (FIB) содержит кроме прочего сообщения о том, является ли
файл документом или шаблоном и указывает на позицию и размер блока TDT.
Блок TDT содержит все сообщения об отдельных макрокомандах (имя,
размер, позиция в пределах WordDocument-Stream, байт шифрования и
т.д.).
VBA5 делает различие между модулями или классами и макрокомандами.
В пределах одного модуля могут находиться несколько макрокоманд. В
файлах VBA5 сведения распределены для модулей или соответствующих
макрокоманд в нескольких Stream. "1Table"-Stream содержит кроме прочего
TDT (который должен корректироваться при очистке). Все другие
макрорелевантные сведения находятся в "VBA"-Storage (который сам, как
правило, содержится в другом Storage, например "Macros" в Word97).
"dir" - и "__VBA_PROJECT"-Stream содержат почти идентичные сведения,
причем они сохранены в "dir"-Stream в заархивированном виде. Здесь
находятся среди прочего имена всех имеющихся модулей и непосредственные
символы PCode. "ThisDocument" (имя устанавливается в зависимости от
языка и от приложения Office и может называться, например,
"DiesesDokument" или "ThisWorkbook") является модулем классов и
содержится в каждом документе Office с макрокомандами.
Сам код программы находится в отдельном модуле Stream. Когда
выполняется макрокоманда и из неё документ сохраняется, тогда в файле
образуются в большом количестве "__SRP"-Stream. Они содержат готовый
компилированный код программы, который Office сохраняет для ускоренного
выполнения макрокоманд. В Modulstream находится PCode, который
формируется из лексем и нуждается в дополнительной информации из таблиц
с непосредственными символами (__VBA_PROJECT-Stream) и косвенными
символами. Здесь появляется уже первая проблема для многих антивирусных
сканеров. Из-за сложности структуры многие антивирусные фирмы не могут
или не хотят редактировать PCode полностью. Таким образом может
происходить то, что антивирусная прграмма следующие строки кода
различить не может:
ActiveDocument.VBProject.VBComponents.Name = "Test"
NormalTemplate.VBE.VBComponents.Description = "Test"
Modulstream содержит дополнительно полный, заархивированный
исходный текст макрокоманд в формате ASCII. Таким образом существуют в
одном файле две или три копии одного вируса и невозможно сразу
определить, какая копия действительно запускается из Microsoft Office.
Почти все антивирусные прграммы проверяют лишь PCode, который считался
до сих пор самим кодом программы. Исходный ASCII-текст не используется
ни для выполнения ни для отображения исходного текста в редакторе VBA.
Если в файле присутствуют __SRP-Stream, Microsoft Office может их
выполнять, а PCode полностью игнорировать. Происходит это следующим
образом: сравниваются номер версии VBA в __VBA_PROJECT-Stream и номер
версии Office, установленный у пользователя. Если оба номера версии
совпадают, запускается наличествующий __SRP-Stream, а не PCode. Если
номера версии не совпадают, Office использует заархивированный исходный
текст и создаёт новый PCode. Этот механизм нужен, очевидно, для обмена
макросами между различными версиями Office. Так Office97 может читать
макрокоманды созданные в Office2000 и наоборот. Однако это доставляет
антивирусным программам проблемы, так как теперь не возможно сказать
однозначно, какая копия вируса в конце концов будет использована для
выполнения. Если PCode повреждается, например, ошибкой в OLE32.DLL, то
в Office97 появляется новый вариант вируса, а при той же ситуации новая
модификация вируса в Office 2000 не появляется. Ни одна антивирусная
прграмма не проверяет в настоящее время, совпадают ли PCode и исходный
код с вирусом. __SRP-Stream являются временными и совсем не проверяются
и не удаляются, к сожалению, некоторыми антивирусными прграммами при
очистке документа от вируса. Так были известны случаи, когда в
результате лечения удалялся модуль Stream, а __SRP-Stream оставались в
документе. Например, вирус X97M/Laroux оставался работоспособным после
такого лечения, но файл уже не определялся антивирусными сканерами как
инфицированный. Следующий пример - это W97M/Melissa.U. Инфицированный
этим вирусом файл также чистился неправильно. PCode удалялся полностью,
многократно вставлялись дефектные исходные тексты в ошибочную позицию и
номер версии VBA устанавливался на недопустимое значение. Однако
исходный код активировался как собственный код вируса - вирус не
удалялся. Такие повреждения обычно не сохраняются при дальнейшем
распространении вируса, однако, W97M/Melissa имеет функции массовой
рассылки почты, при этом отправляет первоначальный документ - в данном
случае модифицированный файл, в котором некоторые антивирусные сканеры
не могут больше определять вирус.
Оптимальным был бы контроль всех трёх возможных позиций
расположения вируса: PCode, исходный код и Execode (__SRP-Stream).
Однако, это значительно замедлило бы работу антивирусных сканеров, так
как при уже существующем количестве макровирусов VBA5/6 (примерно 5000)
актуализация банка сигнатур уже является большой затратой времени.
Псевдо-паразитические макровирусы - "Sandwiches".
С появлением Service Release 1 (SR1) для пакета Microsoft Office 97
был устранён использованный до сих пор макровирусами способ копирования
собственных модулей:
Application.OrganizerCopy Source:= NormalTemplate.FullName,
Destination:= ActiveDocument.FullName, Name:= "Virus"
SR1 препятствует непосредственному копированию модулей из
глобального шаблона NORMAL.DOT в другие документы. Таким образом все
высоко-конвертированные WM-вирусы и более старые W97M-вирусы потеряли
способность к размножению. Тем не менее, вирусописатели быстро выяснили
как можно обойти это ограничение. Более новые Office
97/2000-макровирусы копируют исходный текст вместо того, чтобы
переносить целый вирусный модуль. Для передачи исходного кода
существуют четыре возможности:
1. .Import/.Export - заменена всего исходного текста в модуле
2. .AddFromString - прибавление текста в конец исходного текста
3. .AddFromFile - прибавление текста в конец исходного текста
4. .InsertLine - вставка текста в начало исходного текста
Тем временем современные макровирусы больше не используют метод
.Import/.Export, так как он определяется любой эвристикой, а три других
метода имеют при определенных обстоятельствах непреднамеренный побочный
эффект. Если вирусописатель исходит из того, что в инфицируемом модуле
отсутствует любой код или он забывает удалить присутствующий код
пользователя, тогда макровирусы, псевдо-паразитически используют
упомянутые выше три метода инфицирования. До сих пор известен только
безуспешный опыт написания паразитического макровируса
(W97M/Intended/Flesh), но часто, плохо разработанные макровирусы, могут
инфицировать нормальные макровирусы и паразитировать на них. Комбинация
нескольких макровирусов в пределах одного модуля называется
"сэндвичем", однако, во многих случаях эти комбинации неработоспособны.
Основанием для этого является то обстоятельство, что VBA не позволяет
использовать два одинаковых имени процедуры/функции в пределах одного
модуля. VBA делает различие лишь между авто-модулями (Modul с именем
AutoOpen и процедурой "Main"), авто-макрокомандой (процедура AutoOpen
()) и обработчиком события (процедура Document_Close ()).
Если присутствуют одновременно авто-макрокоманда и авто-модуль с
одинаковым именем, то авто-модуль не запускается. Если текущий документ
содержит авто-макрокоманду и NORMAL.DOT содержит авто-макрокоманду с
тем же именем, то возникает сообщение об ошибке Microsoft Office. Авто-
макрокоманды имеют более высокий приоритет чем обработчик события,
поэтому процедура AutoOpen() запускается раньше, чем Document_Open().
Если два макровируса инфицируют один модуль (так бывает часто например
с модулем "ThisDocument") и при этом оба используют один и тот же
обработчик события (например, Document_Close()), то в результате эти
вирусы теряют возможность к репликации (и при этом они больше не
определяются многими антивирусными сканерами).
Если два вируса используют различные макроимена, то очередность
инфицирования или приоритет используемых макрокоманд, как правило,
решает, может ли результат стать дееспособным вирусом. Многие
макровирусы изменяют строки программы при инфицировании, например, так
часто имя макрокоманды активации Document_Open() изменяется в Document_
Close(). Например, назовём некий вирус "A" и предположим, что в
"ThisDocument" уже присутствует вирус "B", и при этом вирус "A"
использует ".AddFromString". Таким образом код вируса "A" прибавляется
к коду вируса "B". При этом вирус "A" адресует строки программы,
которыми он хочет манипулировать непосредственно через номера строк.
Однако строки теперь лежат в области кода вируса "B". Если в этом месте
располагается важный код программы, то в результате будет поврежден
вирус "A" и он, как правило, больше не сможет функционировать.
Полиморфные макровирусы семейства "W97M/Class" более проблематичны. Они
заменяют каждую вторую строку программы случайно созданными
комментариями. Если при этом модуль уже был заражен таким вирусом, как
например, W97M/Brenda.A и варианта Class (например, Class.D) этот
модуль инфицирует, то есть Class.D будет располагаться в этом модуле на
втором месте, то полиморфные изменения коснутся каждой второй строкой
вируса Brenda.A. Опрос текста используется для самодиагностики
некоторыми макровирусами, например, содержит ли пятая строка исходного
текста строку "Rem Я вирус". Если один из вирусов в "сэндвиче"
использует этот метод, то дело доходит до повторного инфицирования
модуля, так как маркер одного вируса перемещается при повторном
инфицировании. Таким образом, может получиться, что "сэндвич" будет
содержать две копии первого и одну копию второго вируса (очередность:
вирус 1, вирус 2, вирус 1). При этом имена макрокоманд будут
повторяться и такой "сэндвич" станет неработоспособным.
Большими проблемами распознавания таких комбинаций макровирусов
является во-первых, распространённый в данный момент метод
распознавания вирусов в антивирусных прграммах. Антивирусы почти всегда
являются модулеориентированными, а не макроориентированными. Второй
проблемой является непредсказуемость таких комбинаций макровирусов. Из-
за часто появляющихся повреждений одного вируса полиморфной функцией
второго вируса, результат часто невозможно точно идентифицировать.
|
