Использовать алгоритмы экспертных систем для выявления вредоносных файлов что это

Экспресс-анализ вредоносных файлов в учебных целях

Вместо введения

Искусственные примеры, характерные для многих учебников, часто, к сожалению, отбивают желание разобраться в вопросе. Также плохо, когда первая же учебная задача по изучаемому вопросу настолько сложна, что можно потерять нить рассуждений (при отсутствии опыта, а его, ясно, ещё нет) и вместе с ней — интерес.
Отталкиваясь от вышесказанного и помня, что преподнесение материала — задача и ответственность преподавателя — появилось желание продемонстрировать экспресс-анализ обфусцированных вредоносных скриптов. Благо, достать это «добро» не такая уж большая проблема: целая индустрия исправно трудится на созданием и распространением.
Было получено: внушительная подборка из карантина за предыдущую неделю и скромная подборка скриптов с зараженных сайтов (за 2015 год).
С чего начать? С предварительной подготовки полученного «добра».

Шаг первый (подготовительный)

Удаляем все дубликаты, т.к. нас не интересует количественный показатель. Запомним полученный на данном этапе список, точнее — имена файлов, он нам ещё понадобится.

Шаг второй (сортировочный) или по стопам Менделеева

Шаг третий (анализ) или «метод пристального вглядывания»

Прежде чем переходить к большой группе скриптов рассматриваем единственный файл формата html. Ничем действительно интересным он не порадовал: удаленные символы перевода строки и много комментариев. Это легко вычищается и сразу явно виден прием, который хотели использовать злоумышленники.

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

Деобфускация JS — тема неоднократно раскрыта на Хабре и повторяться особо смысла нет. В коллекции встречались разные приемы.

Интересным и наглядным было более пристальное внимание к группе файлов «3 буквы и 10 цифр». Структура файлов была схожа, если переменным дать одинаковые имена и выполнить ещё некоторые «косметические» преобразования (выровнять отступы, выполнить арифметические операции над числами [чтобы 1+4+1 = 2+2+2 = 3+2+1 = 6]), то схожесть файлов становилась очевидной. Файлы явно были обработаны одним обфускатором. Это продемонстрировало, возможность из потока файлов выявлять группы схожих и, выполнив доскональный анализ отдельных файлов, делать выводы о группах.

Источник

Как обнаружить вредонос: методология SANS

Введение

Когда происходит взлом какой-то системы, зачастую возникает необходимость выяснить, как система была взломана, какие компоненты были скомпрометированы, какая информация была похищена, и кто произвел атаку. Ветвь криминалистики, отвечающая на вопросы такого рода, называется компьютерной криминалистикой или форензикой.

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

Существует множество инструментов для анализа дампов памяти, наиболее популярные из которых – фреймворки volatility и rekall, оба с открытым исходным кодом. Однако самих по себе инструментов может оказаться недостаточно: исследователю полезно иметь алгоритм, который помогал бы действовать эффективно, систематично и не упускать важные детали. Один такой алгоритм под названием SANS Six-Step Investigative Methodology был предложен институтом SANS.

SANS Six-Step Investigative Methodology

Описание методологии SANS Six-Step можно найти на одном из постеров SANS. Алгоритм, как следует из названия, состоит из шести шагов:

Идентификация вредоносных процессов.

Анализ DLL и хэндлов процесса.

Изучение сетевых артефактов.

Поиск свидетельств инъекции кода.

Проверка признаков наличия руткита.

Выгрузка подозрительных процессов и драйверов.

Для пошаговой демонстрации методологии я воспользовался известным образом Jackcr’s Challenge в качестве первого семпла и дампом с Linux-машины, подготовленным моим коллегой, в качестве второго. Среди инструментов, которыми я пользовался, – фреймворк volatility, последнюю версию которого можно найти на GitHub, Wireshark и стандартные Linux-утилиты, такие как strings и grep.

Jackcr’s Challenge

В 2012 специалист по безопасности Джек Крук поделился ссылкой на образ челленджа в своем Твиттере. Сейчас образ доступен по ссылке. Челлендж состоит из дампов памяти с нескольких машин, дампа трафика и текстового файла с вопросами, на которые предлагается ответить. После публикации челлендж стал весьма популярным, в интернете можно найти ряд посвященных ему статей-прохождений, поэтому образ вполне подходит для того, чтобы попрактиковаться с новыми инструментами и методами работы.

Рисунок 1. Содержимое архива по ссылке

