Анализ командной строки в CIS 8.2: решенные и нерешенные проблемы

Что такое эвристический анализ командной строки в Comodo Internet Security, и в каких случаях он работает «не в ту сторону».

Добавлено: в версии CIS 10 многие проблемы решены.

В предыдущей заметке разобрана проблема ошибочного наследования привилегий установщика из-за реализации анализа командной строки. Теперь поближе рассмотрим работу анализа командной строки и разберемся с другими его уязвимостями, в особенности — к ложным интерпретаторам.

Напомню суть анализа командной строки. Когда пользователь запускает скрипт, фактически происходит запуск ассоциированной с этим скриптом программы-интерпретатора, а путь к скрипту передается ей в аргументах командной строки. Например, при запуске файла C:\Data\myScript.vbs выполнится команда %windir%\system32\wscript.exe C:\Data\myScript.vbs, и программа-интерпретатор wscript.exe исполнит записанный в файле myScript.vbs код. Однако в окнах CIS (в списке активных процессов, в различных оповещениях) мы увидим в качестве процесса не wscript.exe, а myScript.vbs. В этом и заключается анализ командной строки — при запуске команды вида интерпретатор скрипт воспринимать процесс интерпретатора как скрипт. Таким образом, задача анализа командной строки — определить, когда «интерпретатор» является настоящим интерпретатором, а «скрипт» — настоящим скриптом.

Работа «эвристического» анализа командной строки в CIS

Долгое время CIS решал эту задачу из ряда вон плохо. Определение интерпретаторов осуществлялось... по именам. «Интерпретатором» считался любой файл, названный wscript.exe, cmd.exe, hh.exe, java.exe и т.д.; «скриптом» — вообще любой существующий файл. Т.е. достаточно назвать троянскую программу hh.exe, выполнить команду hh.exe %windir%\system32\svchost.exe — и CIS принимает троянца за svchost.exe, наделяя его соответствующими разрешениями HIPS'а и фаервола.

Таковы практически все популярные версии CIS ниже 8.2, включая излюбленную некоторыми 5.10.

Впрочем, тут еще CIS может предотвратить или виртуализировать сам запуск файла hh.exe. К полному разоружению CIS приведет команда %windir%\System32\cmd.exe /c %windir%\System32\msiexec.exe /i /q & hh.exe %windir%\system32\svchost.exe. Здесь сначала интерпретатор cmd.exe принимается CIS'ом за программу msiexec.exe, которая имеет привилегии установщика. Благодаря этим привилегиям интерпретатор cmd.exe беспрепятственно запускает троянскую программу hh.exe, и та принимается за svchost.exe. Более подробное объяснение этого метода обхода см. в моей предыдущей заметке.

Время от времени в анализ командной строки вносились некоторые изменения. Так, в версии CIS 7 к числу «интерпретаторов» добавили системную программу rundll32.exe. Благодаря этому появилась, в частности, защита от некоторых вирусов, запускающихся посредством ярлыков (мне попадался реальный экземпляр на зараженной флешке: CIS 6 пропускал его запуск). Но версия CIS 7 приобрела и новый баг: уязвимость к скриптам с длинными именами — эта проблема также была обнаружена на «живом» зловреде... В версии CIS 8.0 баг устранили. Однако серьезных изменений в анализе командной строки не производилось.

Ситуация была исправлена в версии CIS 8.2. Во-первых, «скриптами» стали считаться лишь неисполняемые файлы (см. Update). Таким образом, процесс cmd.exe, запущенный командой %windir%\system32\cmd.exe /c %windir%\system32\msiexec.exe, теперь воспринимается именно как cmd.exe, а не msiexec.exe, как было раньше. (Версия CIS 8.2.0.4508 еще принимала за «скрипты» системные программы smss.exe и csrss.exe, в версии CIS 8.2.0.4591 эта ошибка устранена)

Во-вторых, определение «интерпретаторов» тоже изменилось. Эксперименты показывают, что CIS 8.2 считает «интерпретаторами» доверенные программы с именами интерпретаторов, расположенные в реальной среде. А в виртуальной среде программа с именем интерпретатора определяется как «интерпретатор», если в реальной среде на ее месте находится доверенная программа (поясню ниже).

Например, если файл C:\Data\wscript.exe — любой доверенный, то при запуске командой C:\Data\wscript.exe C:\Data\myNotes.txt он будет воспринят CIS'ом как myNotes.txt. Если же программа wscript.exe неопознанная, то она не будет принята за сторонний файл.

Аномалия анализа командной строки в CIS 8.2

Итак, доверенную программу можно выдать за скрипт или любой неисполняемый файл. Поведение, конечно, аномальное, но каких-либо очевидных проблем оно пока не создает. Трудно представить себе, как применить эту особенность для обхода защиты: для этого понадобилось бы осуществлять вредоносную деятельность доверенной программой, выдав ее за скрипт, имеющий разрешения... Выглядит нелепо. Впрочем, иногда пользователи дают разрешения скриптам, java-приложениям и т.п., так что необходимый скрипт, может быть, и найдется. (А если пользователь имел неосторожность задать разрешения целому каталогу, то в качестве «скрипта» подойдет любой неисполняемый файл оттуда.) Итак, предположим, что программе C:\Data\toonel.jar разрешен интернет, и подумаем, грозит ли это обходом фаервола.

