Методология теста фаерволов на защиту от внутренних атак (сентябрь 2011) - Тесты и сравнения антивирусов

Методология теста фаерволов на защиту от внутренних атак (сентябрь 2011)

В тестировании принимали участие 22 популярные программы комплексной защиты (класса Internet Security, если в линейке нет, то выбирался сугубо фаервол) от различных производителей актуальных на дату начала тестирования версий продуктов (01.07.2011) и работающих на платформе Windows XP SP3:

  1. Avast! Internet Security 6.0.1203.0
  2. AVG Internet Security 2011 (10.0.0.1390)
  3. Avira Premium Security Suite 10.0.0.132
  4. BitDefender Internet Security 2011 (14.0.28.351)
  5. Comodo Internet Security 2011 (5.5.64714.1383)
  6. DefenseWall Personal Firewall 3.12
  7. Dr.Web Security Space 6.0.1.08010
  8. Eset Smart Security 4.2 (4.2.71.2)
  9. F-Secure Internet Security 2011 (1.30.4220.0)
  10. G DATA Internet Security 2012 (22.0.2.26)
  11. Jetico Personal Firewall 2.1 (2.1.0.10)
  12. Kaspersky Internet Security 2012 (12.0.0.374)
  13. McAfee Internet Security 2011 (11.0.572)
  14. Microsoft Security Essentials 2.0.657.0 + Windows Firewall
  15. Norton Internet Security 2011 (18.1.0.37)
  16. Online Armor Premium Firewall 5.0.0.1097
  17. Online Solutions Security Suite 1.5.15307.0
  18. Outpost Security Suite Pro 7.5 (3720.574.1668.464)
  19. Panda Internet Security 2011 (16.00.00)
  20. PC Tools Internet Security 2011 (1.0.0.58)
  21. Trend Micro Titanium Internet Security 2011 (3.0.0.1303)
  22. ZoneAlarm Internet Security Suite 2010 (9.3.37.0)


Тест проводился на специально подготовленном стенде под управлением VMware Workstation 7.1.4. Для каждого антивирусного продукта клонировались "чистые" виртуальные машины под операционной системой Windows XP SP3 со всеми установленными обновлениями на момент начала теста.

Тестирование производилось на двух типах настроек: рекомендуемых производителем стандартные (настройки по умолчания) и максимальных.

В первом случае использовались рекомендуемые производителей настройки по умолчанию и производились все рекомендуемые программой действия.

Во втором случае в дополнение все настройки, которые были отключены в режиме «по умолчанию», но при этом могли повлиять на исход тестирования, включались и/или приводились в максимальное положение (наиболее строгие настройки). Другими словами – под выставлением максимальных настроек понимается перевод всех доступных из графического интерфейса пользователя настроек всех модулей, связанных с детектированием вредоносной файловой или сетевой активности,  к наиболее строгому варианту.

В силу принципиальных отличий DefenseWall по логике работы от конкурентов контролируемые им приложения могут запускаться из доверенной (trusted zone) или из недовернной зоны (untrusted zone). Поэтому в данном случае понятие "максимального" или "стандартного" режима настроек применялось к настройкам контроля приложений в недоверенной зоне.  Тестовые утилиты при тестировании этого продукта запускались из недоверенной зоны (с внешнего носителя). 

 

Таблица 1: Платформа для проведения теста

Процессор Intel Core i5 650 3.2 ГГц
Материнская плата ASUS P7H55M
Видеокарта NVIDIA GeForсe 210
Оперативная память 4096 MB
Жесткие диски WD CWD 10EARS 00Y5B1
Hitachi HDP725040GLA360
Сеть

100 Мбит/сек Ethernet

Операционная система: 

Microsoft Windows XP SP3 (+ все обновления на момент начала тестирования).
Стандартный брандмауэр Windows был отключен (кроме случая с Microsoft Security Essentials 2.0.657.0 + Windows Firewall).

 

Методы тестирования

В зону ответственности фаервола входят следующие виды актуальных атак:

  1. Внешняя атака на хост со стороны сетевых червей, распространяющихся посредством автоматизированной массовой эксплуатации уязвимостей в сетевых службах по широким диапазонам сетевых адресов.
  2. Несанкционированная исходящая сетевая активность со стороны вредоносной программы, выполняющейся на хосте (загрузка дополнительного вредоносного модуля, коммуникация с сервером ботнета и т.п.).

 

Для осуществления несанкционированной исходящей сетевой активности вредоносными программами в настоящее время применяются следующие техники:

  1. Ограничение функционирования или полное отключение фаервола;
  2. Реализация поведения, проходящего мимо зоны реакции эвристических анализиторов фаервола;
  3. Использование «Белого списка» и механизмов исключений фаервола с целью маскировки под процесс, для которого разрешена исходящая сетевая активность.

 