Применение методологии к дампу из челленджа

Теперь я продемонстрирую применение каждого шага методологии к дампу из челленджа, снятому на машине ENG-USTXHOU-148.

1. Идентификация вредоносных процессов

Согласно методологии, первый шаг – идентификация вредоносных процессов. Однако, начиная работу с volatility, первым делом нужно выяснить, какой профиль следует использовать с рассматриваемым дампом, иначе volatility не сможет прочитать дамп. Для этого пригодится команда volatility imageinfo: в ее выводе можно найти основную информацию о переданном на вход дампе, в том числе подходящий профиль – в моем случае таковым оказался WinXPSP2x86.

Затем я воспользовался плагином volatility pslist. В списке запущенных процессов, который он вывел на консоль, я заметил несколько подозрительных.

Рисунок 2. Список процессов

Здесь выглядят подозрительными из-за их времени запуска процессы 364, 1796 и 244. Также я взял на заметку процессы 1024 и 284, которые являются родительскими для процессов 364 и 1796 соответственно.

2. Анализ DLL процесса

В состав volatility входит плагин dlllist, предназначенный для получения списка используемых процессом DLL. Запустив dlllist для подозрительных процессов и проверив ряд DLL, я обнаружил 6to4ex.dll, используемый процессом svchost.exe с PID 1024, который был помечен большинством движков VirusTotal как вредоносный. Запустив strings на этой DLL, я заметил вхождения строки “gh0st” – это название известного трояна.

Рисунок 3. Название известного трояна Gh0st фигурирует в DLL

3. Анализ сетевых артефактов

Третий шаг состоял из изучения дампа трафика в Wireshark и запуска плагина volatility connscan, который показывает артефакты подключений, в том числе недавно закрытых. Это дало мне адрес C2, запуск grep по которому показал также, каким образом было доставлено вредоносное ПО: злоумышленники отправили нескольким пользователям фишинговые письма с требованием установить новый антивирус и ссылкой на дроппер под названием Symantec-1.43-1.exe.

Рисунок 4. Вредоносное ПО было доставлено с помощью фишинговых писем

4. Поиск свидетельств инъекции кода

Поиск свидетельств возможного внедрения кода можно осуществить с помощью malfind – ещё одного плагина volatility, разработанного специально для этих целей. В моем случае ничего найдено не было. Это связано с тем, что malfind не способен обнаруживать инъекции DLL (разработчики подчеркивают это в документации).

Рисунок 5. Malfind не находит свидетельств инъекции кода для PID 1024

5. Проверка признаков наличия руткита

Руткиты часто перехватывают вызовы System Service Descriptor Table (SSDT), поэтому проверка на владельцев функций SSDT – один из способов обнаружить руткит в системе. В составе volatility есть плагин, перечисляющий функции SSDT и их владельцев, который так и называется – ssdt. Запуск ssdt, однако, не показал ничего. Надо полагать, это связано с тем, что Gh0st, обнаруженный на исследуемой системе, согласно исследованию InfoSec способен зачищать существующие перехваты SSDT.

6. Выгрузка подозрительных процессов и драйверов

Плагин volatility procdump позволяет выгружать исполняемый файл по переданному на вход номеру процесса. Именно так я и поступил с процессами 1024 и 1796.

Применение методологии к дампу с Linux-машины

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

1. Идентификация вредоносных процессов

При работе с помощью volatility над Linux-дампом следует использовать профиль, созданный на той же машине, на которой был снят дамп. Поэтому на сей раз я не запускал плагин imageinfo, чтобы определить необходимый профиль. Вместо этого я просто использовал профиль, переданный мне вместе с образом.

Итак, вооружившись этим профилем, я воспользовался плагином linux_pslist, чтобы просмотреть список процессов и выделить подозрительные.

Рисунок 6. Список процессов (фрагмент)

Обнаружить подозрительный процесс было нетрудно: wallet.elf не только единственный процесс с расширением .elf у исполняемого файла, но еще и родитель для процесса sh, который в свою очередь является родителем vim. Не самая обычная цепочка.

2. Анализ DLL процесса

Несмотря на то, что термин DLL применим только к Windows, этот шаг легко остается актуальным для Linux-дампа, так как исполняемые файлы под Linux также используют динамические библиотеки, называемые обычно shared libraries. Единственное отличие состоит в том, что если для Windows-дампа я использовал плагин dlllist, то для Linux-дампа я использовал плагин linux_library_list, аналогичным образом выводящий список библиотек для процесса. В случае процесса 1353 список библиотек, однако, оказался пустым.

