А можно ли сделать так, чтобы троян попал в "белый" список AVZ?
Как известно, наличие собственного "белого" списка программ/модулей выгодно отличает [I]AVZ[/I] от многих анти-троянских программ и является, наряду с возможностью получения файлов '[I]Исследования системы[/I]', несомненным достоинством [I]AVZ[/I], отмечаемым многими пользователями программы. Однако, при более пристальном рассмотрении оказалось, что при определенных обстоятельствах эти достоинства могут легко превратиться в серьезные недостатки. Итак, ближе к делу...
Несколько дней назад, при обсуждении в [URL="http://virusinfo.info/showthread.php?t=4971"]соседнем разделе[/URL] программ, динамически устанавливающих свои драйверы путем создания временного файла-драйвера, активации драйвера и последущего удаления файла-драйвера (так, как известно, поступают многие программы, в частности - утилиты от [I]Sysinternals[/I], [I]F-Secure BlackLight[/I], некоторые анти-троянские программы и т.д.), [B][URL="http://virusinfo.info/member.php?u=2119"]МОСТ[/URL][/B] выдвинул предложение о том, что было бы неплохо такие временные файлы помещать в базы "чистых" файлов [I]AVZ[/I] с тем, чтобы они при анализе (в частности, в '[I]Исследовании системы[/I]') не попадали в "черные" списки:
[QUOTE=MOCT]
[QUOTE=Зайцев Олег]aintrust прав все три раза - avz.sys грузится как есть, из каталога AVZ и без переименования, и он естественно распознается как безопасный. Есть подозрение, что mc21.tmp - это что-то типа EXE/DLL, хранимой внутри какого-то приложения. Я подобное поведение десятки раз наблюдал на вполне безопасных программах[/QUOTE]
однозначно.
а по поводу безопасности - пусть даже и безопасная, так все равно не помешает в базу чистых добавить, чтобы больше такие записи нас не смущали[/QUOTE]
Не будем сейчас останавливаться на том, как это лучше сделать - путем ли "выдирания" этих файлов из ресурсов, посредством программ восстановления файлов на диске или еще как-то с последующим добавлением в базу "чистых" - это не важно, т.к. "проблему" попадания таких файлов в "черные" списки, как оказалось, это [U]вообще[/U] не решает! [U]Связано это с тем, что [I]AVZ[/I], чтобы принять решение о том, поместить ли файл, соответствующий некоторому процессу/модулю, в "белый" список или нет, должен "увидеть" этот файл на диске, т.е. соответствующий процессу/модулю проверяемый файл банально должен существовать - иначе, казалось бы, как сравнить сигнатуру и ее объект?[/U] Отсюда простой [U]вывод #1[/U]: "соответствующий" процессу/модулю, но не существующий на диске файл [I]AVZ[/I] 100%-но помещает в "черный" список. Для проверки этого обстоятельства я провел простой эксперимент. [I]AVZ[/I], как известно, помещает свой основной драйвер, [I]avz.sys[/I], в "белый" список (см. [URL="http://aintrust.narod.ru/images/avzwhitelist/avz1.png"]скриншот #1[/URL]). Я загрузил [I]AVZ[/I], потом "на лету" переименовал этот файл, [I]avz.sys[/I], в [I]_avz.sys[/I] (т.е. файл для [I]AVZ[/I] как бы исчез!) - и [I]AVZ[/I] сразу же поместил его в "черный" список (см. [URL="http://aintrust.narod.ru/images/avzwhitelist/avz2.png"]скриншот #2[/URL]). Тогда я пошел дальше: вместо оригинального [I]avz.sys[/I], который так и остался пока что переименованным, я сделал копию [I]avz.exe[/I] и переименовал ее в [I]avz.sys[/I] - AVZ, само собой, подлога не заметил и сразу же стал считать avz.sys "чистым" (см. [URL="http://aintrust.narod.ru/images/avzwhitelist/avz3.png"]скриншот #3[/URL] - обратите внимание на длину файла [I]avz.sys[/I] в папке [I]AVZ[/I]).
Ладно, подумал я, а что будет, если начать "подменять" ("сплайсить") файлы на диске (т.е. после запуска "грязного" файла-оригинала его тут же переименовать (не важно, в какое имя!), а в каталог, где он лежит, переписать заведомо "чистый", например, системный, файл, дав ему старое имя "грязного" файла-оригинала)? И - о чудо! :) "Грязные" файлы, с которыми я провел такие манипуляции, тут же для [I]AVZ[/I] превратились в "чистые" - как во всех окнах и отчетах [I]AVZ[/I], так и в '[I]Исследовании системы[/I]'! Я провел этот эксперимент с постоянно запущенным агентом программы [I]Winamp[/I] (ему соответствует файл [I]winampa.exe[/I]), который изначально не находился в "белом" списке [I]AVZ[/I]. Я переименовал этот файл в [I]_winampa.exe[/I], в каталог программы [I]Winamp[/I] переписал заведомо "чистый" файл [I]Блокнота[/I] ([I]notepad.exe[/I]), переименовал его в [I]winampa.exe[/I] - и это все! Процесс, инициированный [I]winampa.exe[/I], для [I]AVZ[/I] тут же стал "чистым" (см. [URL="http://aintrust.narod.ru/images/avzwhitelist/avz4.png"]скриншот #4[/URL] - обратите внимание на графу '[I]Описание[/I]' в '[I]Диспетчере процессов[/I]' [I]AVZ[/I] :))! Итак, простой [U]вывод #2[/U]: описанным выше способом в [I]AVZ[/I] можно сделать "чистым" любой запущенный на выполнение файл - даже новый троян или вирус (и это очень просто!), и этот троян/вирус не попадет в '[I]Исследование системы[/I]', а во всех отчетах будет выглядеть "чистым"! Понятно, что если сигнатура такого файла известна [I]AVZ[/I], и мы запустим сканирование файлов, то этот файл неминуемо будет обнаружен. А что, если неизвестна? :)
Отсюда простой [U]вывод #3[/U]: существующую в [I]AVZ[/I] методику определения "чистых" файлов нужно менять, и чем скорее - тем лучше, т.к. в указанных выше обстоятельствах она не только не помогает, а даже наоборот - вводит в полное заблуждение! Как известно, во время формирования базы "чистых" объектов имя объекта не учитывается, а при анализе же на "чистоту" [I]AVZ[/I] ищет объект в файловой системе [U]только[/U] по имени (плюс полный путь) - никакие другие "признаки"/атрибуты в расчет не берутся! Даже в этом налицо некоторое противоречие!
Что же нужно сделать? Казалось бы, простую вещь: при проверке процесса на "чистоту" проверять не файл на диске, ему "соответствующий", а его образ в памяти, учитывая при этом только те атрибуты, которые остаются неизменными при загрузке файла в память (ведь изначально база "чистых" формируется из файлов, а не из их образов в памяти!). Это, кстати, решило бы проблему и временных файлов-драйверов, а также прочих похожих объектов - ведь в памяти компьютера все эти объекты практически постоянно присутствуют! Казалось бы простую вещь... :) Конечно же - на деле совсем "не простую": вполне вероятно, что "эта простая вещь" потребует пересмотра даже принципа формирования базы "чистых" объектов, не говоря уже о самой методике проверки!
Такие вот дела...
[edit]
PS. Я сделал необходимые правки в описании (особенно это касается вывода #2), т.к. из моего описания не совсем было понятно, что во время всех манипуляций с файлами "грязный" процесс уже должен быть запущен. Насколько я понимаю, именно из-за этой моей "невнятности" сразу же последовал вопрос от [B]HATTIFNATTOR[/B]-а.
toze tormozilo prosto vstalo vse - а еще говорят XP не подвесишь
тема ;))
например я ваще этот guard включить не могу.
как сканер прошелся и все- В меню он выключен.