Следует заметить, что в течение последних 2-3 лет технологии обхода фаерволов эволюционировали от многочисленных штучных техник, нацеленных на конкретные продукты и отдельные механизмы реализации фаерволов, к нескольким универсальным техникам. А именно, в настоящий момент наиболее популярны следующие техники обхода фаерволов:

  1. Выполнение кода в режиме ядра. Вредоносная программа, которой удалось загрузить свой драйвер в обход систем защиты, получает неограниченные привилегии с точки зрения контроля и обхода фаервола.
  2. Внедрение в стандартный системный процесс (напр. Services.exe). Поскольку сетевая активность таких процессов разрешена во всех фаерволах «по умолчанию», в результате успешной реализации этой техники вредоносный код получает доступ к сети, независимо от типа используемого фаервола.

 

Одного из двух перечисленных методов в большинстве случаев достаточно для обхода любого фаервола.

Основываясь на этом, для проведения тестирования специально были подготовлены тестовые утилиты для моделирования нужных методов атак, которые отбирались с учетом следующих критериев:

  1. Методы атак должны покрывать основные типы «внутренних» атак (см. выше).
  2. Методы должны отражать поведение реальных вредоносных программ.

 

Таким образом, для теста было отобрано 40 вариантов внутренних атак и подготовлено 40 соответствующих тестовых утилит. Все методы атак можно весьма условно разбить на два уровня сложности – базовый и повышенный.

 

Базовый уровень сложности:

1. Проверка защиты процессов от завершения:

Функции самозащиты представляют собой необходимый минимум функционала любого продукта, решающего задачи в области безопасности. При наличии возможности отключения защиты все остальные её функции теряют смысл. Таким образом, базовый тест самозащиты представляет собой минимальную проверку функций фаервола и служит фундаментом для остальных тестов.

 

1.1. TerminateProcess - использование API функции TerminateProcess.

1.2. TerminateThreads - использование API функции TerminateThread.

1.3.  TerminateProcessJob - использование API функции TerminateJobObject.

1.4. TerminateProcessDebug - использование native API функций NtCreateDebugObject/NtDebugActiveProcess.

1.5.  SendMessage – использование API функции SendMessage.

1.6.  SuspendProcess - использование native API функции NtSuspendProcess.

1.7.  SuspendThreads - использование API функции SuspendThread.

1.8.  StopServiceScm – использование Остановка системных сервисов с использованием Service Control Manager API.

1.9. StopServiceNative - остановка системных сервисов с использованием native API функции NtUnloadDriver.

1.10.      CreateRemoteThread - использование API функции CreateRemoteThread(ExitProcess).

1.11.      CreateRemoteThread(DLL)- использование API функции CreateRemoteThread(LoadLibrary).

1.12.      UnmapSection - использование native API функции NtUnmapViewOfSection.

1.13.      VirtualProtect - использование API функции VirtualProtectEx.

1.14.      TerminateProcessTrusted – использование API функции TerminateProcess от имени доверенного процесса.

1.15.      TerminateThreadTrusted – использование API функции TerminateThread от имени доверенного процесса.

 

2. Защита от стандартных внутренних атак:

Задача данного этапа – тестирование фаерволов на стандартных, хорошо известных, простых и документированных техниках. В их число входят, с учётом современных требований к фаерволам и специфики актуальных угроз (см. раздел «Актуальные угрозы»), два класса техник: обход фаервола через доверенный процесс и загрузка драйвера режима ядра.

 

2.1. IECreateProcess – запуск скрытого процесса InternetExplorer с использованием функции API CreateProcess.

2.2. IEShellExecute - запуск скрытого процесса InternetExplorer с использованием функции API ShellExecute.

2.3. IECreateProcessCMD – запуск скрытого процесса InternetExplorer с использованием функции API CreateProcess с использованием командной строки.

2.4.  URLOpenByExplorer – открытие URL адреса через Windows Explorer.

2.5.  COM - использование интерфейса IWebBrowser2.

2.6.  VBS - использование интерфейса IWebBrowser2 из скрипта VBS.

2.7.  NetAPI - использование RPC вызова NetrJobAdd.

2.8.  ITask - использование интерфейса ITaskScheduler.

2.9.  AT - использование стандартной утилиты AT.EXE.

2.10.      Schtasks - использование стандартной утилиты schtasks.EXE

2.11.      BITS - загрузка произвольного файла из сети средствами стандартной службы Background Intelligent Transfer Service.

2.12.      DrvLoadSCM - загрузка драйвера с использованием Service Control Manager API.

2.13.      DrvLoadNative - загрузка драйвера с использованием native API.

2.14.      DrvLoadSysinfo - загрузка драйвера с использованием функции NtSetSystemInformation.

2.15.      SybvertPathValue - загрузка драйвера путём подмены значения параметра реестра ImagePath для службы легитимного драйвера.

2.16.      SubvertImageFile - загрузка драйвера путём подмены исполняемого файла легитимного драйвера.

 