Рисунок 7. Volatility не показывает список библиотек подозрительного процесса

3. Анализ сетевых артефактов

На этот раз у меня не было дампа трафика, поэтому на этапе анализа сетевых артефактов мне оставалось только изучить список подключений с помощью плагина volatility linux_netscan, который выводит список открытых сокетов. Его вывод снова направил внимание в сторону процесса 1353, а также дал потенциальный адрес C2.

Рисунок 8. Вывод linux_netstat (фрагмент)

Более того, запустив strings на дампе и отфильтровав результат по потенциальному адресу C2, я заметил фрагмент bash-скрипта.

Рисунок 9. Скрипт в выводе strings

Была там и строчка, дающая возможность понять, как файл wallet.elf попал в систему.

Рисунок 10. Подозрительный исполняемый файл был загружен скриптом

4. Поиск свидетельств инъекции кода

Как и в случае Windows, в составе volatility есть плагин для поиска возможной инъекции кода. Его Linux-версия называется linux_malfind. Запустив его, я получил несколько положительных сработок для процесса 1353, однако я уже знал, что запущенный в этом процессе исполняемый файл был загружен извне подозрительным скриптом, так что это было не очень полезно.

Рисунок 11. Malfind нашел признаки инъекции кода в процессе 1353

5. Проверка признаков наличия руткита

В составе volatility есть несколько инструментов для обнаружения руткитов в случае Linux:

linux_check_fop проверяет на наличие модификаций структуры file_operation;

linux_check_idt проверяет, были ли изменены IDT;

linux_check_modules сравнивает список модулей с данными sysfs;

linux_hidden_modules пытается обнаружить скрытые модули ядра;

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

6. Выгрузка подозрительных процессов и драйверов

Работая над Windows-дампом, я использовал плагин volatility procdump, чтобы выгрузить исполняемый файл подозрительного процесса. В volatility есть аналогичный плагин и для Linux-дампов – он называется linux_procdump. С помощью этого плагина я выгрузил исполняемый файл процесса 1353 для дальнейшего анализа.

Заключение

В этой статье я проиллюстрировал применение методологии SANS для анализа Windows-дампа, а затем и для анализа Linux-дампа, чтобы показать, что, за исключением небольших адаптаций алгоритм в обоих случаях остается неизменным.

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

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

Источник

Технологии обнаружения вредоносного кода. Эволюция

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

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

1. Введение

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

Несмотря на то что название данной статьи апеллирует ко всему спектру технологий детектирования вредоносного кода, речь в ней пойдет преимущественно о несигнатурных технологиях — о сигнатурных сказать уже практически нечего ввиду их примитивности и однозначности. В то же время пользователи плохо ориентируются в несигнатурных технологиях. Что скрывается под названиями «эвристика», «проактивное детектирование», «поведенческое детектирование», «HIPS», как перечисленные технологии соотносятся друг с другом, каковы преимущества и недостатки каждой из них? Разобраться в этом — задача нашей статьи. Помимо прочего, данная статья, так же как и предыдущая — «Эволюция самозащиты вредоносных программ», имеет целью систематизировать и максимально объективно рассмотреть некоторые частные проблемы из области вредоносных программ и защиты от них. Статьи этого цикла рассчитаны на читателей, имеющих общее представление об антивирусных технологиях, но не являющихся специалистами в области защиты от вредоносных программ.

2.Модель системы защиты от вредоносных программ

Для начала рассмотрим, как работают технологии поиска вредоносного кода. Для этого я предлагаю использовать следующую модель.

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

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

Аналитический компонент — это система принятия решения. Это алгоритм, который анализирует имеющиеся в его распоряжении данные и выносит о них некое суждение. В соответствии с этим суждением антивирус (либо другое защитное ПО) предпринимает установленные его политикой безопасности действия: оповещает пользователя, запрашивает у него дальнейшие указания, помещает файл в карантин, блокирует несанкционированное действие программы и т.д.

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

