Добавлено: в версии CIS 10 многие проблемы решены.
В предыдущей заметке разобрана проблема ошибочного наследования привилегий установщика из-за реализации анализа командной строки. Теперь поближе рассмотрим работу анализа командной строки и разберемся с другими его уязвимостями, в особенности — к ложным интерпретаторам.
Напомню суть анализа командной строки. Когда пользователь запускает скрипт, фактически происходит запуск ассоциированной с этим скриптом программы-интерпретатора, а путь к скрипту передается ей в аргументах командной строки. Например, при запуске файла C:\Data\myScript.vbs выполнится команда %windir%\system32\wscript.exe C:\Data\myScript.vbs, и программа-интерпретатор wscript.exe исполнит записанный в файле myScript.vbs код. Однако в окнах CIS (в списке активных процессов, в различных оповещениях) мы увидим в качестве процесса не wscript.exe, а myScript.vbs. В этом и заключается анализ командной строки — при запуске команды вида интерпретатор скрипт воспринимать процесс интерпретатора как скрипт. Таким образом, задача анализа командной строки — определить, когда «интерпретатор» является настоящим интерпретатором, а «скрипт» — настоящим скриптом.
Долгое время 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 неопознанная, то она не будет принята за сторонний файл.
Итак, доверенную программу можно выдать за скрипт или любой неисполняемый файл. Поведение, конечно, аномальное, но каких-либо очевидных проблем оно пока не создает. Трудно представить себе, как применить эту особенность для обхода защиты: для этого понадобилось бы осуществлять вредоносную деятельность доверенной программой, выдав ее за скрипт, имеющий разрешения... Выглядит нелепо. Впрочем, иногда пользователи дают разрешения скриптам, 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, представив неопознанную программу «интерпретатором» и дав ей разрешения какого-либо скрипта.
Вернемся к реальной среде. Здесь «интерпретатором» можно представить только доверенную программу. Однако вспомним, что занести вредоносный файл в доверенные тоже можно: с помощью привилегий установщика или прямого редактирования базы 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: если она включена, то при запуске подмененного файла именно с аргументами командной строки проактивная защита обнаруживает, что этот файл неопознанный.
Так или иначе, «обман» все-таки возможен и в реальной среде.
Выше рассмотрены случаи, когда за «интерпретаторы» и «скрипты» принимаются файлы, ими не являющиеся. Возможна и даже более очевидна обратная ситуация: анализ командной строки не срабатывает, и вредоносный скрипт выполняется от имени самого интерпретатора. Например, отсутствует контроль над AutoIt-скриптами (при том, что сам интерпретатор AutoIt3 входит в скрытую базу неподписанных доверенных файлов). Также некоторые виды скриптов могут выполняться переименованными копиями интерпретаторов — они тоже не будут контролироваться CIS'ом, вернее, получат права интерпретаторов. Наконец, команда интерпретатор скрипт может оказаться нераспознанной из-за нестандартного формата, например, %COMSPEC% /c cd . & malware.bat.
Напрашивается довольно очевидное решение некоторых проблем анализа командной строки: считать «интерпретаторами» программы с репутацией доверенных и определенными значениями секции «File Version Information», независимо от имени. По этим двум признакам «интерпретаторы» идентифицировались бы довольно точно. Кроме того, стало бы легко внести в число «интерпретаторов» различные сторонние средства, наподобие AutoIt. Ну и, конечно, в виртуальной среде необходимо анализировать именно те программы, которые запускаются, а не их «прообразы» из реальной среды. Озарит ли разработчиков такая идея?..
Update. Как выяснилось, текст выше чересчур оптимистичен. К сожалению, мое наблюдение, что «скриптами» признаются лишь неисполняемые файлы (более строго — не PE-файлы), не во всех случаях верно. В действительности, все еще можно заставить CIS принять какую-либо программу за любую другую, хоть за svchost.exe, хоть за cis.exe и т.д. Таким образом, даже если фаервол не разрешает выход в интернет никакому скрипту, остается угроза его обхода описанным методом.