Повышенный уровень сложности:

3. Тестирование защиты от нестандартных утечек:

Задача данного этапа – оценить возможности защиты тестируемых продуктов от более сложных вариантов обхода фаерволов путем внедрения в процесс, которые недокументированны или малоизвестны, но при этом используются реальными вредоносными программами.

 

3.1. APCInject - инжектирование шеллкода в доверенный процесс с использованием функций NtCreateSection/NtMapViewOfSection для копирования памяти и QueueUserAPC для запуска кода на исполнение.

3.2. InterProcessInject - поэтапное инжектирование кода в доверенный процесс, при котором каждая операция (выделение памяти, копирование кода, создание потока, и т.д.) осуществляется из новой копии злонамеренного процесса.

3.3. WORD - внедрение DLL в контекст процесса WORD.EXE (Microsoft Office Word) средствами встроенного в него интерпретатора VBS-сценариев. Создание нового документа Word из контекста злонамеренного процесса происходит с помощью COM-объекта "Word.Application".

 

4. Тестирование защиты от нестандартных техник проникновения в режим ядра:

Задача данного этапа – оценка способности тестируемых продуктов по блокировке выполнения неавторизованного кода в режиме ядра. Подобные функции, строго говоря, не относятся к зоне ответственности фаерволов. Вместе с тем, без защиты режима ядра фаервол легко обходится, и все остальные его функции оказываются бесполезными.

 

4.1. InstallHinfSection- Устанавливает драйвер режима ядра, используя .INF-файл и API функцию InstallHinfSection из SETUPAPI.DLL, вызываемую из контекста системного процесса RUNDLL32.EXE.

4.2. Scheduler - выполнение установки драйвера режима ядра в виде отложенного задания Task Scheduler-а (служба планировщика заданий). Задание создаётся путём вызова функции NetrJobAdd через RPC сервер ATSvc.

4.3. PrintInject - внедрение DLL в процесс службы диспетчера печати (SPOOLSV.EXE) используя документированную API функцию AddPrintProvidor. Внедрённая библиотека выполняет загрузку драйвера режима ядра.

4.4. MoveFile - замена зарегистрированного в системе драйвера режима ядра с помощью API функции MoveFileEx с флагом MOVEFILE_DELAY_UNTIL_REBOOT, при использовании которого непосредственно операция копирования/перемещения файла будет отложена до следующей загрузки системы, в процессе которой отложенные файловые операции осуществляются диспетчером сессий (Session Manager).

4.5. Object - принцип данной атаки заключается в том, что не все проактивные защиты корректно обрабатывают поле RootDirectory структуры OBJECT_ATTRIBUTES, благодаря чему становится возможным, к примеру, открыть на чтение/запись системный файл в обход правил проактивной защиты. Таким образом, ликтест осуществляет загрузку злонамеренного драйвера.

4.6. NTVDM - данный ликтест представляет собой реализацию атаки на NTVDM, которая была подробно описана в статье Алекса Ионеску. В результате успешного проведения атаки ликтест снимает активные перехваты системных вызовов, которые используются проактивными защитами для отслеживания различных системных событий, и выполняет загрузку драйвера.

 

При этом полностью исключалась возможность сигнатурного детектирования тестовых утилит со стороны антивирусных компонент тестируемых комплексных продуктов.

Тестирование проводилось в максимально жёстких  условиях, так как это повышает объективность результатов: фаервол, успешно отработавший тесты в жёстких условиях, гарантированно справится с ними и в более мягких условиях.

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

 

Шаги проведения тестирования

  1. Установка операционной системы и ее обновление (создание образа чистой системы);
  2. Установка тестируемой программы на чистую виртуальную машину со стандартными настройками, рекомендованными производителем , обновление модулей и антивирусных баз продукта, принудительная перезагрузка системы;
  3. Проверка успешной установки и работоспособности всех модулей программы;
  4. Создание образа системы с установленным продуктом;
  5. Запуск тестовых утилит и запись результатов их работы (после работы каждой тестовой утилиты производился откат системы к сохраненному образу со стандартными настройками);
  6. Изменения настроек продукта на «максимальные, создание нового образа системы;
  7. Повторный запуск тестовых утилит и запись результатов их работы (после работы каждой тестовой утилиты производился откат системы к сохраненному образу с максимальными настройками).

 

После каждой атаки обязательно проводилась проверка работоспособности функционала тестируемого продукта (его отдельных модулей, активных процессов, сервисов, драйверов).

Если в ходе тестов на завершение/модификацию процессов один из них завершался (т.е. атака на него удавалась), то все остальные процессы подвергались атаке повторно.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.
Если вы являетесь производителем и хотели бы видеть свой продукт в списке протестированных по данной методологии или обновить его результаты, не дожидаясь нового планового теста, вы можете воспользоваться услугой индивидуального тестирования.