В рамках описанной модели любая система защиты может быть представлена как «комплексное число» — как связка двух независимых объектов: технического и аналитического компонентов определенного типа. Анализируя технологии таким образом, легко увидеть их соотношение, их принципиальные плюсы и минусы. И, в частности, с помощью этой модели удобно разрешить путаницу в определениях технологий. Например, ниже будет показано, что «эвристика» как способ принятия решений — лишь разновидность аналитического компонента, а не самостоятельная технология. А HIPS (Host Intrusion Prevention System) — лишь разновидность технического компонента, способ сбора данных. Как следствие, данные термины, во-первых, формально не противоречат друг другу, а во-вторых, не полностью характеризуют технологию, в описании которой встречаются: говоря об эвристике, мы не уточняем, по каким именно данным производится эвристический анализ, а говоря о HIPS-системе — ничего не знаем о том, по какому принципу в ней выносится вердикт.

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

Диаграмма. Суммарная схема технологий обнаружения вредоносного кода

2.1 Технический компонент

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

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

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

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

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

Рассмотрим эти способы подробно.

2.1.1 Считывание файлов

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

Характерная особенность этого способа в том, что антивирус работает только с исходным байтовым кодом программы, не затрагивая ее поведение. Несмотря на то, что способ «архаический», он совершенно не устарел и так или иначе используется во всех современных антивирусах — но уже не как единственный и даже не как основной, а лишь как один из нескольких.

2.1.2 Эмуляция

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

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

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

2.1.3 Виртуализация: «песочница»

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

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

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

Таким образом, средство защиты, основанное на виртуализации описанного типа, работает уже не с файлом, но с поведением программы — однако все еще не с системой.

Механизм типа «песочница», так же как и эмулятор, не особенно активно используется в антивирусах — главным образом потому, что в программной реализации он требует значительного объема ресурсов. Антивирусы, имеющие в своем составе «песочницу», легко идентифицируются по существенной временной задержке между запуском программы и началом ее исполнения (либо — в случае успешной идентификации вредоносной программы — между ее запуском и уведомлением, полученным от антивируса, об ее успешном детектировании). Учитывая, что в настоящий момент проводятся активные исследования в области аппаратной виртуализации, ситуация вскоре может поменяться.

Пока что движок типа «песочница» используется лишь в нескольких антивирусах.

2.1.4 Мониторинг системных событий

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

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

Этот технологический принцип наиболее активно развивается в настоящее время. Он используется в качестве одного из компонентов в нескольких крупных антивирусах, и в качестве основы — в отдельных утилитах, специализирующихся на мониторинге системы (их называют «HIPS-утилитами», «HIPS’ами» — это Prevx, CyberHawk и ряд других). Однако в свете того, что любую защиту можно обойти, данный способ поиска вредоносных программ представляется не самым перспективным, поскольку при запуске программы в реальной среде риск существенно снижает эффективность защиты.

2.1.5 Поиск системных аномалий

Это наиболее абстрактный способ сбора информации о предположительно зараженной системе. Я упоминаю его здесь в первую очередь как логическое продолжение и предел абстракции в приведенном списке технологий.

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

Исходя из этих положений мы можем судить о состоянии системы (и, следовательно, о возможном присутствии в ней вредоносных программ), сравнивая его с эталоном (за эталон принимается «здоровое» состояние системы) или анализируя совокупность отдельных ее параметров.

Для эффективного обнаружения вредоносного кода методом анализа аномалий необходима достаточно сложная аналитическая система — наподобие экспертной системы или нейронной сети. Возникает много вопросов: как определить «здоровое состояние», чем оно отличается от «нездорового», какие дискретные параметры можно отслеживать и как их анализировать? По причине такой сложности в настоящее время этот способ разработан мало. Зачатки его можно обнаружить в некоторых антируткит-утилитах, где он реализован на уровне сравнения с определенным срезом системы, взятым за эталон (устаревшие утилиты PatchFinder, Kaspersky Inspector), либо отдельных ее параметров (GMER, Rootkit Unhooker).

2.1.6 Забавная метафора

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

Технологии растут и развиваются.

2.2 Аналитический компонент

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

2.2.1 Простое сравнение

Вердикт выносится по результатам сравнения единственного объекта с имеющимся образцом. Результат сравнения бинарный («да» или «нет»). Пример: идентификация вредоносного кода по строго определенной последовательности байт. Другой пример, более высокоуровневый: идентификация подозрительного поведения программы по единственному совершенному ею действию (такому как запись в критичный раздел реестра или в папку автозагрузки).

2.2.2 Сложное сравнение

Вердикт выносится по результатам сравнения одного или нескольких объектов с соответствующими образцами. Шаблоны для сравнения могут быть гибкими, а результат сравнения — вероятностным. Пример: идентификация вредоносного кода по одной из нескольких байтовых сигнатур, каждая из которых задана нежестко (например, так, что отдельные байты не определены). Другой пример, более высокоуровневый: идентификация вредоносного кода по нескольким используемым им и вызываемым непоследовательно API-функциям с определенными параметрами.

