понедельник, марта 13, 2006
Утилита AVZ и ее "белый" список программных файлов: достоинства и недостатки
Как известно, наличие собственного "белого" списка программных файлов (базы "чистых" файлов) выгодно отличает утилиту AVZ от многих анти-троянских программ и является, наряду с возможностью получения файлов-отчетов Исследования системы, безусловным достоинством, отмечаемым многими пользователями утилиты. Однако же, при более детальном рассмотрении оказывается, что в некоторых обстоятельствах это, казалось бы, неоспоримое достоинство может легко превратиться в серьезный недостаток. Итак, ближе к делу...
Несколько дней назад при обсуждении на форуме VirusInfo программ, динамически устанавливающих свои драйверы (путем создания временного файла-драйвера, активации этого драйвера и последущего удаления файла-драйвера - так, как известно, поступают многие программы, в частности, утилиты от компаний Sysinternals, F-Secure, некоторые анти-троянские программы и т.д.), пользователь МОСТ выдвинул предложение о том, что было бы неплохо такие временные файлы помещать в базы "чистых" файлов AVZ с тем, чтобы они при анализе (в частности, в Исследовании системы) не попадали в "черный" список и не смущали неопытного пользователя.
Не будем сейчас останавливаться на том, как это лучше сделать - путем ли "выдирания" этих файлов из ресурсов, посредством ли программ восстановления файлов на диске или еще как-то (с последующим добавлением в базу "чистых") - это не важно, т.к. проблему попадания таких файлов в "черный" список AVZ, как оказалось, это вообще не решает! Связано это с тем, что AVZ, чтобы принять решение о том, поместить ли файл, соответствующий некоторому процессу/модулю, в "белый" список или нет, должен непременно увидеть этот файл на диске, т.е. проверяемый файл банально должен существовать в момент проверки - а иначе, казалось бы, как сравнить сигнатуру и ее объект? Отсюда мы сделаем вывод #1: файл, соответствующий процессу/модулю, но не существующий в момент проверки сигнатуры на диске, AVZ стопроцентно помещает в "черный" список.
Для проверки этого обстоятельства я провел простой эксперимент. AVZ, как известно, помещает свой основной драйвер, avz.sys, в "белый" список:
Я загрузил AVZ, затем "на лету" переименовал этот файл, avz.sys, в _avz.sys (т.е. файл драйвера для AVZ как бы "исчез"!) - и AVZ сразу же поместил его в "черный" список:
Тогда я пошел дальше: вместо оригинального avz.sys, который так и остался пока что переименованным, я сделал копию avz.exe и переименовал ее в avz.sys - AVZ, само собой, никакого подлога не заметил и сразу же стал считать "новый" avz.sys (а на самом деле - старый avz.exe) "чистым" (обратите внимание на длину файла avz.sys в папке AVZ!):
OK, подумал я, а что будет, если начать "подменять" файлы на диске, т.е. после запуска "грязного" файла-оригинала его тут же переименовывать (не важно, в какое имя!), а в каталог, где он лежит, переписывать заведомо "чистый", например, системный, файл, давая ему старое имя "грязного" файла-оригинала? И - о чудо! "Грязные" файлы, с которыми я провел такие манипуляции, тут же для AVZ превратились в "чистые" - как во всех окнах и отчетах AVZ, так и в Исследовании системы! Я провел этот эксперимент с постоянно запущенным агентом программы Winamp (ему соответствует файл winampa.exe), который изначально не находился в "белом" списке AVZ. Я переименовал этот файл в _winampa.exe, в каталог программы Winamp (C:\Program Files\Winamp) переписал заведомо "чистый" файл Блокнота (notepad.exe), переименовал его в winampa.exe - и все! Процесс, инициированный winampa.exe, для AVZ тут же стал "чистым" (кстати, обратите внимание на графу Описание в Диспетчере процессов AVZ!):
Итак, делаем вывод #2: описанным выше способом в AVZ можно сделать "чистым" любой запущенный на выполнение файл - даже новый троян или вирус (и это совсем просто!), и этот троян/вирус не попадет в Исследование системы AVZ, а во всех ее отчетах будет выглядеть "чистым"! Понятно, однако, что если сигнатура такого файла заранее известна AVZ, и мы запустим сканирование файлов, то этот файл неминуемо будет обнаружен. А что, если сигнатура не будет известна?
Для демонстрации этой уязвимости я написал простое приложение, AVZWhiteListC (в архиве находятся исходный текст и загрузочный модуль), которое, будучи запущенным на выполнение, попадает в "белый" список процессов AVZ и, как следствие, отсутствует в отчете Исследования системы.
Учитывая вышеизложенное, можно сделать вывод #3: существующую в AVZ методику определения "чистых" процессов и соответствующих им файлов нужно менять, и чем скорее - тем лучше, т.к. в указанных выше обстоятельствах она не только не помогает, а даже наоборот - вводит в полное заблуждение! Более того, во время формирования базы "чистых" объектов имя объекта не учитывается, а при анализе же на "чистоту" AVZ ищет объект в файловой системе только по имени (плюс полный путь) - никакие другие признаки/атрибуты в расчет не берутся! Даже в этом факте налицо некоторое противоречие!
Что же нужно сделать? Казалось бы, простую вещь: при проверке процесса на "чистоту" проверять не файл на диске, соответствующий этому процессу, а его загруженный образ в памяти, учитывая при этом только те атрибуты, которые остаются неизменными при загрузке файла в память (ведь изначально база "чистых" формируется из файлов, а не из их образов в памяти!). Это, кстати, решило бы проблему и временных файлов-драйверов, а также прочих похожих объектов - ведь в памяти компьютера все эти объекты практически постоянно присутствуют! Да, казалось бы простую вещь... Но, конечно же, на деле совсем не простую: вполне вероятно, что эта "простая вещь" потребует пересмотра даже принципа формирования базы "чистых" объектов, не говоря уже о самой методике проверки!
Такие вот дела...
Несколько дней назад при обсуждении на форуме VirusInfo программ, динамически устанавливающих свои драйверы (путем создания временного файла-драйвера, активации этого драйвера и последущего удаления файла-драйвера - так, как известно, поступают многие программы, в частности, утилиты от компаний Sysinternals, F-Secure, некоторые анти-троянские программы и т.д.), пользователь МОСТ выдвинул предложение о том, что было бы неплохо такие временные файлы помещать в базы "чистых" файлов AVZ с тем, чтобы они при анализе (в частности, в Исследовании системы) не попадали в "черный" список и не смущали неопытного пользователя.
Не будем сейчас останавливаться на том, как это лучше сделать - путем ли "выдирания" этих файлов из ресурсов, посредством ли программ восстановления файлов на диске или еще как-то (с последующим добавлением в базу "чистых") - это не важно, т.к. проблему попадания таких файлов в "черный" список AVZ, как оказалось, это вообще не решает! Связано это с тем, что AVZ, чтобы принять решение о том, поместить ли файл, соответствующий некоторому процессу/модулю, в "белый" список или нет, должен непременно увидеть этот файл на диске, т.е. проверяемый файл банально должен существовать в момент проверки - а иначе, казалось бы, как сравнить сигнатуру и ее объект? Отсюда мы сделаем вывод #1: файл, соответствующий процессу/модулю, но не существующий в момент проверки сигнатуры на диске, AVZ стопроцентно помещает в "черный" список.
Для проверки этого обстоятельства я провел простой эксперимент. AVZ, как известно, помещает свой основной драйвер, avz.sys, в "белый" список:
Я загрузил AVZ, затем "на лету" переименовал этот файл, avz.sys, в _avz.sys (т.е. файл драйвера для AVZ как бы "исчез"!) - и AVZ сразу же поместил его в "черный" список:
Тогда я пошел дальше: вместо оригинального avz.sys, который так и остался пока что переименованным, я сделал копию avz.exe и переименовал ее в avz.sys - AVZ, само собой, никакого подлога не заметил и сразу же стал считать "новый" avz.sys (а на самом деле - старый avz.exe) "чистым" (обратите внимание на длину файла avz.sys в папке AVZ!):
OK, подумал я, а что будет, если начать "подменять" файлы на диске, т.е. после запуска "грязного" файла-оригинала его тут же переименовывать (не важно, в какое имя!), а в каталог, где он лежит, переписывать заведомо "чистый", например, системный, файл, давая ему старое имя "грязного" файла-оригинала? И - о чудо! "Грязные" файлы, с которыми я провел такие манипуляции, тут же для AVZ превратились в "чистые" - как во всех окнах и отчетах AVZ, так и в Исследовании системы! Я провел этот эксперимент с постоянно запущенным агентом программы Winamp (ему соответствует файл winampa.exe), который изначально не находился в "белом" списке AVZ. Я переименовал этот файл в _winampa.exe, в каталог программы Winamp (C:\Program Files\Winamp) переписал заведомо "чистый" файл Блокнота (notepad.exe), переименовал его в winampa.exe - и все! Процесс, инициированный winampa.exe, для AVZ тут же стал "чистым" (кстати, обратите внимание на графу Описание в Диспетчере процессов AVZ!):
Итак, делаем вывод #2: описанным выше способом в AVZ можно сделать "чистым" любой запущенный на выполнение файл - даже новый троян или вирус (и это совсем просто!), и этот троян/вирус не попадет в Исследование системы AVZ, а во всех ее отчетах будет выглядеть "чистым"! Понятно, однако, что если сигнатура такого файла заранее известна AVZ, и мы запустим сканирование файлов, то этот файл неминуемо будет обнаружен. А что, если сигнатура не будет известна?
Для демонстрации этой уязвимости я написал простое приложение, AVZWhiteListC (в архиве находятся исходный текст и загрузочный модуль), которое, будучи запущенным на выполнение, попадает в "белый" список процессов AVZ и, как следствие, отсутствует в отчете Исследования системы.
Учитывая вышеизложенное, можно сделать вывод #3: существующую в AVZ методику определения "чистых" процессов и соответствующих им файлов нужно менять, и чем скорее - тем лучше, т.к. в указанных выше обстоятельствах она не только не помогает, а даже наоборот - вводит в полное заблуждение! Более того, во время формирования базы "чистых" объектов имя объекта не учитывается, а при анализе же на "чистоту" AVZ ищет объект в файловой системе только по имени (плюс полный путь) - никакие другие признаки/атрибуты в расчет не берутся! Даже в этом факте налицо некоторое противоречие!
Что же нужно сделать? Казалось бы, простую вещь: при проверке процесса на "чистоту" проверять не файл на диске, соответствующий этому процессу, а его загруженный образ в памяти, учитывая при этом только те атрибуты, которые остаются неизменными при загрузке файла в память (ведь изначально база "чистых" формируется из файлов, а не из их образов в памяти!). Это, кстати, решило бы проблему и временных файлов-драйверов, а также прочих похожих объектов - ведь в памяти компьютера все эти объекты практически постоянно присутствуют! Да, казалось бы простую вещь... Но, конечно же, на деле совсем не простую: вполне вероятно, что эта "простая вещь" потребует пересмотра даже принципа формирования базы "чистых" объектов, не говоря уже о самой методике проверки!
Такие вот дела...
# posted by aintrust : 21:55
Comments:
<< Home
Спасибо! :) К своему великому сожалению, давно ничего нового не писал сюда - то времени нет, то желания... Да и переделать внешний вид надо бы немного, а то этот и-фейс начал уже слегка доставать. В общем, впереди много интересной работы и "расследований"! ;)
Отправить комментарий
<< Home