Рассмотрим виртуальную среду Comodo. Если в ней просто создать файл с именем интерпретатора, например, hh.exe, то статус «интерпретатора» он не получит, независимо от своей репутации. Другое дело, если этот файл виртуально подменяет реальный доверенный файл. Например, в виртуальной среде можно скопировать вредоносную программу C:\Data\malware.exe на место настоящего интерпретатора. Тогда в виртуальной среде эта программа будет считаться «интерпретатором», и ее можно будет выдать за разрешенное java-приложение, чтобы передать украденные данные. Чтобы выполнить всю последовательность действий, достаточно однострочной команды:

"%PROGRAMFILES%\Comodo\COMODO Internet Security\virtkiosk.exe" -v %comspec% /c "copy C:\Data\malware.exe %windir%\hh.exe /y & %windir%\hh.exe C:\Data\toonel.jar"

Впрочем, в CIS 8.2.0.4674 (в отличие от более ранних сборок) виртуальная подмена системного файла %windir%\hh.exe требует права администратора. Но можно пойти другим путем: сначала в реальной среде поместить любую доверенную программу во временный каталог под именем интерпретатора, а затем виртуально заменить ее вредоносной и запустить, выдав за разрешенное java-приложение. Опять же, достаточно одной команды:

%comspec% /c copy %windir%\notepad.exe %tmp%\hh.exe /y & "%PROGRAMFILES%\Comodo\COMODO Internet Security\virtkiosk.exe" -v %comspec% /c "copy C:\Data\malware.exe %tmp%\hh.exe /y & %tmp%\hh.exe C:\Data\toonel.jar"

Обман анализа командной строки CIS 8.2 в виртуальной среде

Как видим, в виртуальной среде легко обмануть CIS, представив неопознанную программу «интерпретатором» и дав ей разрешения какого-либо скрипта.

Вернемся к реальной среде. Здесь «интерпретатором» можно представить только доверенную программу. Однако вспомним, что занести вредоносный файл в доверенные тоже можно: с помощью привилегий установщика или прямого редактирования базы CIS. Впрочем, это пресекается несложной настройкой.

Вспомним также про «бич» версий 8.x — уязвимость к подмене доверенного файла неопознанным: некоторое время после подмены файл считается доверенным. Поэтому достаточно поместить куда-нибудь любую доверенную программу с именем интерпретатора, временно запустить (чтобы CIS проверил репутацию), а затем подменить вредоносной — и эта вредоносная программа будет считаться «интерпретатором». Остается запустить эту программу, указав в командной строке путь к разрешенному скрипту или java-приложению, — и программа получит права этого скрипта. Все описанные манипуляции проделываются одной строкой:

%COMSPEC% /c copy %windir%\System32\msiexec.exe %tmp%\java.exe /y & %tmp%\java.exe /i /q & copy malware.exe %tmp%\java.exe /y & start "" %temp%\java.exe C:\Data\toonel.jar

Справедливости ради — вариант с «уязвимостью к подмене» работает нестабильно. Обычно запуск неопознанного файла методом подмены происходит успешно. Но запуск с аргументами командной строки, как в приведенном примере, — не всегда. По моим наблюдениям, играет роль опция «Проверять происхождение файлов» в настройке Auto-Sandbox: если она включена, то при запуске подмененного файла именно с аргументами командной строки проактивная защита обнаруживает, что этот файл неопознанный.

Обман анализа командной строки CIS 8.2 в реальной среде

Так или иначе, «обман» все-таки возможен и в реальной среде.

Выше рассмотрены случаи, когда за «интерпретаторы» и «скрипты» принимаются файлы, ими не являющиеся. Возможна и даже более очевидна обратная ситуация: анализ командной строки не срабатывает, и вредоносный скрипт выполняется от имени самого интерпретатора. Например, отсутствует контроль над AutoIt-скриптами (при том, что сам интерпретатор AutoIt3 входит в скрытую базу неподписанных доверенных файлов). Также некоторые виды скриптов могут выполняться переименованными копиями интерпретаторов — они тоже не будут контролироваться CIS'ом, вернее, получат права интерпретаторов. Наконец, команда интерпретатор скрипт может оказаться нераспознанной из-за нестандартного формата, например, %COMSPEC% /c cd . & malware.bat.

Напрашивается довольно очевидное решение некоторых проблем анализа командной строки: считать «интерпретаторами» программы с репутацией доверенных и определенными значениями секции «File Version Information», независимо от имени. По этим двум признакам «интерпретаторы» идентифицировались бы довольно точно. Кроме того, стало бы легко внести в число «интерпретаторов» различные сторонние средства, наподобие AutoIt. Ну и, конечно, в виртуальной среде необходимо анализировать именно те программы, которые запускаются, а не их «прообразы» из реальной среды. Озарит ли разработчиков такая идея?..

Update. Как выяснилось, текст выше чересчур оптимистичен. К сожалению, мое наблюдение, что «скриптами» признаются лишь неисполняемые файлы (более строго — не PE-файлы), не во всех случаях верно. В действительности, все еще можно заставить CIS принять какую-либо программу за любую другую, хоть за svchost.exe, хоть за cis.exe и т.д. Таким образом, даже если фаервол не разрешает выход в интернет никакому скрипту, остается угроза его обхода описанным методом.

Комментарии и отзывы

Добавляя комментарий, ознакомьтесь с Правилами сообщества

Нашли ошибку?