2.2.3 Экспертная система

Вердикт выносится в результате тонкого анализа данных. Это может быть система, содержащая в себе зачатки искусственного интеллекта. Пример: идентификация вредоносного кода не по жестко заданному набору параметров, но по результатам многосторонней оценки всей совокупности параметров в целом, с присвоением каждому из событий веса «потенциальной вредоносности» и расчетом общего результата.

3. Реальные названия технологий — что к чему

Рассмотрим теперь, какие именно алгоритмы лежат в основе конкретных технологий поиска вредоносных программ.

Обычно производитель, разработав новую технологию, дает ей совершенно новое, уникальное имя (примеры: «Проактивная защита» в Kaspersky Antivirus, TruPrevent от Panda, DeepGuard от F-Secure). Это очень правильный подход, поскольку он позволяет избежать автоматического восприятия технологии в узких рамках некого термина-штампа. Тем не менее, использование штампов — таких как «эвристика», «эмуляция», «песочница», «поведенческий блокиратор» — неизбежно при любых попытках доступно и не вдаваясь в технические подробности охарактеризовать технологию.

Тут-то и начинается терминологическая путаница. За терминами жестко не закреплены значения (а в идеале термин должен быть однозначен, на тот он и термин). Один человек так понимает этот термин, другой — иначе. Вдобавок, значения, которые вкладывают в термины авторы так называемых «доступных описаний», часто очень существенно отличаются от значений, принятых в среде профессионалов. Иначе чем объяснить тот факт, что описание технологии на сайте производителя может изобиловать терминами, но при этом ничего не сообщать о сути технологии или сообщать нечто, не соответствующее ей.

Например, некоторые производители антивирусных систем характеризуют свои продукты как оснащенные HIPS, «проактивной технологией» или «несигнатурной технологией». Пользователь, который понимает термин HIPS как мониторинг системных событий и их анализ на наличие вредоносного кода, может оказаться обманутым. В действительности под этими характеристиками может скрываться все что угодно — например, движок типа «эмулятор», оснащенный аналитической системой типа «эвристика» (определение см. ниже). Еще чаще встречается ситуация, когда защита характеризуется как «эвристическая» без каких-либо уточнений.

Подчеркнем, что речь не идет об умышленном обмане пользователя производителем — вероятнее всего, составитель описания просто сам запутался в терминах. Речь идет лишь о том, что описание технологии, составленное для конечного пользователя, может не отражать ее суть, и что опираться на него при ответственном подходе к выбору защиты следует с осторожностью.

Рассмотрим наиболее распространенные термины в области антивирусных технологий (см. диаграмму).

Меньше всего разночтений у термина «сигнатурное детектирование»: так или иначе, с технической стороны оно подразумевает работу с байтовым кодом файлов, а с аналитической — примитивный способ обработки данных, обычно — простое сравнение. Это самая старая технология, но она же и наиболее надежная — поэтому, несмотря на большие производственные издержки, связанные с пополнением базы, активно используется по сей день во всех антивирусах.

Если в характеристике используется название технического компонента из приведенного выше списка — «эмулятор» или «песочница» — это также вызывает минимум толкований. При этом аналитический компонент такой технологии может быть представлен алгоритмом любой степени сложности, от простого сравнения до экспертной системы.

Термин «эвристика» уже немного туманен. По определению словаря Ожегова-Шведовой, «эвристика — совокупность исследовательских методов, способствующих обнаружению ранее неизвестного». Эвристика — это в первую очередь тип аналитического компонента защиты, а не определенная технология. Вне конкретной темы, в контексте решения задач, он приблизительно соответствует «нечеткому» способу решения нечетко поставленной задачи.

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

Еще меньше определенности с такими названиями, как «поведенческое детектирование», «проактивное детектирование». Они могут подразумевать широкий спектр технологий — от эвристики до мониторинга системных событий.

Термин HIPS используется в описаниях антивирусных технологий очень часто, и не всегда оправданно. Несмотря на то что расшифровка аббревиатуры (Host Intrusion Prevention System) никак не отражает суть технологии, применительно к антивирусной защите технология четко определена: HIPS — это защита, технически основанная на мониторинге системных событий. При этом аналитический компонент защиты может быть каким угодно — от пресечения единичных подозрительных событий до сложного анализа цепочек программных действий. Таким образом, под определением «HIPS» в описании антивируса может скрываться, например, примитивная защита нескольких ключей реестра, либо система уведомлений о попытках доступа к определенным директориям, либо более сложная система анализа поведения программ, либо какая-то другая технология, в основе которой лежит мониторинг системных событий.

