Внешние изменения
Если смотреть поверхностно, новых функций почти нет, разве что платный «Безопасный шоппинг» и ряд изменений на уровне интерфейса. Компоновка различных кнопок и списков в окне расширенной настройки стала чуть менее компактной, но в целом гламурненько. Блуждание по интерфейсу позволило все же выявить небольшие функциональные изменения.
Во-первых, к счастью многих, вернули изъятую из версии 8.2 функцию очистки списка файлов от недействительных записей.
Во-вторых, в правилах Auto-Sandbox изменилось задание условий на целевую программу, внешне и функционально:
- появилось условие на пользователя, создавшего файл;
- появилось условие на дату создания файла или его возраст (раньше было только на возраст);
- стало возможным отметить съемный диск как источник происхождения;
- вместе с тем исчезла возможность задавать в качестве расположения программы локальный, съемный или сетевой диск;
- стало невозможным редактировать путь программы-создателя (но в качестве создателя можно указать группу и редактировать путь уже в ней).
В-третьих, изменилось представление журналов событий: журнал «Событий Защиты+» разделен на «События HIPS» и «События Sandbox», а журнал изменений конфигурации разделен на изменения собственно конфигурации, изменения в списке файлов и изменения в списке доверенных поставщиков. Надо сказать, это повысило удобство и наглядность. Разделить бы еще журнал «Событий HIPS» на события собственно HIPS и события облачной проверки...
Обнаружилась также парочка сомнительных, если не сказать «трешевых» нововведений, к которым я вернусь в конце статьи. А пока рассмотрю важные изменения, находящиеся «под капотом».
Сразу предупрежу, что выводы сделаны из тестов на Windows 7 x64, в основном, виртуальной. Где проверялась Windows 10, оговорено отдельно.
Лед тронулся?
Отказ от ADS
В новой версии по-новому реализован учет происхождения файлов. Раньше CIS записывал информацию о происхождении в ADS (альтернативные потоки данных NTFS) самих файлов. При копировании файлов информация о происхождении дублировалась, так как копировались привязанные к файлу ADS. Это обеспечивалось самой операционной системой. Недостатки такого решения — засорение файлов, искажение даты их модификации, конфликты с некоторыми приложениями.
Еще в утекшей альфе CIS 9 я заметил, что все сведения о происхождении CIS стал записывать в собственную базу данных. Также CIS стал самостоятельно отслеживать копирование файлов и записывать данные о каждой копии в таблицу FcTrackingFiles. Удаление также отслеживается: при удалении файла удаляется и соответствующая ему запись из этой таблицы. При этом файлы идентифицируются не по именам, а по их физическому расположению на диске.
Можно предположить, что изначально разработчики таким путем и собирались пойти, так как в базе версии CIS 8 тоже присутствовала таблица FcTrackingFiles, но запись в нее не велась. По неведомым причинам они сбились с этого пути, но, к счастью, временно.
Однако теперь от учета происхождения файлов невозможно отказаться: удалена опция, позволявшая это сделать.
Хотя учет происхождения стал менее конфликтным, нельзя сказать, что повысилась его надежность: риск неучтенных файлов как был, так и остался.
Новые ограничения на размер файлов
Другое важное изменение связано с «проблемой больших файлов», напомню ее. Файлы, размер которых превышал определенную границу (40 МБ), CIS воспринимал по-особому:
- они считались установщиками (а при наличии подписи доверенного поставщика — доверенными установщиками, со всеми вытекающими привилегиями);
- для таких «больших» файлов не работали правила Auto-Sandbox, основанные на хеше или происхождении;
- будучи созданными доверенными установщиками, «большие» файлы не делались автоматически доверенными;
- в отсутствие подписи такие файлы воспринимались «неопознанными», несмотря на добавление в «доверенные» (конкретно для этого поведения граница менялась опцией «Максимальный размер фйала» в настройке антивируса, в остальных случаях она была фиксированной: 40 МБ).
Самое яркое следствие «проблемы больших файлов» — привилегии установщика у таких популярных программ, как Skype (7.7), Opera (29.0), Dropbox (3.6.9).
Что же изменилось в версии CIS 10? Эксперименты дали простой ответ: границу повысили с 40 до 200 МБ. Теперь с превышением именно этого размера начинают проявляться перечисленные особенности (с одним исключением: основанные на хеше правила Auto-Sandbox работают даже для гигабайтных файлов).
Таким образом, для 10-й версии Скайп не будет представлять опасность... до тех пор, пока он не вымахает за 200 МБ.
Сняты привилегии установщика со сборок PortableApps
Еще одна решенная проблема — уязвимость к портативным сборкам. Напомню, что в прежних версиях CIS считал ряд стартеров PortableApps доверенными установщиками. Под «раздачу привилегий» попадал ряд портативных браузеров и некоторые другие программы.
Впрочем, уязвимость к браузерам, собранным в формате PortableApps, более-менее устранили уже в версии CIS 8.2: статус установщиков перестали получать программы с именами FirefoxPortable, OperaPortable и т.п. Однако оставалась проблема с другими портативными сборками, например, 7-ZipPortable.
Теперь стартеры PortableApps не считаются установщиками: стартеры не только браузеров, но и других портативных сборок. Любопытно, что при этом метод версии CIS 8.2, исключавший стартеры по именам, больше не используется.
Поддержка правил с буквами съемных носителей
Приятное и совершенно неожиданное улучшение. Теперь наконец-таки можно защищать от изменения файлы на съемных дисках, регламентировать права программ на них и т.д. В какой-то мере это было достижимо и раньше, но приходилось так или иначе изворачиваться.
Что особенно радует, стала работать блокировка ярлыков на флешках. Значит, теперь можно не городить из-за них огород с Software Restriction Police.
Защита от чтения тоже есть, хотя не полная. Напомню, что содержимое «Папок с защищенными данными» на локальном диске скрывается двумя способами: в реальной среде эти папки запрещено открывать программам, которым в правилах HIPS заблокирован «Диск»; а в виртуальной среде эти папки для всех программ выглядят пустыми. Так вот, на съемных дисках работает только первый способ, а из виртуальной среды данные доступны. Но если какой-либо программе заблокирован «Диск», то при виртуальном запуске ей тоже будет запрещено открывать защищенные папки. Короче, если нужна эффективная защита от чтения — запрещаем «Диск» глобально.
А теперь весомая ложка дегтя. Вся эта радость не работает для виртуальных шифрованных томов VeraCrypt/TrueCrypt, т.е. как раз там, где она наиболее востребована.
В связи с последним возникает опасение, что и вообще для съемных устройство все не так гладко, но с флешками я пока не заметил проблем.
Защита клавиатуры от виртуальной среды
Прямой доступ к клавиатуре из виртуальной среды представлял серьезную опасность, причем не только считыванием вводимых паролей. Виртуально запущенные программы могли отправлять клавиатурные нажатия в реальную среду и в результате запросто выскочить из-под виртуализации. От этого можно было защититься глобальной блокировкой клавиатуры в HIPS, но она создавала проблемы с буфером обмена.
В версии CIS 10 эта уязвимость закрыта, т.е. виртуальная среда сама по себе запрещает прямой доступ к клавиатуре, безо всяких правил. При этом запрет более мягкий, чем в правилах HIPS: доступ к буферу обмена не блокируется и с ним можно нормально работать.
Дополнительная защита монитора
Кроме клавиатуры, от виртуальной среды стал защищаться и монитор. Эта защита выражена, в частности, в запрете создавать рабочий стол. Теоретически таким трюком могут воспользоваться трояны-вымогатели, чтобы заблокировать интерфейс ОС. Хотя против реальных порнобаннеров одной этой защиты оказалось недостаточно, CIS 10 успешно дал отпор тестовой программе.
Прежде этой защиты не было, и даже блокировка «Монитора» в правилах HIPS ее не давала. Сейчас защита работает для виртуально запущенных программ независимо от правил; а для программ, выполняющихся в реальной среде, она достигается блокировкой «Монитора» в правилах HIPS.
Как и в случае с клавиатурой, виртуальная среда защищает монитор мягко: виртуально запущенная программа может снимать скриншоты, когда ее окно активно. Блокировка же «Монитора» в правилах HIPS запрещает делать скриншоты, что мешает корректной работе некоторых программ.
Исправлена защита реестра
Устранена проблема, когда CIS ни в какую не хотел защищать отдельные разделы реестра. На CIS 8 это более-менее решалось заменой аббревиатур полными названиями. В CIS 10 защита работает и с аббревиатурами.
Контроль интерфейса DNS на Windows 10
Прежде CIS неполноценно работал на Windows 10. В частности, не мог защитить системный интерфейс DNS от сторонних приложений. Сейчас защита DNS работает.
Устранена проблема виртуальной установки MSI-пакетов
Раньше возникал сбой при установке MSI-пакетов в виртуальной среде Comodo, если выбрана конфигурация «Proactive Security». Приходилось идти на ухищрения из-за этого.
Теперь проблема решена разработчиками.
Устранены недочеты в работе Auto-Sandbox
Исправлена работа автопесочницы со скриптами. Раньше, если правило Auto-Sandbox срабатывало для скрипта, то оно применялось не в полной мере: не работало ограничение по времени и исключение дочерних процессов. Теперь и то, и другое работает в т.ч. для скриптов.
Еще один мелкий баг автопесочницы: исключение из Auto-Sandbox дочерних процессов не срабатывало, если запуск дочернего процесса более двух минут задерживался оповещением HIPS. Исправлено.
Улучшено ведение списка файлов
CIS 8.x обращался с некоторыми файлами (теми, что из скрытой базы) как с доверенными, не занося при этом их в список файлов. CIS 10 заносит и отмечает в журнале.
Однако неопознанные файлы, блокируемые автопесочницей, как не заносились в список, так и не заносятся.
Исчез конфликт с EMET
Раньше программы, которые защищены в правилах EMET, могли беспрепятственно запускать неопознанные скрипты. Т.е. для них не работал анализ командной строки.
Сейчас анализ командной строки работает, по крайней мере, у меня.
И ныне там
Легкодобываемые привилегии установщика
Как и прежде, защиту легко обойти с помощью привилегий установщика. Автопесочница может худо-бедно противостоять этому при определенной настройке, хипс — нет.
Я иллюстрирую проблему вредоносными ярлыками, но это совершенно не значит, будто вся угроза — в них.
Для получения привилегий достаточно воспользоватсья каким-нибудь признаком установщика, например, характерным именем. Следующая команда, будь она вписана в ярлык, запустит файл malware.exe с привилегиями установщика:
%COMSPEC% /c "copy %COMSPEC% install.exe /y & install.exe /c malware.exe"
Чтоб еще и сделать вредоносный файл доверенным, раньше достаточно было скопировать его «установщиком». Но в CIS 10 копирование не засчитывается, нужно именно создать файл. Не знаю, зачем комодовцы внесли данное изменение, но если вдруг для защиты от уязвимости, то это почти удалось — однострочная команда, добавляющая файл malware.exe в доверенные, увеличилась на целых девять символов (подчеркнуто):
%COMSPEC% /c copy %COMSPEC% install.exe /y & install.exe /c "copy /b nul + malware.exe malware2.exe & malware2.exe"
Казалось бы, что стоило сделать признаки установщика отключаемыми?
Фальшивая защита от шелл-кода
Как читатели уже знают, опция «Обнаруживать внедрение shell-кода» имеет мало общего со своим названием. По сути, она просто отключает внедрение комодовских библиотек в некоторые процессы (почему бы разработчикам не переименовать ее соответственно?).
Немного изменилась работа CIS с процессами, исключенными из этой «защиты». Раньше они могли свободно запускать программы, которые, по правилам автопесочницы, должны блокироваться. Теперь — нет, блокировка срабатывает. Но, как и прежде, не применяются другие ограничения автопесочницы, за исключением виртуализации и ограничения по времени.
Конфликты с Sandboxie
Из-за изменений в «защите от shell-кода» придется немного изменить рекомендации по настройке CIS для Sandboxie: настраивать автопесочницу не на блокировку программ из каталога Sandboxie, а на ограничение.
Как и прежде, из-за CIS на Windows 10 не работает запуск 64-битных программ в Sandboxie. Как и прежде, это частично решается исключениями «защиты от shell-кода». Но плохо.
Обновлено. Конфликт на Windows 10 решается блокировкой файлов guard32.dll и guard64.dll.
Восставшие из зада
Не проверяется репутация интерпретаторов
Да-да, определение интерпретаторов снова стало поименным, даром что эту уязвимость я уже в землю закопал и надпись написал. Снова можно выдать вредоносную программу за любую другую, причем в реальной среде. В сочетании с проблемой установщиков это делается однострочной командой:
%COMSPEC% /c copy %COMSPEC% install.exe /y & install.exe /c "copy /b nul + malware.exe rundll32.exe /y & rundll32.exe %WINDIR%\System32\svchost.exe"
Здесь близлежащий файл malware.exe выдается за svchost.exe, да еще и получает привилегии установщика. Кстати, от этого не спастись, даже если отключить обнаружение установщиков (в настройке песочницы) и доверие к созданным ими файлам (в настройке репутации).
Старая репутация у подмененного файла
В версии CIS 8.2 эта уязвимость была не то чтобы устранена, но при определенной (не очень хорошей) настройке она пропадала. В альфа-версии CIS 9 ситуация стала даже лучше (благодаря отказу от ADS).
Но сейчас получи фашист гранату — после замены доверенного файла неопознанным тот все равно считается доверенным. Эксплуатация уязвимости: копируем любой доверенный файл, запускаем, после завершения заменяем вредоносным, запускаем. Profit. Все делается одной строкой:
%COMSPEC% /c "copy %windir%\System32\msiexec.exe i.exe /y & i.exe /i /q & copy malware.exe i.exe /y & start "" i.exe"
(Здесь по-прежнему наш воображаемый зловред имеет имя malware.exe, а рядом лежит ярлык с указанной командой.)
Проблема короткого хеша
Вернулась лажа, исправленная в CIS 8.2.0.5027. Но дело не настолько плохо, как было раньше. Фактически точь-в-точь повторяется ситуация с CIS 8.2.0.5005: при определении репутации сравнивается криптостойкий хеш Sha1, но если встретится вредоносный файл с тем же коротким хешем Crc32ofSha1, что и у доверенного (ранее занесенного в базу вручную), то случится опасный конфликт. Подробно расписано в отдельной статье.
Конечно, это противно, но я ожидал гораздо худшего.
Невразумительное
А теперь обещанный «треш». Добавлена новая оригинальная кнопка — «Разблокировка приложений». От чего же освобождается «разблокированное приложение»? — От всего. Почти всего...
- Оно добавляется в доверенные файлы.
- Его путь становится исключенным для антивируса.
- Ему назначаются правила фаервола, разрешающие любую сетевую активность (что эквивалентно политике фаервола «Разрешенное приложение»).
- Ему назначаются правила HIPS, разрешающие все, кроме запуска дочерних процессов (что эквивалентно политике HIPS'а «Разрешенное приложение»).
- Создается правило Auto-Sandbox, снимающее контроль с этого приложения и всех его дочерних процессов.
Попробуем понять логику разработчиков: для чего они делали эту функцию. Ведь в большинстве случаев одного только занесения приложения в «доверенные» более чем достаточно: после этого оно не определяется антивирусом, не изолируется автопесочницей, его запуск и активность разрешается HIPS'ом (в «Безопасном режиме»); даже фаервол, если он в «Безопасном режиме», разрешает исходящие соединения.
Зачем же было исключать из антивируса путь к приложению? По-видимому — чтобы не произошло детекта в случае его заражения, ведь тогда нарушится целостность файла, и он не будет доверенным. Тут пригодятся и разрешения HIPS'а. Ну и правила фаервола, разрешающие «разблокированному» приложению любые исходящие и даже входящие соединения, окажутся очень кстати.
Сложнее с автопесочницей. Дело в том, что «разблокированное» приложение задается в разрешающем правиле автопесочницы двумя условиями: путем и репутацией доверенного. Требование к репутации делает это правило слегка бессмысленным: при нарушении целостности «разблокированного приложения» разрешающее правило не сработает (сработает изоляция в песочнице), а при сохранении целостности — доверенное приложение и без того не изолируется. Другое дело, что дочерние процессы «разрешенного приложения» исключатся из автопесочницы по полной программе, какими бы они ни были.
Вернемся к HIPS'у. Разработчики разрешили «разблокированному приложению» разнообразную активность, да забыли разрешить сам его запуск (в правиле для группы «Все приложения», например). И дали права всего лишь «Разрешенного приложения». Почему же не «Системного»? Ведь наверняка это приложение будет дочерние процессы запускать, а там — раз, и оповещение или, того гляди, блокировка. Непорядок. Да и вообще, раз уж приложение «разблокированное» — гулять так гулять — даешь политику «Установка или обновление»! Останется только разрешить внедрение в память процессов CIS и их завершение...
С исключениями из антивируса разработчики тоже не додумали: надо было занести «разблокированное» приложение не только на вкладку «Исключенные пути» (чтобы не было детекта в случае заражения его самого), но и на вкладку «Исключенные приложения» — чтобы антивирус не мешал ему загружать любую заразу.
Как видим, функция «разблокировки приложений» далека от идеала: создаваемые ей дыры есть куда расширять...
После легкого разочарования недоделками «разблокировки приложений» перейдем к изменениям в настройке Auto-Sandbox. Тут разработчики оказались последовательнее.
Опция, определяющая реакцию CIS на неопознанные установщики, стала более гибкой. Раньше она предписывала или молча изолировать неопознанные установщики в песочнице, или показывать оповещение с выбором действий. Сейчас, кроме возможности молча изолировать, появились другие: блокировать любые неопознанные установщики, временно снимать с них ограничения или даже добавлять их в доверенные. Для тех, кто не проникся глубиной последнего нововведения, повторю медленно: Любые. Неопознанные. Установщики. Делать. Доверенными. Выдыхаем.
К счастью, никто не заставляет пользоваться новыми абсурдными функциями. Но цель их внедрения остается туманной...