4. Плюсы и минусы способов обнаружения вредоносного кода

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

Технический компонент технологии отвечает в основном за такие ее характеристики, как нагрузка на систему (и как следствие — ее быстродействие), безопасность и защищенность.

Нагрузка на систему — это доля процессорного времени и оперативной памяти, непрерывно или периодически задействованных в обеспечении защиты и ограничивающих быстродействие системы. Эмуляция выполняется медленно, вне зависимости от реализации: на каждую проэмулированную инструкцию приходится несколько инструкций искусственной среды. То же можно сказать и про виртуализацию. Мониторинг системных событий также безусловно равномерно тормозит всю систему, но степень этой нагрузки зависит от реализации. В случае с файловым детектированием и поиском системных аномалий степень нагрузки всецело зависит от реализации.

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

Подводя итог: в среднем, чем менее абстрактна защита, тем она безопаснее, но и тем проще ее обойти.

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

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

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

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

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

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

5. Как выбрать систему несигнатурной защиты?

В настоящий момент большинство решений в области компьютерной безопасности реализуются как комплекс нескольких технологий. В классических антивирусах сигнатурное детектирование обычно используется в связке с той или иной реализацией мониторинга системных событий, эмулятора, песочницы. Как сориентироваться в спецификациях и выбрать систему защиты от вредоносного кода, оптимально отвечающую потребностям конкретного пользователя?

Прежде всего, следует помнить, что не существует ни универсального, ни «самого лучшего» решения. У каждой технологии есть свои плюсы и минусы. Например, мониторинг событий в системе постоянно занимает процессорное время, но его труднее всего обмануть; процессу эмуляции можно помешать использованием в коде определенных команд, зато при ее использовании обнаружение вредоносного кода выполняется в упреждающем режиме, система остается незатронута. Другой пример: простые правила принятия решений требуют от пользователя слишком активного участия в процессе, порождая много вопросов к пользователю, а сложные и «тихие» чреваты ложными срабатываниями. Выбор технологии — это выбор золотой середины с учетом конкретных потребностей и обстоятельств.

Например, тому, кто работает в уязвимых условиях («непропатченная» система, отсутствие запретов на использование расширений браузера, скриптов и т.п.), сильно беспокоится за свою безопасность и имеет достаточно ресурсов, больше всего подойдет система типа «песочница», с качественным аналитическим компонентом. Такая система обеспечивает максимум безопасности, но в сегодняшней реализации задействует много оперативной памяти и процессорного времени — что может проявляться в «торможении» ОС. Специалисту, желающему контролировать критичные системные события, и заодно оградить себя от неизвестных вредоносных программ, подойдет система мониторинга реального времени. Такая система равномерно, но не существенно загружает операционную систему и требует специального участия в создании правил и исключений. А пользователю, который ограничен в ресурсах либо не хочет загружать свою машину постоянным мониторингом, а разум — созданием правил, подойдет более простая эвристика. В конце концов, за качество детектирования неизвестных вредоносных программ отвечает не какая-то одна составляющая защитной системы, а вся система в целом; более простой технологический способ можно компенсировать более умелым принятием решений.

Системы несигнатурного обнаружения ранее неизвестного кода распадаются на две категории. Первая — это самостоятельные HIPS-системы, такие как уже приведенные в качестве примера Prevx или Cyberhawk. Вторая — крупные антивирусы, эволюционировавшие в поиске большей эффективности до несигнатурных технологий. Преимущества той или иной категории очевидны: узкая специализация, в рамках которой можно неограниченно совершенствовать качество, — в первом случае, и значительный опыт разносторонней борьбы с вредоносными программами — во втором.

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

1 Эмуляция — имитация работы одной системы средствами другой без потери функциональных возможностей и искажений результатов. Эмуляция выполняется программными и/или аппаратными средствами.

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

3 Приемы против эмуляции основаны на том, что на некоторые команды эмулятор реагирует иначе, чем процессор. Это позволяет вредоносной программе детектировать эмуляцию и совершать определенные действия — например, завершиться или выполняться по альтернативному алгоритму.

Автор: Алиса Шевченко

Ведущий эксперт “Лаборатории Касперского”

Источник