Криптографический хеш наподобие MD5 позволяет распознать только конкретный файл, поскольку предназначен для его однозначного обозначения. Более гибкие сигнатуры, например контрольная сумма CRC отдельных участков данных вместо хеширования всего файла, способны выявлять несколько разных файлов.

Как описано в главе 8, продукты обычно используют несколько видов сигнатур. Они варьируются от простых контрольных сумм CRC до сложных эвристических признаков, основанных на многочисленных полях заголовка PE, сложности кода в точке входа исполняемого файла, энтропии всего файла либо отдельного раздела или сегмента. Иногда сигнатуры строятся по базовым блокам, обнаруженным при анализе кода от точки входа проверяемого исполняемого файла.

У каждого вида сигнатур есть достоинства и недостатки. Одни очень точны и редко приводят к ложному срабатыванию, когда безопасный файл объявляется вредоносным. Другие рискованны и способны породить множество ложных срабатываний. Представьте сигнатуру, которая ищет слово Microsoft в любом файле, начинающемся с байтов MZ\x90. Независимо от того, была ли такая последовательность найдена во вредоносной программе, правило вызовет огромное число ложных срабатываний. Сигнатуры необходимо создавать с большой осторожностью, чтобы избежать как ложных срабатываний, подобных показанному на рисунке 1.1, так и пропусков, при которых настоящий вредоносный код признается безопасным.

Рисунок 1.1. Ложное срабатывание Comodo Internet Security при проверке фактически стандартного средства обратной разработки IDA

Средства сжатия и архивы

Еще одна важная часть любого антивирусного ядра - поддержка сжатых файлов и архивов, в том числе ZIP, TGZ, 7z, XAR и RAR. Антивирус должен уметь распаковывать такие файлы и обходить все содержащиеся в них объекты, а также сжатые потоки в PDF и других форматах. Поскольку ядру приходится поддерживать множество форматов, в обрабатывающем их коде часто находят уязвимости.

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

Распаковщики

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

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

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

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

Эмуляторы

Почти все представленные на рынке антивирусные ядра, кроме ClamAV, содержат несколько эмуляторов. Чаще всего встречается эмулятор Intel x86. В некоторых сложных продуктах поддерживаются также эмуляторы AMD64 или ARM.

Эмуляция не ограничивается обычными архитектурами центральных процессоров. Существуют эмуляторы виртуальных машин, предназначенные для анализа байт-кода Java и Android DEX, JavaScript, VBScript и даже Adobe ActionScript.

Выявить признаки эмулятора или виртуальной машины антивируса и обойти их нетрудно: достаточно найти несоответствия в реализации. Например, разработчики эмулятора Intel x86 едва ли смогут воспроизвести все команды поддерживаемых процессоров в точности так же, как их изготовители. Еще менее вероятно, что в высокоуровневой среде исполнения файлов ELF или PE будет полностью воспроизведена операционная система и весь предоставляемый ею прикладной программный интерфейс. Поэтому найти множество способов распознавания и обмана эмулятора относительно легко. В книге рассматриваются как способы обхода антивирусных эмуляторов, так и методы их распознавания. Часть III посвящена созданию средств эксплуатации уязвимостей для конкретного антивирусного ядра.

Прочие форматы файлов

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

Помимо средств сжатия и архивов, приходится поддерживать контейнеры OLE2, в том числе документы Word и Excel; страницы HTML, документы XML и PDF; справочные файлы CHM и старые форматы справки Microsoft; исполняемые файлы PE, ELF и Mach-O; изображения JPG, PNG, GIF, TGA и TIFF; значки ICO и CUR; звуковые и видеофайлы MP3, MP4, AVI, ASF и MOV и многое другое.

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

Расширенные возможности

Далее рассматриваются некоторые наиболее распространенные расширенные возможности антивирусных продуктов.

Фильтры пакетов и межсетевые экраны

С конца 1990-х примерно до 2010 года часто появлялись сетевые черви - вредоносные программы, использовавшие одну или несколько удаленных уязвимостей в выбранных продуктах. Иногда они заражали общие сетевые ресурсы Windows CIFS еще проще: перебирали стандартные сочетания имени пользователя и пароля, а затем копировали себя под привлекательными именами. Среди известных примеров - I Love You, Conficker, Melissa, Nimda, Slammer и Code Red.

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

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

Самозащита

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

Многие антивирусы реализуют самозащиту в драйверах ядра, блокируя распространенные операции завершения, например вызов ZwTerminateProcess. Другие способы основаны на запрете вызовов OpenProcess с определенными параметрами для антивирусных процессов либо на блокировании WriteProcessMemory, которое применяется для внедрения кода в чужой процесс.

Обычно эти меры реализуются драйверами ядра, хотя защиту можно разместить и в пользовательском пространстве. Однако опора на код пользовательского пространства - заведомо несостоятельная модель, не работающая по меньшей мере с 2000 года. Несмотря на это, многие продукты по-прежнему допускают такую ошибку. Примеры рассматриваются в части III.

Противодействие эксплуатации уязвимостей

Современные операционные системы Windows, Mac OS X и Linux предоставляют средства противодействия эксплуатации уязвимостей, также называемые механизмами снижения ущерба. К ним относятся рандомизация размещения адресного пространства ASLR и предотвращение исполнения данных DEP. Однако появились они сравнительно недавно, поэтому некоторые антивирусные комплексы предлагают или прежде предлагали собственные средства.

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

К сожалению, как это часто бывает с антивирусным программным обеспечением, большинство отраслевых средств реализовано в пользовательском пространстве посредством перехвата функций. Один из примеров - комплект Malwarebytes. После появления комплекта Microsoft EMET многие антивирусные решения оказались либо менее полными, либо устаревшими, вследствие чего их легко обойти.

В некоторых случаях применение антивирусного средства против эксплуатации уязвимостей даже хуже полного отсутствия такого средства. Примером служит Sophos BOPS - собственная реализация ASLR. Исследователь Google Тэвис Орманди обнаружил, что Sophos устанавливала общесистемную динамическую библиотеку DLL, для которой ASLR не была включена. Эту библиотеку внедряли в процессы, чтобы имитировать ASLR в операционных системах без ее поддержки, например Windows XP.

Ирония заключалась в том, что сама общесистемная библиотека была скомпилирована без поддержки ASLR. Поэтому в системах, где ASLR имелась, например Windows Vista, защита фактически ослаблялась из-за этой библиотеки. Другие недостатки подобных комплектов в антивирусном программном обеспечении рассматриваются в части IV.

Итоги

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

Подведем итоги:

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

• Существуют различные виды вредоносного кода: троянские программы, вирусы, руткиты, сетевые черви, загрузчики, средства эксплуатации уязвимостей, код командной оболочки и другие.

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

• Государства также создают вредоносные программы для слежения и саботажа, защищая собственные интересы. Власти Бахрейна применяли FinFisher для слежения за повстанцами, а Stuxnet, предположительно совместно созданный правительствами США и Израиля, предназначался для нарушения иранской ядерной программы.

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

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

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

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

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

Например, для отключения механизма самозащиты, который в китайском продукте Qihoo 360 называется защитой от хакеров, измените параметр Start драйвера 360AntiHacker (360AntiHacker.sys) на 4, как показано на рисунке 2.5. В комплекте разработки Windows этому значению соответствует константа SERVICE_DISABLED: служба отключается и больше не загружается Windows. После изменения может потребоваться перезагрузка.

*Рисунок 2.5. Отключение драйвера 360AntiHacker*

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

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

Отладка ядра

Отладчик ядра позволяет исследовать как антивирусные драйверы, так и процессы пользовательского режима. Это наименее трудный способ присоединиться к процессу антивируса и обойти противоотладочные приемы пользовательского режима. Вместо отключения драйверов самозащиты отлаживается вся операционная система, а при необходимости отладчик присоединяется к нужному пользовательскому процессу. Понадобится WinDbg или Kd из комплекта Debugging Tools for Windows либо WDK.

Рисунок 2.6. Отладчик WinDbg

Для отладки ядра создайте виртуальную машину в VMware или VirtualBox. В примерах используется свободно распространяемый VirtualBox.

После установки Windows 7 или более новой версии настройте параметры загрузки, разрешив отладку ядра. В Windows XP и Windows 2000 для этого редактировали C:\boot.ini. Начиная с Windows Vista применяется bcdedit. Откройте командную строку cmd.exe с правами администратора и выполните две команды:

Первая команда включает отладку ядра текущей операционной системы. Вторая задает связь через последовательный порт COM1 со скоростью 115 200 бод, как показано на рисунке 2.7.

*Рисунок 2.7. Настройка отладки ядра Windows 7 с помощью bcdedit*

После успешной настройки выключите виртуальную машину и измените параметры VirtualBox:

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

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

3. Разрешите создание канала и укажите путь \\.\pipe\com_1, как на рисунке 2.8.

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

Рисунок 2.8. Настройка отладки в VirtualBox

Примечание. Здесь предполагается, что VirtualBox работает на узле Windows. Настройка отладки ядра гостевой Windows на узле Linux или Mac OS X значительно сложнее, требует как минимум двух виртуальных машин и сильно зависит от версии основной операционной системы. Ее можно выполнить как в VMware, так и в VirtualBox, но по возможности рекомендуется использовать узел Windows.

Отладка пользовательских процессов отладчиком ядра

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

1. Запустите WinDbg с повышенными правами и выберите в главном меню команду отладки ядра.

2. На вкладке COM укажите ранее заданный порт или файл и включите использование канала.

3. Задайте путь к открытому серверу символов Microsoft и потребуйте перезагрузить символы:

Теперь WinDbg сможет использовать открытые символы. В качестве примера исследуем 32-разрядную пользовательскую службу F-Secure Scanner Manager fssm32.exe. Из режима ядра необходимо перечислить процессы исследуемого узла, найти нужный, переключить контекст исполнения и начать отладку.

Все пользовательские процессы перечисляет команда:

Имя в конце команды отфильтровывает результаты:

Значение 868c07a0 указывает на структуру EPROCESS. Передайте ее адрес следующей команде:

Ключи /r /p обеспечивают автоматическое переключение между контекстами ядра и пользователя, после чего можно отлаживать fssm32.exe:

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

Теперь пользовательский процесс можно исследовать из режима ядра. Другие приемы работы с WinDbg описаны в главе 4 книги Practical Reverse Engineering Дага, Газе, Башаалани и Жосса, выпущенной Wiley в 2014 году, ISBN 978-1-118-78731-1.

Анализ антивируса средствами командной строки

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

В этом случае проверьте версии для Linux, BSD и Mac OS X: велика вероятность, что в них есть независимый самодостаточный сканер командной строки. Так обстоит дело с Avira, Bitdefender, Comodo, F-Secure, Sophos и многими другими продуктами.

Средство командной строки не обязательно отлаживать вручную в WinDbg, IDA, OllyDbg или GDB. Фаззеры можно создавать через программные интерфейсы отладки: привязки LLDB, отладчик Vtrace компании Kenshoto либо интерфейсы Python PyDbg и WinAppDbg.

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

Перенос ядра

В этом разделе выбираются платформа и средства автоматизации. Правильный выбор операционной системы и компонента антивируса задает верное направление для обратной разработки и дальнейшей автоматизации.

Для обычной автоматизации и фаззинга лучше всего подходят системы семейства Unix, прежде всего Linux: они требуют меньше памяти и дискового пространства и предлагают множество вспомогательных средств. Набор виртуальных машин Linux проще запускать в QEMU, KVM, VirtualBox или VMware, чем такой же набор Windows. Поэтому автоматический фаззинг антивирусов рекомендуется проводить в Linux.

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

Wine широко известен как среда запуска исполняемых файлов Windows в других операционных системах, например Linux. Вспомогательная библиотека Winelib позволяет переносить приложения Windows в Linux. С ее помощью были успешно перенесены программа просмотра и упорядочивания фотографий Picasa компании Google, компилятор и среда разработки Kylix компании Borland, WordPerfect 9 for Linux компании Corel и WebSphere компании IBM.

Иными словами, средство командной строки только для Windows можно запустить посредством Wine. Другой вариант - исследовать библиотеки ядра и написать на C или C++ оболочку Winelib для Linux, вызывающую экспортированные функции библиотеки DLL Windows.

Оба способа успешно применяются, например, со средством Ikarus t3 Scan, работающим только в Windows, и библиотекой mpengine.dll продукта Microsoft Security Essentials. Этот вариант рекомендуется, когда другого способа автоматизировать работу выбранного антивируса в Linux нет, поскольку автоматизация в Windows слишком сложна или требует чрезмерных ресурсов.

*Рисунок 2.9. Ikarus t3 Scan, запущенный в Linux посредством Wine*

Практический пример: основные привязки Python для Avast в Linux

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

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

Краткое знакомство с Avast для Linux

В Avast для Linux есть только два исполняемых файла: avast и scan. Первый является серверным процессом, который распаковывает файл вирусной базы VPS, запускает проверки, обрабатывает запросы адресов и выполняет другие действия. Второй представляет собой клиент для передачи этих запросов. Поставляемые исполняемые файлы содержат часть символов. На рисунке 2.10 показано клиентское средство scan.

*Рисунок 2.10. Список функций и дизассемблированный код функции scan_path в средстве Avast scan*

Благодаря частичным символам назначение программы легко определить в IDA. Начнем с функции main:

По адресу 0x08048935 находится указатель на строку C /var/run/avast/scan.sock, загружаемый в регистр ESI. Позднее вызывается функция getopt со строкой hvVfpabs:e:. Она описывает поддерживаемые средством scan аргументы. Предыдущий путь обозначает сокет Unix, к которому должен подключиться клиент. Это подтверждает код по адресу 0x08048B01:

Указатель на путь к сокету копируется функцией strcpy в переменную стека socket_copy, после чего открывается сокет домена Unix. Затем функция connect соединяет его с scan.sock:

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

Простые привязки Python для Avast в Linux

Сначала проверим сделанный вывод, подключившись к сокету из интерактивной оболочки Python:

Соединение установлено. Теперь нужно определить, что клиент отправляет серверу и какие ответы получает. Сразу после connect вызывается функция parse_response, от которой ожидается магическое значение 220:

После соединения прочитаем из сокета 1024 байта:

Тайна раскрыта: код ответа 220 поступает непосредственно от сервера. Привязка должна извлечь число из приветствия фоновой службы Avast и проверить, что оно равно 220, то есть соединение исправно.

Далее в main вызывается функция av_close:

Завершив работу, клиент вызывает av_close. Функция передает фоновой службе строку QUIT\n, сообщая, что соединение можно закрыть.

Создадим минимальный класс, который соединяется со службой Avast и правильно разрывает соединение. Первая реализация в файле basic_avast_client1.py выглядит так:

Запустим сценарий:

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

По адресу 0x08048D3B встречается интересный вызов:

Благодаря частичным символам назначение scan_path очевидно: функция проверяет путь. Рассмотрим ее начало:

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

Добавим отправку команды проверки и выведем ответ:

Первый запуск дает такой результат:

Полезных данных пока нет. Ответ 210 SCAN DATA\r\n сообщает, что вслед за ним придут другие пакеты с результатом. Читать сокет необходимо до пакета вида 200 SCAN OK\n. Применим простой, хотя и не самый изящный способ:

Повторный запуск выводит ожидаемые данные:

Сервер Avast распознал файл 00908235ee9e267fa2f4c83fb4304c63af976cbc как вредоносную программу Win32:Hoblig. Теперь у нас есть рабочие основные привязки Python, способные проверять файлы и каталоги и получать результат. На основе протокола код можно приспособить для фаззинга.

Стоит проверить, используется ли тот же протокол в Avast для Windows, и при возможности перенести привязки. В противном случае фаззинг можно продолжить в Linux: присоединить GDB или другой отладчик к службе /bin/avast, подавать ей искаженные входные файлы и ожидать аварийного завершения.

Ядро в Windows и Linux одинаково, хотя, по словам разработчиков Avast, версия ядра для Linux не всегда является самой новой. Поэтому сбой в Linux с большой вероятностью воспроизводится в Windows. Именно таким способом в обработчике файлов RPM версии для Linux была найдена уязвимость, затрагивавшая все поддерживаемые Avast платформы.

Окончательная версия привязок Python

Окончательная версия привязок доступна в проекте pyavast на GitHub. Она охватывает почти все возможности протокола, известные на апрель 2014 года.

Практический пример: машинные средства C/C++ для Comodo Antivirus в Linux

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

В этом примере создается неофициальный комплект разработки C/C++ для Comodo Antivirus в Linux. К счастью, продукт содержит полный набор символов, поэтому найти интерфейсы и структуры сравнительно легко.

Начнем со сканера командной строки Comodo для Linux под названием cmdscan, установленного по адресу:

Откройте файл в IDA, дождитесь завершения первоначального автоматического анализа и перейдите к функции main:

Стандартная функция getopt проверяет параметры s:vh. Запуск /opt/COMODO/cmdscan без аргументов выводит справку:

Обнаруженные в дизассемблированном коде параметры документированы. Нас интересует ключ -s, предписывающий проверить файл или каталог:

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

Проверяется, задан ли путь src. При его отсутствии программа переходит к справке и завершается. Иначе вызываются open_dev_avflt, load_framework и maybe_IFrameWork_CreateInstance. Устройство dev/avflt для сканирования фактически не требуется, поэтому первую функцию можно пропустить. Перейдем сразу к load_framework, загружающей ядро Comodo. Ее полный псевдокод:

Получился почти готовый код, который можно скопировать из окна псевдокода в исходный файл C/C++. Он выполняет следующее:

• определяет собственный путь, прочитав созданную ядром Linux символическую ссылку /proc/self/exe, и делает этот каталог текущим;

• динамически загружает libFRAMEWORK.so, находит функцию CreateInstance и сохраняет указатель в глобальной переменной FnCreateInstance;

• функция CreateInstance загружает находящееся в libFRAMEWORK.so ядро и находит основную функцию, создающую новый экземпляр каркаса.

Теперь исследуем maybe_IFrameWork_CreateInstance:

Ранее найденная FnCreateInstance получает адрес локальной переменной hInstance и создает экземпляр интерфейса Comodo Antivirus. Затем исполняется код:

Каркас инициализируется вызовом hFramework->baseclass_0->CFrameWork_Init. В функцию передаются только что созданный экземпляр, каталог с остальными файлами ядра, длина буфера пути и предполагаемые флаги. Текущим каталогом является /opt/COMODO/, поскольку программа изменила его ранее.

Затем ядро окончательно загружается:

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

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

Однако наша цель - получить достаточно сведений для комплекта разработки C/C++, взаимодействующего с ядром Comodo. Завершив анализ maybe_IFrameWork_CreateInstance, вернемся к main. После вызова разобранной функции исполняется примерно такой псевдокод:

Код проверяет существование пути из глобальной переменной src. Если путь существует, в зависимости от флагов, возвращенных __lxstat, вызывается scan_directory либо scan_stream. Функция проверки каталогов, вероятно, вызывает scan_stream для каждого найденного объекта. Углубимся в эту функцию:

Этот фрагмент особенно интересен. Сначала создаются объекты SCANRESULT и SCANOPTION, затем задаются параметры: проверять ли архивы, применять ли эвристику и так далее. После этого вызывается функция-член pfunc50, получающая основной компонент, имя файла и другие аргументы. Ее точное назначение неизвестно, но полностью понимать ядро Comodo не требуется: наша задача состоит во взаимодействии с ним. Продолжим:

Именно здесь файл проверяется. Переданная pfunc50 локальная переменная inited_to_zero, по-видимому, получила все необходимые сведения. Она вместе с другими аргументами передается CAEEngineDispatch_ScanStream. Особенно важны объекты SCANOPTION и SCANRESULT: первый задает параметры, второй принимает результат. Функция также обнуляет глобальные обратные вызовы, но эту и другие связанные с ними части пока можно пропустить.

Если err неотрицательна, счетчик проверенных файлов увеличивается. Когда поле bFound объекта SCANRESULT истинно, выводится имя найденной вредоносной программы. Наконец, при обнаружении угрозы увеличивается соответствующий счетчик:

Вернемся к main. После функций scan_* выполняется очистка:

Следующий код отменяет возможную незавершенную проверку и освобождает каркас:

Затем закрывается библиотека libFRAMEWORK.so:

Теперь сведений достаточно, чтобы написать собственное средство C/C++ для Comodo Antivirus. Продукт содержит определения всех нужных структур. Чтобы экспортировать структуры и перечисления в заголовочный файл, откройте в IDA окно локальных типов, вызовите его контекстное меню и выберите экспорт в заголовочный файл. Включите создание компилируемого заголовка, задайте путь и запустите экспорт. После исправления ошибок файл можно использовать в обычном проекте C/C++.

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

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

Большую часть псевдокода Hex-Rays можно перенести в проект, но делать это лучше последовательно, а не копировать весь декомпилированный файл сразу. Начнем с необходимых вызовов инициализации, проверки и очистки в main:

Первый аргумент командной строки обозначает проверяемый файл. Программа загружает каркас, создает экземпляр, вызывает scan_stream, выводит сводку, освобождает каркас и выгружает библиотеку. Необходимо реализовать load_framework, maybe_IFrameWork_CreateInstance, scan_stream, uninit_framework и dlclose_framework. Их псевдокод можно поочередно скопировать из декомпилятора Hex-Rays:

После последней директивы подключения добавьте предварительные объявления функций и глобальные переменные:

Основная версия сканера готова. В Linux она компилируется командой:

Для проверки скопируйте ее в каталог /opt/COMODO:

Запустим программу подобно исходному cmdscan:

Программа работает. Теперь выведем дополнительные сведения об обнаруженном или пропущенном файле. В структуре SCANRESULT есть интересные поля:

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

Строку, сообщающую об отсутствии вируса, заменим так:

Перед scan_stream добавим функцию, сопоставляющую идентификаторы сканеров с названиями:

Эти сведения извлечены из уже имевшегося в базе IDA перечисления, поскольку продукт содержит полные символы:

Снова скомпилируем файл, скопируем его в /opt/COMODO и запустим:

Теперь известно, что файл обнаружен механизмом ENGINEDISPATCH, который использовал контрольные суммы CRC. Здесь проверяется испытательный файл EICAR. Для другого файла обнаружение, возможно, удалось бы обойти изменением CRC.

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

Другие компоненты, загружаемые ядром

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

Например, ядро Microsoft Security Essentials mpengine.dll запускает подпрограммы обобщенного обнаружения и лечения, написанные на C++.NET и Lua. Они извлекаются из файлов базы, распространяемых с продуктом и ежедневными обновлениями. Bitdefender поступает подобным образом с двоичными подключаемыми модулями XMD, содержащими динамически загружаемый код. Kaspersky загружает модули и подпрограммы лечения, заново связывая ядро с новыми объектными файлами из обновлений. Иными словами, каждый антивирус решает эту задачу по-своему.

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

Итоги

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

Рассмотрены и другие важные темы:

• Доступные отладочные символы значительно упрощают обратную разработку. Поскольку версии антивируса для разных платформ обычно используют общую исходную базу, компоненты можно исследовать там, где символы присутствуют, а затем перенести их на платформу без символов. Для этого подходят zynamics BinDiff и Diaphora Хосеана Корета.

• Для фаззинга и автоматизации предпочтительна Linux. Wine и родственный проект Winelib позволяют запускать либо переносить в Linux сканеры командной строки Windows.

• Самозащиту антивируса можно обойти. Версии для Linux обычно не защищают себя так, как версии для Windows. Мы рассмотрели несколько приемов отключения механизмов, мешающих отладке.

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

Глава завершилась подробным практическим разбором создания клиентского средства для Comodo Antivirus.

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

Ядро обычно умеет анализировать только файлы и каталоги, иногда память пользовательского пространства, стандартными средствами операционной системы - например, CreateFile или системным вызовом open. Однако файловые системы HFS+ в Mac OS X и NTFS в Windows позволяют скрывать файлы в альтернативных потоках, о которых основные подпрограммы ничего не знают. Дополнительный модуль перечисляет такие потоки, обходит их и запускает проверку всех найденных объектов.

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

При поиске уязвимостей или способов обхода особенно полезно выяснить:

• как и когда файл признается вредоносным;

• как запускаются анализаторы форматов, средства распаковки и распаковщики исполняемых файлов;

• когда к одному образцу применяются обобщенные подпрограммы;

• когда образец отправляется во внутреннюю песочницу, если она есть.

Анализ сканеров раскрывает виды сигнатур и способы их применения к файлам и буферам.

К обобщенным подпрограммам относятся модули, созданные для обнаружения и, вероятно, лечения конкретного файла, каталога, раздела реестра или другого объекта. Например, модуль способен распознать вариант известного файлового вируса Sality, собрать сведения для лечения и поместить их во внутренние структуры, доступные другим компонентам.

С точки зрения поиска уязвимостей такие подпрограммы чрезвычайно интересны. Обработка сложных вирусов подвержена ошибкам. После завершения волны заражений код могут не трогать годами, считая вредоносную программу почти исчезнувшей. Ошибки остаются скрытыми очень долго. Уязвимости, пригодные для эксплуатации, находили даже в подпрограммах обнаружения вирусов группы 29A, программ для MS-DOS и первых версий Microsoft Windows.

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

Поддержка форматов файлов и протоколов

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

К этой категории относятся распаковщики UPX, Armadillo, FSG, PeLite и ASPack; анализаторы PDF, OLE2, LNK, SIS, CLASS, DEX и SWF; средства распаковки zlib, gzip, RAR, ACE, XZ и 7z. Список настолько велик, что именно эти модули являются крупнейшим источником ошибок в любом ядре.

Даже Adobe регулярно находила уязвимости в собственном формате PDF и Acrobat Reader, что видно по длинному перечню записей CVE последних лет. Трудно ожидать, что антивирусная компания напишет безошибочный анализатор формата, частичная опубликованная документация которого занимает 1310 страниц, или 1159 без указателя.

Шансы явно не в пользу антивирусных инженеров. Помимо PDF им приходится создавать механизм OLE2 для документов Microsoft Word, Excel, Visio и PowerPoint, анализатор видео ASF, поддержку исполняемых файлов Mach-O для Mac OS X и ELF, а также множества еще более сложных форматов. Количество возможных ошибок чрезвычайно велико. Если добавить протоколы с отсутствующей или неполной документацией, например Oracle TNS и CIFS, становится ясно: это крупнейшая поверхность атаки любого антивируса.

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

Эвристика

Эвристическое ядро может быть дополнением к основным подпрограммам, которое взаимодействует с другими модулями или использует ранее собранные ими сведения. Пример из открытого антивируса ClamAV - механизм Heuristics.Encrypted.Zip. Он просто проверяет, зашифрован ли исследуемый ZIP паролем.

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

Эвристика подвержена ложным срабатываниям, поскольку опирается лишь на косвенные признаки. Например, PDF может выглядеть поврежденным: содержать JavaScript, потоки с несколькими способами кодирования, в том числе повторным применением FlateDecode или ASCII85Decode к одному потоку, а также строки, похожие на данные в кодировках ASCII, шестнадцатеричной и восьмеричной. Эвристика, вероятно, сочтет такой документ средством эксплуатации уязвимости. Однако его могла создать программа с ошибкой, а Adobe Reader откроет файл без возражений. Перед разработчиком стоит типичная задача: обнаружить угрозу и не вызвать ложное срабатывание на безопасной программе, создающей крайне подозрительные файлы.

Эвристические механизмы бывают статическими и динамическими. Статическим не требуется исполнять или эмулировать образец, чтобы оценить его вредоносность. Динамические наблюдают за исполнением в основной операционной системе либо гостевой среде, например в созданной разработчиками песочнице поверх эмулятора Intel, ARM или JavaScript. Примеры с PDF и ZIP относятся к статической эвристике. Динамические механизмы рассматриваются ниже в разделе об эвристике на основе весов.

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

Байесовские сети

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

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

После обучения байесовская сеть антивируса обычно работает так:

1. Инженеры передают сети новый образец.

2. Система собирает его эвристические признаки и сохраняет состояние во внутренних переменных.

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

4. По полученной оценке образец признается «вероятно вредоносным» либо «вероятно безопасным».

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

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

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

• обнаружения новых образцов, которые, вероятно, являются вредоносными;

• сбора новых подозрительных файлов.

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

Фильтры Блума

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

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

Рассмотрим условный фильтр для базы хешей MD5. Допустим, в ней есть образцы со следующими значениями:

Если MD5 нового образца или буфера не начинается с 9 или E, можно с уверенностью утверждать, что файла нет в наборе для медленных подпрограмм. Если же значение начинается с одного из этих знаков, образец лишь может входить в набор, и для точного ответа потребуется более сложный запрос. Этот упрощенный пример только объясняет принцип работы; существуют намного лучшие способы искать хеш в базе строк фиксированной длины.

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

Эвристика на основе весов

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

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

Допустим, зафиксирована следующая последовательность:

1. Программа читает обычный текстовый файл из каталога, где запущена.

2. Она открывает окно и показывает диалог подтверждения или отмены.

3. Она загружает исполняемый файл с неизвестного домена.

4. Загруженный файл копируется в %SystemDir%.

5. Программа запускает этот файл.

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

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

Сложные подключаемые модули

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

Сканеры памяти

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

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

Пользовательский сканер обращается к прикладному программному интерфейсу операционной системы, например OpenProcess и ReadProcessMemory в Windows, либо к драйверу ядра, созданному разработчиками антивируса.

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

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

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

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

Код для управляемой среды

Ради производительности ядра почти всегда пишутся на C или C++, но подключаемые модули могут использовать языки более высокого уровня. Некоторые продукты поддерживают .NET или особые виртуальные машины для обобщенного обнаружения, лечения и эвристики. Причины таковы:

• Сложность. На высокоуровневом языке проще написать средство обнаружения, лечения или эвристического анализа.

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

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

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

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

Старые разработчики Symantec могут рассказать немало страшных историй о гостевой виртуальной машине GVM. Когда-то она не позволяла отлаживать код обычным отладчиком, поэтому инженеры изобретали собственные способы выяснить причину неисправности. В некоторых виртуальных машинах обнаружение приходилось писать непосредственно на ассемблере: транслятора или компилятора для поддерживаемого набора команд не существовало. Нетрудно понять, почему разработчики антивирусной отрасли не любят виртуальные машины, которые нельзя исследовать знакомыми OllyDbg, GDB и IDA.

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

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

С точки зрения обратной разработки собственная виртуальная машина тоже может стать настоящим кошмаром. Допустим, условный продукт ACME AV исполняет в ней большинство подпрограмм обнаружения, лечения и эвристики. Если машина нестандартна, аналитику придется:

1. Установить, что код предназначен для виртуальной машины, хотя в начале исследования это неизвестно.

2. Восстановить весь поддерживаемый набор команд.

3. Написать для него дизассемблер, обычно в виде модуля процессора IDA.

4. Найти байты подпрограмм в файлах модулей или памяти и извлечь их.

5. Начать анализ в IDA либо собственном дизассемблере из шага 3.

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

Исследование таких модулей обычно слишком сложно. Но при использовании известной среды, например .NET, аналитику может повезти: внутри базы обнаружатся полноценные библиотеки или исполняемые файлы .NET. Тогда подойдет открытый декомпилятор ILSpy или коммерческий .NET Reflector. Вместо менее удобного ассемблера можно будет читать высокоуровневый код с именами функций и переменных.

Языки сценариев

Антивирусы могут исполнять обобщенное обнаружение, лечение и эвристику на Lua, JavaScript и других языках сценариев. Причины те же: безопасность, удобство отладки и простота разработки. Есть и деловая причина: хороших высокоуровневых программистов найти проще, чем хороших разработчиков на C или C++. Новому инженеру не обязательно знать C, C++ и ассемблер. Для написания модуля на Lua или JavaScript ему достаточно изучить прикладной программный интерфейс ядра.

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

Если сценарий скомпилирован в байт-код, может оказаться, что продукт использует стандартную виртуальную машину встроенного языка. Например, для Lua уже существует открытый декомпилятор unluac. Иногда для правильного восстановления исходника понадобится немного изменить его код, но обычно это занимает лишь несколько часов.

Эмуляторы

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

Почти все ядра, за заметным исключением ClamAV, содержат хотя бы эмулятор Intel 8086. Обычно он исполняет файлы PE при содействии отдельного загрузчика, который иногда встроен в сам эмулятор, загрузочные секторы и код командной оболочки. Некоторые продукты применяют его и для ELF. Аналогичного эмулятора Mach-O нам не известно.

Антивирусы также эмулируют ARM, x86_64, байт-код .NET, JavaScript и ActionScript. Сам по себе эмулятор мало полезен и быстро достигает пределов, если программа часто вызывает системные функции. Поэтому обычно задается максимальное количество эмулируемых вызовов, после которого исполнение останавливается.

Поддержать набор команд архитектуры - лишь половина задачи. Вторая половина состоит в правильной имитации прикладного программного интерфейса. Эмулятор должен воспроизводить системные вызовы настоящей операционной системы или среды. Обычно частично поддерживаются библиотеки Windows ntdll.dll и kernel32.dll: антивирус тем или иным способом реализует самые распространенные функции. Нередко они вообще ничего не делают и лишь возвращают код успешного завершения.

То же относится к эмуляции пользовательских программ вместо целой операционной системы. Воспроизводится прикладной программный интерфейс Internet Explorer или Acrobat Reader, чтобы изолированный код не завершился с ошибкой и выполнил свои действия. Затем его безопасное или опасное поведение записывается и анализируется.

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

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

Итоги

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

Основные выводы:

• Модули не являются жизненно важной частью ядра и загружаются по требованию.

• Единого способа загрузки нет. Одни продукты используют обычный прикладной программный интерфейс операционной системы, другие - собственный механизм расшифровки и загрузки.

• От выбранного механизма зависит сложность обратной разработки.

• При исследовании назначения модуля можно следовать простой последовательности действий.

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

• Эвристика ищет аномалии во входных файлах. Она может использовать простые правила или сложные модели, например байесовские сети и веса.

• Эвристические механизмы бывают статическими и динамическими. Статические исследуют файл без исполнения или эмуляции. Например, срабатывание могут вызвать необычные поля заголовка PE либо многократно закодированные разными способами потоки PDF. Динамические пытаются определить вредоносность по поведению исполняемого или эмулируемого кода.

• Анализаторы сложных или недокументированных форматов и протоколов часто становятся источником уязвимостей.

• К сложным модулям относятся сканеры памяти, компоненты на интерпретируемых языках для виртуальной машины и эмуляторы.

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

• Модули на языках сценариев проще писать и сопровождать. Интерпретатор создает дополнительный уровень защиты, но обратная разработка особенно сложна при использовании собственной виртуальной машины.

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

В следующей главе рассматриваются антивирусные сигнатуры, принципы их работы и способы обхода.

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

Графовые хеши исполняемых файлов

Некоторые сложные продукты хранят сигнатуры графов программ. Программу можно представить двумя видами графов:

• Граф вызовов - ориентированный граф связей между всеми функциями, то есть всеми вызывающими и вызываемыми функциями программы.

• Граф потока управления - ориентированный граф связей между базовыми блоками определенной функции. Базовый блок имеет одну точку входа и одну точку выхода.

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

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

Но при неправильных ограничениях подход ухудшает производительность и, как любая сигнатура, вызывает ложные срабатывания. Узнав, что определенная функция обнаруживается по графу, автор угрозы может изменить ее структуру, сделав похожей на функцию безопасной программы - например, notepad.exe из Windows. Инженерам придется создавать новую сигнатуру семейства: прежний граф теперь встречается в безопасном программном обеспечении, поэтому просто расширить правило нельзя.

Для обхода доступны разные приемы:

• изменить граф потока или вызовов, придав ему распространенную структуру из безопасной программы;

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

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

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

Открытым примером средства для построения и проверки графовых сигнатур служит GCluster - сценарий более крупного проекта Pyew.

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

Криптографические хеши подтверждают, что это разные файлы:

Даже сложное нечеткое хеширование двоичных данных их не связывает:

Графовые сигнатуры намного сильнее сигнатур, основанных только на байтах. Но стоимость вычисления часто делает их применение неприемлемым. Поэтому антивирусные компании не стали внедрять этот подход повсеместно.

Итоги

Антивирусные сигнатуры играют неотъемлемую роль в обнаружении угроз и применяются с момента появления защитных программ. По существу, это базы признаков, которые вместе с алгоритмами сопоставления распознают отдельную вредоносную программу или семейство. Для каждого вида в главе также показаны способы обхода.

Рассмотрены следующие сигнатуры:

• Последовательности байтов сопоставляются со строковыми шаблонами в содержимом вредоносного файла.

• Контрольные суммы, например CRC32, преобразуют последовательность байтов в короткий идентификатор, который ищется в базе. Они слабо защищены от коллизий и часто дают ложные срабатывания.

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

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

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

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

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

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

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

• Считанный буфер может передаваться другому процессу через межпроцессное взаимодействие, сокет Unix и другие средства. Клиент получает только итог зараженности, потому что логика обнаружения находится на сервере. Иногда инструментировать придется обе стороны: легкие проверки могут выполняться клиентом, тяжелые - сервером.

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

• Даже если обработать большинство пограничных случаев, сложность не оправдана. Современные статические сигнатуры обходятся намного проще.

Количество форматов распространения вредоносного кода и способов их использования огромно. Далее рассматриваются лишь наиболее распространенные случаи: PE, JavaScript и PDF.

Файлы PE

Исполняемые файлы Windows также называются переносимыми исполняемыми файлами PE. Это любимый формат авторов вредоносных программ: он самодостаточен и может запускаться без другой программы, как это требуется документам Microsoft Word. Хотя PE легко обнаружить и поэтому он не всегда служит первой стадией атаки, вредоносный код часто распространяется через PDF, документы Microsoft Office или уязвимость браузера, а на заключительном этапе все равно записывает один или несколько файлов PE.

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

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

• **TimeDateStamp.** Члены одного семейства иногда имеют одинаковую дату сборки, и она используется как признак либо даже как вся сигнатура. Для операционной системы поле не имеет значения, поэтому его можно свободно изменить или обнулить.

• **MajorLinkerVersion и MinorLinkerVersion.** Версия компоновщика также обычно не важна операционной системе и применяется сигнатурами подобно дате. Ее изменение не нарушает работу файла.

• **MajorOperatingSystemVersion, MinorOperatingSystemVersion, ImageVersion и MinorImageVersion.** Эти поля допускают такие же изменения.

• **AddressOfEntryPoint.** Часто считают, что адрес точки входа не может быть нулевым. На самом деле ноль означает, что исполнение начнется по смещению 0x00, непосредственно с IMAGE_DOS_HEADER и магических байтов MZ.

• Количество разделов. Windows XP допускала не более 96 разделов, а Windows 7 - 65 535. Некоторые ядра ради производительности заранее считают файл поврежденным, если разделов больше 96. Для систем новее давно неподдерживаемой Windows XP это предположение неверно.

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

Другие приемы приведены в материалах Corkami о PE.

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

JavaScript

Большая часть распространяемого через интернет вредоносного кода представляет собой написанные на JavaScript средства эксплуатации уязвимостей браузера. Многие заражения начинаются с уязвимости Internet Explorer или Firefox, внедренной рамки либо заманивания пользователя на сайт, который в конце концов загружает исполняемый файл PE.

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

Что делает следующий код?

Он показывает сообщение cafe: десятичное число 51966 преобразуется в шестнадцатеричное 0xcafe и возвращается строкой посредством toString(16).

Следующий пример сложнее:

Он всего лишь показывает сообщение Hi. Код на рисунке 7.5 делает то же самое, хотя выглядит намного запутаннее.

Рисунок 7.5. Обфусцированный код JavaScript

Количество приемов сокрытия логики и обхода ограничено только воображением. Рассмотрим несколько из них.

Кодирование строк

Знаки строки можно представить множеством способов. Например, настоящая строка частично скрывается последовательностью объединений переменных:

Другой способ - представить строки числами и преобразовать обратно позднее. Можно также применять escape и unescape:

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

Создание и исполнение кода на лету

Многие интерпретаторы создают и исполняют код во время работы. В JavaScript строка передается функции eval. Но подходят и setTimeout, запускающая код после задержки, addEventListener либо document.write, записывающая HTML и JavaScript.

Приемы можно объединять: после задержки исполнить строку, которая через document.write добавит еще один обфусцированный фрагмент, а тот передаст настоящую логику в eval. Цепочка может иметь произвольную длину.

Сокрытие логики: непрозрачные предикаты и мусорный код

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

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

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

PDF

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

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

Для опыта возьмем образец с SHA-1 88b6a40a8aa0b8a6d515722d9801f8fb7d332482, который первоначально обнаруживали 25 из 57 ядер VirusTotal. Он содержит JavaScript. Объекты с таким кодом обозначаются именами /JS или /JavaScript.

Имена допускают запись ASCII и шестнадцатеричное представление. Например, знак a заменяется его кодом с префиксом #: /J#61v#61Script вместо /JavaScript. Можно закодировать и все имя: /#4a#61#76#61#53#63#72#69#70#74.

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

Вернем исходный файл и применим путаницу объектов. Объект PDF имеет приблизительно такой вид:

Здесь 1 и 2 - номера объектов, 0 - редакция, а между << и >> перечислены фильтры данных. После stream располагаются данные, которые завершаются endstream и endobj.

Если номера повторяются, используется последний объект, а предыдущие игнорируются. Но знают ли об этом антивирусные анализаторы? Создадим фиктивный объект номер 66 перед настоящим. Перед строкой 66 0 obj добавим:

После добавления фиктивного объекта число обнаружений падает до 15 из 57. Причиной может быть непонимание повторных номеров либо второй примененный прием.

Данные потока разрешено сжимать и кодировать. В примере фиктивный объект несколько раз сжат фильтром /FlateDecode и представлен шестнадцатерично посредством /AsciiHexDecode. После декодирования и распаковки он потребляет 256 мегабайт оперативной памяти.

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

Добавим новый набор повторяющихся объектов. Объект 70 указывает на JavaScript:

Он ссылается на объект 67 с настоящим кодом. Создадим еще одну копию номера 70 перед действительной. Число обнаружений уменьшится до 13 из 57.

Наконец, применим более радикальный прием. Анализатор Adobe Acrobat не требует закрывать объекты и потоки. Удалим из фиктивного объекта 66 строки endstream и endobj. Результат падает с 13 всего до трех обнаружений.

Функциональность встроенного средства эксплуатации не изменилась, поскольку изменения рассчитаны на особенности анализатора Adobe PDF. В другой программе просмотра результат мог бы отличаться.

Итоги

В главе рассмотрены общие способы обхода сигнатур и приемы для конкретных форматов PE, JavaScript и PDF.

• Реализация анализатора формата утомительна. При отсутствии документации приходится прибегать к обратной разработке. В любом случае невозможно гарантировать безошибочную реализацию сложного формата.

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

• Антивирусы распознают множество форматов. Для каждого нужно понимать структуру и допустимые изменения.

• PE содержит многочисленные поля, неважные операционной системе, например TimeDateStamp. Если сигнатура опирается на них, изменение делает файл нераспознаваемым.

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

• PDF принят повсеместно и одинаково отображается в разных системах, но его спецификация огромна и сложна. Это дает много способов скрыть средство эксплуатации: иначе закодировать встроенный JavaScript, повторять номера объектов, многократно сжимать и кодировать потоки разными фильтрами и так далее.

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

Устройство c:\con открывается во всех версиях от Windows 95 как минимум до Windows 8.1, но не в эмуляторе без такой поддержки. Впрочем, прием действует в основном против новых эмуляторов: в старых ядрах, создававшихся еще при поддержке Windows 9x, эта возможность обычно осталась, поскольку из антивирусного кода редко что-либо удаляют.

Эмуляция команд центрального процессора

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

Код пытается изменить отладочный регистр Intel x86 DR0, что пользовательской программе запрещено. Следующий пример обращается к другому привилегированному регистру, CR0; Norman SandBox долгое время позволял это:

Еще один вариант использует прерывание при переполнении INTO:

Norman SandBox прекращал работу уже при встрече INTO. То же происходило с неопределенной командой UD2 и недокументированной, но широко известной ICEBP:

Документация Intel x86 позволяет найти огромное количество подобных приемов. Приведенные выше были обнаружены всего за два дня исследования.

Противодействие дизассемблированию

Этот способ нарушает работу дизассемблера или вводит его в заблуждение. Современные Intel x86 и AMD x86_64 поддерживают не только старые наборы 8086 и 8087, но также SSE, SSE2, SSE3, SSE4, SSE5, 3DNow!, MMX, VMX, AVX, XOP, FMA и множество других сложных, иногда частично либо полностью недокументированных наборов.

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

Антивирусные компании либо создают собственный дизассемблер, как Kaspersky и Panda, либо используют старую версию diStorm Гила Дабаха, распространявшуюся по лицензии BSD. Собственную реализацию требуется исследовать вручную или подавать ей разные команды, чтобы найти ошибки.

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

Обычный NOP кодируется байтом 0x90, но существуют и другие варианты. Здесь NOP снабжен префиксом REP F3 и ссылается на [EAX+0x66909090]. Допустимость адреса неважна: команда не обращается к нему и не вызывает сбой. Однако некоторые антивирусные дизассемблеры не понимают редкую форму. Похоже, она встречается только в отдельных вариантах файлового вируса Sality.

Поскольку многие продукты применяют diStorm, можно получить старую версию и локально проверить поддерживаемые команды. Вариант BSD не понимает многие наборы, включая AVX и VMX. Достаточно использовать минимальную часть неподдерживаемого набора, не нарушив обычное исполнение программы или кода командной оболочки. Тогда все обобщенные подпрограммы, зависящие от дизассемблера, завершатся неудачно.

Кроме того, команды кодируются несколькими способами, а руководство Intel x86 бывает неполным или ошибочным. Следующие правильные, но плохо документированные формы не разбираются старыми diStorm, udis86 и другими свободными средствами, кроме Capstone:

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

Нарушение работы анализаторов кода

Еще один распространенный прием направлен против анализатора базовых блоков и функций Intel x86. Обычно применяются непрозрачные предикаты и мусорный код с переходом в середину команды x86 или x86_64.

Рассмотрим образец с SHA-1 405950e1d93073134bce2660a70b5ec0cfb39eab. На рисунке 8.1 IDA не обнаружила функцию в точке входа и нашла лишь два базовых блока.

Рисунок 8.1. Дизассемблированный код вредоносной программы FlyStudio

Почему большая часть кода не разобрана? В точке входа 0x45402C выполняется безусловный переход на 0x454031, затем команды PUSHA и CLC, после чего условный переход JNB. Он указывает не на начало обычной команды, а в середину расположения 0x45403A + 2.

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

В IDA листинг можно исправить вручную.

Рисунок 8.2. IDA показывает больше кода FlyStudio после исправления

После изменений обнаруживается дополнительный код. Можно выделить команды от точки start до JNB, нажать P и создать функцию.

Рисунок 8.3. Частично восстановленная функция FlyStudio

Однако она выглядит странно: всего четыре базовых блока, нигде не выбирается ложная ветвь, а в последнем блоке видны недопустимые команды. Причина - еще один непрозрачный предикат с переходом в середину настоящей команды. Команда JP ведет на 0x4540BD + 1, повторяя прежний прием.

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

Рисунок 8.4. Граф потока главной функции FlyStudio

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

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

Другие приемы противодействия

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

Защита от присоединения

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

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

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

Пропуск страниц памяти

Большинство ядер не присоединяется к процессам, поскольку это слишком навязчиво. Вместо этого они обычно:

1. вызывают OpenProcess;

2. несколькими вызовами VirtualQuery определяют страницы памяти;

3. читают первые байты страниц посредством ReadProcessMemory.

Настольный антивирус не может читать все байты всех страниц из-за производительности. Даже один Блокнот Microsoft в 32-разрядной Windows 7 содержит сегменты системных DLL ntdll, kernel32, advapi, gdi32 и других, собственные разделы кода и данных, стек, кучу и виртуальную память - всего около 222 отдельных страниц.

Поэтому сканеры сокращают объем. Часто пропускаются большие страницы или читается только начало каждой. Код и строки можно спрятать на несколько килобайтов или мегабайтов дальше начала. Антивирус прочитает лишь ограниченный объем, обычно до 1024 килобайт, и не увидит настоящие данные.

Другой прием использует то, что внимание обычно уделяется страницам RWX или RX. Код размещается на нескольких страницах только для чтения RO. Попытка исполнения вызывает исключение. Его обработчик временно меняет защиту на RX, продолжает исполнение, а затем снова запирает страницу как RO.

Это лишь один из способов обмануть пользовательский анализ памяти. Ядровой анализ обойти сложнее, хотя последний прием иногда действует и против него.

Путаница форматов

Смешение форматов обходит обнаружение, рассчитанное на определенный тип. Например, Adobe Acrobat Reader в большинстве версий считает PDF все, где магическая строка %PDF-1.X находится среди первых 256 байтов. Поэтому можно создать правильный PDF со средством эксплуатации внутри другого действительного формата - PE, ZIP, JPG и так далее.

Примечание. Примеры файлов-полиглотов есть в разделе Corkami. Среди них документ, одновременно являющийся PDF, HTML с JavaScript и исполняемым файлом Windows PE.

Автоматизация обхода сканеров

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

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

Начальные действия

Нам понадобятся:

• виртуальная машина VirtualBox;

• 32-разрядная Ubuntu Desktop 14;

• открытое средство MultiAV для проверки файла или каталога несколькими сканерами, полностью написанное на Python;

• несколько антивирусов с версией для Linux либо возможностью запуска через Wine и бесплатной лицензией;

• библиотека или комплект обхода: вместо более полного Veil Framework здесь используется сценарий peCloak.py для PE, написанный на Python.

Создайте 32-разрядную виртуальную машину Ubuntu Desktop, установите гостевые дополнения и настройте сетевую карту как мост, чтобы подключаться к слушающим службам TCP внутри гостевой системы.

Установите Git и получите исходный код MultiAV:

Теперь исходники есть, но антивирусы еще не установлены.

Установка ClamAV

Начнем с самого простого. Установите фоновую службу, привязки Python, свежие сигнатуры и запустите службу:

Проверьте сканер на испытательном файле EICAR:

Проверьте привязки Python отсутствием ошибки импорта:

Кроме ClamAV установим:

• Avast для Linux с тридцатидневной испытательной лицензией;

• бесплатный домашний выпуск AVG для Linux;

• бесплатный домашний F-Prot;

• бесплатный Comodo для Linux;

• Zoner Antivirus, продукты которого на момент написания были бесплатными.

Установка Avast

Испытательную версию Avast Core Security для Linux можно запросить на сайте поставщика; требуется действующая электронная почта. Получив ключ лицензии, сведения о репозитории Ubuntu и ключ GPG, выполните:

Скопируйте присланный файл license.avastlic в /etc/avast. Лицензии на 30 дней достаточно для испытательной системы. Запустите и проверьте продукт:

Установка AVG

Загрузите 32-разрядный пакет DEB для Linux. На момент написания использовался avg2013flx-r3118-a6926.i386.deb. Установка состоит из одной команды:

Проверьте EICAR:

Установка F-Prot

Загрузите с сайта F-Prot архив GZip и распакуйте:

Перейдите в созданный каталог и запустите установщик:

Принимайте ответы по умолчанию. После установки программы и свежих сигнатур выполните проверку:

Установка Comodo

Загрузите 32-разрядный пакет Ubuntu с сайта Comodo; в примере это cav-linux_1.1.268025-1_i386.deb. Установите и выполните первоначальную настройку:

Примите лицензию и параметры по умолчанию. Затем запустите графический интерфейс:

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

Поставляемый cmdscan несколько ограничен. В главе 2 было создано улучшенное средство, совместимое с MultiAV; ниже используется именно оно.

Установка Zoner Antivirus

Загрузите Zoner Antivirus для GNU/Linux, выбрав Ubuntu и 32-разрядную версию. Установите пакет:

Зарегистрируйте продукт и получите по электронной почте код. От имени root откройте /etc/zav/zavd.conf и запишите ключ в секцию UPDATE_KEY. Затем обновите сигнатуры, перезапустите службу и проверьте ее:

Все необходимые продукты установлены. Теперь настроим клиент MultiAV.

Настройка MultiAV

MultiAV поддерживал 15 продуктов, задаваемых в config.cfg. Нужно отключить все неиспользуемые ядра. Например, для ESET Nod32 добавьте DISABLED=1:

Оставьте включенными только Avast, AVG, ClamAV, Comodo, F-Prot и Zoner. Полная конфигурация выглядит примерно так:

Проверьте MultiAV файлом EICAR:

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

Следующий шаг - запуск веб-интерфейса и прикладного программного интерфейса JSON. Рядом с multiav.py находится сценарий webapi.py. Запустите его командой:

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

Рисунок 8.5. Главная страница MultiAV

Через нее можно передать один файл для проверки несколькими продуктами. После завершения появится таблица результатов, как на рисунке 8.6, где показан другой экземпляр MultiAV с большим числом антивирусов.

Рисунок 8.6. Результаты антивирусной проверки

Но важнее не веб-интерфейс, а прикладной программный интерфейс для собственных средств. Интерфейс MultiAV на основе JSON предоставляет три метода:

• /api/upload - передать файл и получить отчет;

• /api/upload_fast - проверить только быстрыми сканерами;

• /api/search - получить сохраненный отчет ранее исследованного файла.

upload_fast подходит для проверки измененных вариантов собственной нагрузки. Создать такой вариант Meterpreter или другой программы поможет peCloak.py.

peCloak

peCloak создавался как опыт по обходу антивирусов. Опыт оказался успешным: все исследуемые продукты удалось обмануть, одни с параметрами по умолчанию, другие со специальными ключами. Измененная авторами книги версия находится в каталоге evasion проекта TAHH на GitHub.

Средство преобразует существующие исполняемые файлы Windows PE ради обхода статического обнаружения. Проверим его вручную на образце с MD5 767d6b68dbff63f3978bec0114dd875c:

Известный образец обнаружили пять продуктов. Создадим измененную версию:

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

Окончательное средство

Программа автоматического обхода на основе MultiAV и peCloak должна:

1. принять файл Windows PE;

2. изменить его посредством peCloak;

3. проверить результат;

4. вернуть необнаруживаемый вариант.

Для этого достаточно простого сценария оболочки, использующего peCloak.py и клиент multiav-client.py:

Сценарий запускает peCloak для заданного PE, кодирует его, передает MultiAV и повторяет цикл до появления варианта, который никто не обнаруживает. Проверим упрощенную версию:

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

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

Итоги

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

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

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

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

• PE с неожиданным количеством разделов может исполняться операционной системой, но считаться сканером поврежденным и не проверяться.

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

• Редкие сочетания префиксов и операндов и недокументированные команды мешают дизассемблированию.

• Защита от присоединения отладчика и чтения памяти действует против сканеров памяти.

• Путаница форматов и полиглоты вводят ядро в заблуждение. Например, исполняемый файл под видом PDF может быть передан анализатору PDF вместо PE или наоборот и остаться незамеченным.

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

• Открытый MultiAV проверяет файлы и каталоги несколькими локальными ядрами одновременно.

• Veil Framework и самостоятельный сценарий peCloak изменяют вредоносные файлы, чтобы те перестали обнаруживаться.

• Частный MultiAV вместе со средством преобразования автоматизирует цикл мутации и проверки. После достаточного числа повторений можно получить необнаруживаемый образец.

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

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

• madCodeHook - механизм перехвата в пространстве пользователя, написанный на Delphi и поддерживающий множество сред исполнения. Его применяют антивирусы Comodo, старые версии McAfee и решения Panda.

• EasyHook - открытый механизм перехвата, известный высокой производительностью и полнотой возможностей. Его используют некоторые антивирусные механизмы.

• Detours - закрытый механизм перехвата от Microsoft Research. Его исходный код доступен, однако для использования в коммерческих продуктах требуется приобрести лицензию. Некоторые антивирусы применяют этот механизм в системах наблюдения, работающих в кольце 3.

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

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

2. Затем механизм определяет адреса функций программного интерфейса, за которыми хочет следить антивирус.

3. Первые машинные инструкции функции заменяются переходом к коду антивируса, обрабатывающему соответствующий вызов.

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

Антивирусные библиотеки перехвата можно внедрять разными способами. Раньше одним из самых распространенных был раздел реестра AppInit_Dll, ныне устаревший и не рекомендуемый Microsoft. В нем хранятся пути к одной или нескольким динамическим библиотекам, которые внедряются почти во все процессы Windows в пространстве пользователя, импортирующие user32.dll; исключением служат лишь некоторые процессы, например Csrss.exe. Много лет именно этот способ был основным. Его применяли Kaspersky, Panda, множество других антивирусов, а также вредоносные программы.

Другой популярный, хотя и не вполне надежный прием внедрения действует так: при запуске рабочего стола Windows выполняется компонент антивируса, который посредством CreateRemoteThread внедряет код в процесс explorer.exe и перехватывает функцию CreateProcessInternal. Она вызывается перед созданием каждого нового процесса. Перехватчик устроен так, чтобы внедрять библиотеку наблюдения в память новой программы. Из-за ограничений CreateRemoteThread этот способ не гарантирует наблюдение за всеми новыми процессами, но некоторые антивирусы по-прежнему его используют.

Последний распространенный способ - внедрение динамической библиотеки из пространства ядра. Драйвер антивируса регистрирует обратный вызов PsSetCreateProcessNotifyRoutineEx, а затем из пространства ядра внедряет библиотеку с пользовательским кодом в каждый новый процесс.

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

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

Быстрый способ снять перехват - жестко записать байты пролога в код обхода и заменить ими начало функции. Однако у перехваченной функции пролог может оказаться другим. Более надежный порядок действий таков:

1. Прочитать с диска исходные библиотеки, например код kernel32.dll или ntdll.dll.

2. Определить адреса перехваченных функций в библиотеке. Для этого можно воспользоваться библиотекой Microsoft dbgeng.dll либо самостоятельно пройти по таблице экспорта динамической библиотеки.

3. Прочитать начальные байты этих функций.

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

В следующем разделе показан еще более простой способ обхода подобных эвристических механизмов.

Примечание. Обойти пользовательские перехватчики эвристического механизма может быть даже проще, чем с помощью описанного общего решения. Их устанавливают на разных уровнях. Например, можно перехватить функции CreateFileA и CreateFileW из kernel32.dll либо функцию NtOpenFile из ntdll.dll. Самый низкий уровень пространства пользователя находится в ntdll.dll, но многие антивирусы перехватывают только функции верхнего уровня, экспортируемые из advapi32.dll или kernel32.dll. В таком случае не требуется исправлять память загруженных библиотек: достаточно обращаться к экспортируемому программному интерфейсу ntdll.dll, также называемому собственным программным интерфейсом системы, и механизм антивируса не заметит этих действий.

Обход пользовательской системы предотвращения вторжений

В Comodo Internet Security версии 8 и более ранних были система предотвращения вторжений на узле и песочница. Первая, естественно, являлась эвристическим механизмом. Песочница работала в пространстве ядра, а система предотвращения вторжений была полностью реализована компонентами пространства пользователя. Ее код находился в библиотеке guard32.dll или guard64.dll, в зависимости от архитектуры исполняемой программы, и внедрялся во все пользовательские процессы.

Если бы эти библиотеки не поддерживали рандомизацию размещения адресного пространства (ASLR), их внедрение сделало бы системную защиту ASLR бесполезной для всех пользовательских компонентов защищаемого компьютера. Это еще один пример опасных последствий внедрения библиотек без ASLR. Некоторое время Comodo действительно допускала такую ошибку, как показано на рисунке 9.2.

*Рисунок 9.2. Механизм Comodo без поддержки ASLR, внедренный в Firefox*

Библиотеки Comodo guard32 и guard64 перехватывают пользовательские функции, в том числе экспортируемые kernel32!CreateProcess[A|W], kernel32!CreateFile[A|W] и ntdll!LdrUnloadDll. Быстро избежать обнаружения можно, отключив этот эвристический механизм: сразу после исполнения кода обхода выгрузить библиотеку перехватчиков - guard32.dll для 32-разрядных процессов или guard64.dll для 64-разрядных.

В первой попытке автор просто создал служебную программу со следующим кодом:

Однако это не сработало: функция unhook неизменно возвращала ошибку 5 - «Отказано в доступе». После подключения отладчика к пользовательскому процессу выяснилось, что модуль guard перехватывал FreeLibrary не на уровне kernel32, откуда эта функция экспортируется, а на уровне ntdll.dll, подменив LdrUnloadDll. Чтобы выгрузить механизм предотвращения вторжений из процесса, достаточно снять перехват с LdrUnloadDll, а затем выполнить предыдущий код:

В этом простом примере достаточно восстановить точку входа экспортируемой из ntdll.dll функции LdrUnloadDll, а затем вызвать FreeLibrary с дескриптором библиотеки guard32.dll. Все действительно так просто. Подобный прием неоднократно применяли для обхода других систем предотвращения вторжений. Насколько помнит автор, впервые описание этого подхода появилось в журнале Phrack, том 0x0b, выпуск 0x3e, в 2003-2004 годах: <http://grugq.github.io/docs/phrack-62-05.txt>.

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

Перехватчики в пространстве ядра

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

• PsSetCreateProcessNotifyRoutine добавляет элемент в перечень процедур, вызываемых при создании или удалении процесса, либо удаляет его оттуда.

• PsSetCreateThreadNotifyRoutine регистрирует предоставленную драйвером функцию, которая получает уведомление при создании или удалении потока.

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

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

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

2. Она получает указатель на недокументированный массив PspCreateProcessNotifyRoutine.

3. Затем удаляет все зарегистрированные в нем обратные вызовы.

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

Сначала программе необходимо добиться исполнения кода на уровне ядра, иначе она не сможет удалить зарегистрированные обратные вызовы. Пример удаления обратных вызовов ядра приведен в публикации Даниэля Пистелли: <http://rcecafe.net/?p=116>.

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

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

Для наблюдения за реестром антивирус может зарегистрировать функцию обратного вызова посредством CmRegisterCallback. Функция RegistryCallback получает уведомление о каждой операции с реестром до того, как ее обработает диспетчер конфигурации. И здесь программа из пространства пользователя не способна обнаружить или обойти обратные вызовы ядра: для этого ей потребуется исполнение на уровне ядра. Вредоносная или любая другая программа ядра может удалить обратные вызовы, как в случае с PsSetCreateProcessNotifyRoutine, а затем беспрепятственно работать с реестром, не попадая под перехват антивирусного драйвера ядра. Уровни запросов прерываний показаны на рисунке 9.3.

Рисунок 9.3. Перечень уровней запросов прерываний

Итоги

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

Основные положения главы:

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

• Статические эвристические механизмы пытаются обнаружить вредоносную программу по признакам, найденным при дизассемблировании или анализе заголовков файла. Часто они используют алгоритмы машинного обучения: байесовские сети, генетические алгоритмы или экспертные системы. Обычно истинно эвристическими считают статические механизмы, а динамические называют системами предотвращения вторжений на узле (HIPS).

• Эвристические механизмы на основе экспертных систем реализуют набор алгоритмов, имитирующих способ принятия решений человеком-аналитиком.

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

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

• Пользовательские динамические механизмы перенаправляют отдельные вызовы программного интерфейса, чтобы наблюдать за ними и при необходимости блокировать. Обычно перехватчики реализуют с помощью сторонних библиотек, среди которых EasyHook, Microsoft Detours и madCodeHook.

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

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

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

• Третья разновидность эвристических механизмов сочетает перехватчики в пространстве пользователя и ядра.

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

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

Пример настоящей ошибки, связанной не столько с правами на файл с SUID, сколько с архитектурой, обнаружился в eScan Malware Admin. Это веб-приложение для управления установленными антивирусами eScan было спроектировано так, чтобы исполнять команды от имени root, используя любые входные данные конечного пользователя веб-приложения, что само по себе крайне опасно. Веб-приложение не способно напрямую запускать команды от имени суперпользователя, но из-за другого архитектурного недостатка его задачам требовались такие права. Разработчики «решили» проблему, создав файл /opt/MicroWorld/sbin/runasroot с SUID, который запускал команды по входным данным из веб-приложения.

Это решение привело к множеству проблем, особенно при наличии уязвимостей в самом веб-приложении. Удаленный злоумышленник мог сначала получить права пользователя mwadmin, от имени которого оно работало. Поскольку этот пользователь имел право запускать указанный файл, затем команда runasroot давала злоумышленнику права суперпользователя на целевой машине.

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

Состояние ASLR и DEP для программ и библиотек

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

Некоторые операционные системы, включая macOS и Linux, в зависимости от настроек ядра принудительно применяют ASLR ко всем программам и библиотекам. Windows включает ее только для программ, собранных с соответствующим параметром. При сборке приложений C и C++ в Microsoft Visual Studio этот параметр включен по умолчанию с 2002 года. Однако часть старых приложений создана прежними версиями компилятора, а некоторые разработчики намеренно отключают ASLR, нередко необоснованно ссылаясь на производительность. Само по себе отсутствие ASLR у основного процесса или библиотек еще не является уязвимостью, но помогает злоумышленнику оценить, насколько легко будет эксплуатировать ошибки повреждения памяти.

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

В Windows состояние ASLR и DEP для целевой программы или модуля можно проверить с помощью Process Explorer, файла procexp.exe из комплекта Sysinternals.

На рисунке 10.1 видно, что служба безопасности Bitdefender, выполняющая постоянный анализ, принудительно включает DEP для процесса - это показано в восьмом столбце панели процессов. Однако ни основная программа vsserv.exe, ни большинство библиотек не используют ASLR, что видно в пятом столбце нижней панели. Поэтому автору средства эксплуатации очень легко взять фрагмент кода из этих библиотек или набор жестко заданных смещений, соответствующих нужному шаблону, и построить надежную атаку.

Даже если для процесса или библиотеки ASLR отключена, нельзя безоговорочно считать адрес загрузки равным тому, который один раз показал Process Explorer или другая программа. Адреса библиотек с ASLR могут конфликтовать с базовыми адресами библиотек, выбранных для эксплуатации, и тогда Windows переместит последние. Даже в Bitdefender, где большинство собственных библиотек не поддерживает ASLR, системные библиотеки могут пересекаться с их базовыми адресами и тем самым создавать подобие случайного размещения.

Чтобы найти библиотеки без конфликтов, следует несколько раз перезагрузить компьютер, каждый раз записать их адреса и убедиться, что базовые адреса остаются постоянными. Для службы Bitdefender это не требуется: основная программа vsserv.exe тоже не использует ASLR, а исполняемые файлы загружаются раньше библиотек. Ошибка разработчиков Bitdefender тем самым обеспечивает полностью надежный обход ASLR.

*Рисунок 10.1. У основной программы и большинства библиотек службы безопасности Bitdefender не включена ASLR*

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

Так устроен, например, широко распространенный в Китае и Японии китайский антивирус Kingsoft Internet Security (KIS). Его межсетевой экран прикладного уровня внедряет несколько динамических библиотек во все пользовательские процессы. Поскольку эти библиотеки не используют ASLR, писать средства эксплуатации против пользователей KIS становится проще.

На рисунке 10.2 показано, что во все пользовательские процессы, включая браузер Firefox, внедрена библиотека защиты с постоянным адресом. Злоумышленник, не располагающий иным способом обхода ASLR, может применить внедренные антивирусом библиотеки для надежной эксплуатации уязвимости Firefox на компьютерах определенных пользователей KIS, например в Китае или Японии. К сожалению, этот недостаток встречается не только в данном китайском продукте, но и в нескольких других антивирусах. Некоторые из них кратко рассматриваются в разделе «Программы, усиливающие безопасность».

*Рисунок 10.2. Три библиотеки без ASLR, внедренные в адресное пространство Firefox*

Эксплуатация неправильных прав на объекты Windows

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

Права и установленные списки управления доступом проверяются программой WinObj, файлом winobj.exe из комплекта Sysinternals. Чтобы увидеть права всех объектов, программу необходимо запустить от имени администратора. Затем в каталоге \BaseNamedObjects можно просмотреть все виды объектов и назначенные им разрешения. Например, при исследовании Kingsoft Antivirus следует искать объекты Windows с именами, начинающимися с буквы k.

На рисунке 10.3 показан один из таких объектов - событие kws_down_files_scan_некоторый_идентификатор. Двойной щелчок по объекту ядра открывает окно с двумя вкладками. На вкладке сведений отображается общая информация об объекте Windows, включая число ссылок и открытых дескрипторов. На вкладке безопасности показаны его конкретные права.

WinObj предупреждает, что событию не назначены разрешения, поэтому любой пользователь может получить контроль над этим объектом Windows. Точный текст сообщения:

Этому объекту не назначены разрешения.

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

Как и в примере с ASLR и DEP, отсутствие назначенных объекту Windows разрешений еще не обязательно означает уязвимость антивируса. Однако вероятность того, что объект создаст проблемы продукту или одному из его компонентов, велика. Например, программа может получить контроль над объектом и отозвать доступ к нему у всех пользователей. Тогда ни один другой процесс не сможет открыть событие и по этому каналу не поступит ни одного уведомления.

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

*Рисунок 10.3. У события KIS нет списка управления доступом, и WinObj предупреждает, что объект может захватить любой пользователь*

События и мьютексы, пожалуй, наименее интересны при аудите приложения Windows. Другие объекты способны обеспечить простое повышение привилегий. Лучший пример - объект потока или процесса без списка управления доступом. Такая ошибка встречается относительно редко, но до 2014 года ей были подвержены разные антивирусы, включая Panda Global Protection.

Рассмотрим Panda Global Protection 2012. В отличие от предыдущего случая с Kingsoft Internet Security, здесь лучше пользоваться не WinObj, а Process Explorer из комплекта Sysinternals: он удобнее для исследования пользовательских потоков и процессов. После установки и запуска Panda Global Protection 2012 в Process Explorer можно найти интересующий процесс Panda - SrvLoad.exe, показанный на рисунке 10.4.

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

SetSecurityDescriptorDACL, передавая ей пустой список управления доступом. Впрочем, программисты нередко делают это намеренно, чтобы их собственным процессам было проще открыть объект и взаимодействовать с ним. К сожалению, теми же и даже более широкими возможностями получает любой другой локальный пользователь. Например, локальное средство эксплуатации может открыть процесс и посредством CreateRemoteThread внедрить в него динамическую библиотеку, исполнить код в контексте SrvLoad.exe и повысить привилегии до локальной системы.

*Рисунок 10.4. Процесс Panda SrvLoad, работающий от имени SYSTEM с наивысшим уровнем целостности и без списка управления доступом. Автор сообщил об этой уязвимости, и в 2014 году ее исправили*

При поиске уязвимостей в антивирусах и вообще любых программах Windows необходимо следить и за объектами разделов. Такой объект представляет область памяти, которую могут совместно использовать несколько процессов. С его помощью процесс предоставляет другим процессам часть своего адресного пространства. Объект раздела также позволяет отобразить файл в память процесса. Если разделу назначены неправильные права или список управления доступом отсутствует, любой пользователь может прочитать его содержимое. Это способно раскрыть конфиденциальные сведения, например пароли. Кроме того, злоумышленник может записать в общий раздел искаженные данные и тем самым нарушить работу одного или нескольких процессов антивируса.

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

Эксплуатация логических ошибок

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

Например, процессы Panda Global Protection версий 2011-2013 защищала технология Panda's Shield. Она не позволяла или, по крайней мере, пыталась не позволять локальным процессам завершать анализаторы и системные службы Panda либо внедрять в них оболочечный код. Однако разработчики по неизвестной причине встроили в технологию потайной механизм включения и отключения защиты. Библиотека pavshld.dll экспортирует набор функций: почти у всех понятные человеку имена, за исключением PAVSHLD_001 и PAVSHLD_002, как показано на рисунке 10.5.

*Рисунок 10.5. Функции, экспортируемые библиотекой pavshld.dll*

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

Из прокомментированного дизассемблированного кода видно, что щит Panda отключается, если вызвать библиотечную функцию и передать ей «секретный» универсальный уникальный идентификатор ae217538-194a-4178-9a8f-2606b94d9f13. После вызова с правильным идентификатором изменяется несколько доступных для записи разделов реестра, причем запись в них разрешена группе «Все». В результате антивирусный щит Panda отключается. Эту логическую ошибку можно было найти и другим способом - проверив права соответствующих разделов реестра Panda.

Рисунок 10.6. Секретный универсальный уникальный идентификатор позволяет отключить щит

Понимание удаленной поверхности атаки

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

Чтобы определить компоненты целевого антивируса, доступные для удаленных атак, необходимо выяснить, какие из них обрабатывают внешние данные:

• синтаксические анализаторы различных форматов файлов;

• код обобщенного обнаружения и обезвреживания файлов;

• сетевые службы, панели и консоли администрирования;

• дополнения браузеров;

• межсетевые экраны, системы обнаружения вторжений и их анализаторы сетевых протоколов;

• службы обновления.

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

Далее кратко рассматривается каждая из перечисленных удаленных поверхностей.

Синтаксические анализаторы файлов

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

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

В наши дни некоторые антивирусные компании, как и многие другие поставщики программ, регулярно проверяют безопасность исходного кода и применяют приемы безопасной разработки, чтобы снизить вероятность пригодных для эксплуатации ошибок форматов. Тем не менее аудит с большой вероятностью находит уязвимости в машинном коде антивируса, разбирающем сложные форматы: Microsoft OLE2, PDF, ELF, PE, Mach-O, ZIP, 7z, LZH, RAR, GZIP, BZIP2, LNK, Adobe Flash, MOV, AVI, ASF, CLASS, DEX и другие.

Во время проведенного автором в 2014 году аудита 19 антивирусных продуктов ошибки форматов обнаружились в 14 механизмах - чрезвычайно высокий показатель. По мнению автора, остальные механизмы не завершались аварийно даже после нескольких месяцев фаззинга по одной из двух причин: либо анализаторы запускались в эмуляторе или виртуальной машине, либо были написаны не на языке, компилируемом в машинный код, а на интерпретируемом языке или для управляемой среды. Подобные подходы применяют, например, Symantec, Microsoft и Norton.

Код обобщенного обнаружения и обезвреживания файлов

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

Представим файловый вирус, который заражает исполняемый файл PE и шифрует исходный раздел кода. При проверке такого файла код обобщенного обнаружения должен собрать признаки заражения, прежде чем объявить файл инфицированным. Ему требуется найти исходную точку входа (OEP), место хранения ключа расшифрования и расположение вируса внутри файла PE. Затем код обезвреживания использует собранные сведения, чтобы удалить заражение и восстановить исходное состояние файла.

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

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

Сетевые службы, панели и консоли администрирования

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

• Отсутствие проверки подлинности. Вход в консоль администрирования AVG проверялся на стороне клиента. Поэтому любой пользователь с сетевым доступом к машине мог войти в консоль. С точки зрения безопасности клиентскую проверку трудно вообще считать настоящим входом.

• Отсутствие проверки подлинности сторон. Протокол связи не умел подтверждать личность участников. Злоумышленник мог выдать себя за конечный узел AVG или поддельный сервер администрирования.

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

• Удаленное исполнение кода. Один из передаваемых клиентом серверу параметров, ClientLibraryName, содержал путь к динамической библиотеке, которую загружал сервер администрирования AVG. Если указать удаленный путь в формате универсального соглашения об именовании (UNC), сервер загружал библиотеку по сети и исполнял ее код в своем контексте с правами SYSTEM. Эту крайне серьезную ошибку было чрезвычайно легко эксплуатировать.

Полное уведомление SEC Consult Vulnerability Lab с подробностями доступно по адресу: <https://www.sec-consult.com/fxdata/seccons/prod/temedia/advisories_txt/20140508-0_AVG_Remote_Administration_Multiple_critical_vulnerabilities_v10.txt>.

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

Межсетевые экраны, системы обнаружения вторжений и их анализаторы

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

Эти системы исследуют весь получаемый машиной трафик, поэтому разработчикам антивируса приходится писать код разбора и декодирования сетевых протоколов. Анализатор протокола можно эксплуатировать точно так же, как анализатор формата файла. Насколько вероятно совершенно правильно разобрать, например, протокол HTTP? Он сложен, но создать свободную от ошибок реализацию, возможно, все же удастся. Однако какова вероятность не допустить ни одной уязвимости в коде обработки и разбора

протоколов ARP, IP, TCP, UDP, SNMP, SMTP, POP3, Oracle TNS, CIFS и многих других? Как и в случае с форматами файлов, наличие уязвимостей весьма вероятно.

Службы обновления

Службы обновления, как и процедуры обезвреживания, относятся к наименее исследованным областям обычных антивирусов. Тем не менее они остаются точкой входа удаленных атак. Представим, что служба загружает обновления с сервера HTTP без SSL или TLS, как поступает большинство антивирусных продуктов. Если при этом скачивается новый исполняемый файл, например программа или библиотека Windows в формате PE, злоумышленник может перехватить трафик и подменить обновление измененной вредоносной или полностью вымышленной версией.

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

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

Дополнения браузеров

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

Ошибки антивирусных дополнений особенно часто встречались во времена популярности ActiveX. Многие поставщики создавали уменьшенные версии своих механизмов, которые можно было встроить в веб-страницу как элемент ActiveX для отображения в Internet Explorer. Так пользователь без установленного антивируса мог опробовать продукт. Однако множество подобных компонентов было подвержено целому ряду атак, среди которых чаще всего встречались переполнения буфера и архитектурные недостатки.

Например, F-Secure Anti-Virus версий 2010 и 2011 распространял компонент ActiveX, помеченный как безопасный для сценариев и допускающий загрузку в Internet Explorer. Ошибка переполнения кучи позволяла злоумышленнику удаленно добиться исполнения кода. Уязвимость обнаружила группа Garage4Hackers, опубликовавшая средство эксплуатации по адресу <https://www.exploit-db.com/exploits/17715/>.

Другой пример - компонент ActiveX антивируса Kaspersky AxKLSysInfo.dll, который тоже считался безопасным для сценариев и без предупреждений загружался в Internet Explorer. Он позволял злоумышленнику получать содержимое каталогов FTP и тем самым, возможно, читать сведения с серверов FTP, скрытых за межсетевыми экранами. Это пример архитектурного недостатка дополнения браузера.

Бывали и более серьезные ошибки проектирования. В 2008 году элемент ActiveX антивируса Comodo предоставлял функцию ExecuteStr, фактически исполнявшую команду операционной системы. Злоумышленнику требовалось лишь создать веб-страницу, встроить в нее элемент ActiveX и убедить пользователя открыть страницу в Internet Explorer. После этого ошибка позволяла исполнить любую команду операционной системы в контексте браузера. Это лишь одна серьезная уязвимость антивирусного продукта, и неудивительно, что сходные недостатки затрагивали другие продукты.

Программы, усиливающие безопасность

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

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

На азиатском, особенно китайском, рынке очень популярны локализованные браузеры. Такие браузеры, усиленные средствами безопасности, устанавливают, например, Rising и Kingsoft. Rising предлагает программу, имитирующую Internet Explorer и имеющую китайский интерфейс. Однако она использует движок Internet Explorer 7, не имеет никакой песочницы, а несколько ее модулей не поддерживают ASLR, что особенно привлекательно для разработчика средств эксплуатации.

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

С Kingsoft ситуация еще любопытнее своей катастрофичностью. Компания распространяет локализованный на китайском браузер Liebao, название которого переводится как «гепард». Он основан на измененной старой версии Google Chrome. Во время последней проверки автор обнаружил следующие ошибки:

• песочница была отключена без всякой причины;

• многие библиотеки без ASLR, например kshmpg.dll и iblocker.dll, сохраняли постоянные адреса после перезагрузки;

• устанавливалось даже расширение браузера для снимков рабочего стола пользователя.

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

Итоги

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

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

• Локальное повышение привилегий из-за неправильных прав на файлы или каталоги. Примером служат разряды SUID и SGID в системах Unix.

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

• Отсутствие или неправильное применение защитных средств компилятора и операционной системы. Например, если в Windows антивирус внедряет в процессы защитный модуль без ASLR, каждый такой процесс становится кандидатом для вредоносной локальной атаки. Другой пример - сборка антивируса без поддержки DEP. Оба недостатка облегчают создание надежного средства эксплуатации.

• Ошибки драйверов устройств ядра. Если антивирусный драйвер, например фильтр файловой системы или драйвер самозащиты, взаимодействует с пользовательскими компонентами через IOCTL, неправильная работа с буферами или логическая ошибка может позволить атаковать драйвер из режима пользователя и исполнить код с системными правами.

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

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

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

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

• Код обобщенного обнаружения и обезвреживания файлов. Для удаления заражения антивирус читает и истолковывает байты инфицированного файла. Намеренно подготовленный файл может задействовать ошибку в процедуре обезвреживания.

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

• Дополнения браузеров. Антивирусы регулярно устанавливают их для защиты при просмотре сайтов. Простой пример опасной ошибки - возможность обращаться к дополнению из JavaScript. Злоумышленник заманивает жертву на свой сайт, взаимодействует с дополнением и передает произвольные опасные команды, добиваясь захвата.

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

• Службы обновления. Как показано в главе 5, это серьезное направление атаки с тяжелыми последствиями.

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

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

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

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

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

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

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

Локальные уязвимости отказа в обслуживании в антивирусных драйверах встречаются очень часто. Ежегодно обнаруживается несколько ошибок в самых разных продуктах - от наиболее популярных до малоизвестных. Примеры прошлых лет с демонстрационным кодом можно найти на сайте exploit-db.com, как показано на рисунке 11.4.

Рисунок 11.4. Демонстрационные примеры эксплуатации ошибок отказа в обслуживании

Удаленные атаки отказа в обслуживании

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

• архивные бомбы, как при локальном отказе в обслуживании;

• ошибки синтаксических анализаторов форматов файлов, также совпадающие с локальным случаем;

• ошибки анализаторов сетевых протоколов;

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

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

Архивные бомбы

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

1. Злоумышленник отправляет в целевой почтовый ящик письмо с архивной бомбой во вложении.

2. Сразу после получения письма антивирус начинает анализировать файл.

3. Сразу вслед за первым письмом злоумышленник отправляет второе с вредоносной программой.

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

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

Ошибки синтаксических анализаторов форматов файлов

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

1. Злоумышленник создает вредоносную веб-страницу, которая тем или иным способом определяет установленный антивирус. Можно также без предварительного распознавания атаковать один или несколько выбранных продуктов.

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

3. Через несколько секунд или после определенного события страница выполняет сценарий JavaScript, эксплуатирующий уязвимость браузера.

4. Поскольку ошибка анализатора формата уже отключила антивирус, эксплуатация браузера остается незамеченной и пользователь заражается.

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

Итоги

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

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

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

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

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

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

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

* * *

Часть III. Анализ и эксплуатация

В этой части:

• глава 12: статический анализ;

• глава 13: динамический анализ;

• глава 14: локальная эксплуатация;

• глава 15: удаленная эксплуатация.

Компоненты устанавливаются раздельно соответствующими пакетами DEB для Ubuntu или другого дистрибутива Linux на основе Debian. Уязвимы следующие версии пакетов:

• escan-5.5-2.Ubuntu.12.04_x86_64.deb;

• mwadmin-5.5-2.Ubuntu.12.04_x86_64.deb;

• mwav-5.5-2.Ubuntu.12.04_x86_64.deb.

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

В дистрибутиве Linux на основе Debian пакеты eScan устанавливаются командой:

После установки в /opt/MicroWorld появляется набор каталогов и приложений:

При исследовании локальных приложений всегда полезно искать файлы с SUID и SGID, как объяснялось в главе 10. В данном случае такую проверку следует выполнить даже при поиске удаленной уязвимости; причина станет понятна далее. Команда поиска файлов с SUID в Linux или Unix выглядит так:

Программа runasroot имеет SUID. Ее назначение очевидно из названия: исполнять переданные команды от имени root. Запуск разрешен не всем, а только пользователям root и mwconf; последняя учетная запись создается при установке. Приложение PHP работает в контексте установленного веб-сервера именно от имени mwconf.

Следовательно, если в веб-приложении удастся найти удаленное исполнение кода, команды можно будет сразу запускать от имени root, поскольку mwconf разрешено исполнять runasroot. Такая находка была бы особенно ценной.

Рассмотрим приложение PHP, установленное в /opt/MicroWorld/var/www/htdocs/index.php:

Файлов PHP очень много. Первая страница, которую обычно отдает веб-сервер, находится в index.php и сама по себе не слишком интересна. Однако один участок ссылается на сценарий login.php:

Откроем этот файл и проверим, как выполняется проверка подлинности: возможно, удастся найти способ ее обойти. Сначала код убеждается, что метод запроса CGI в REQUEST_METHOD не равен GET, в отличие, например, от POST:

Затем выполняется несколько проверок действий, не относящихся к нашей задаче. Стоит обратить внимание на использование переменной $runasroot:

Сценарий читает из аргументов приложения несколько интересных полей: uname, сокращенное имя пользователя, и pass, пароль. Еще важнее, что он без лишних церемоний вызывает exec($runasroot) с некоторыми переменными. Однако путь $conffile жестко задан в приложении, поэтому повлиять на него нельзя. Проверим, можно ли управлять аргументами других вызовов exec($runasroot). При дальнейшем анализе обнаруживается подозрительная проверка:

Вызов preg_match ищет перечисленные в выражении знаки и пробел. Вероятно, фильтр должен пресекать обычное внедрение команд с помощью управляющих знаков оболочки. Но в нем забыли по меньшей мере один важный знак - точку с запятой (;). Проследим поток управления и выясним, попадает ли переданный клиентом $passwd в команду операционной системы.

После успешного прохождения всех проверок вызывается check_user. Поиск по исходным файлам показывает, что она реализована в common_functions.php:

Отлично: переданное пользователем поле пароля объединяется со строкой и исполняется функцией PHP exec(), допускающей управляющие знаки командной оболочки. Это позволяет запустить произвольную команду операционной системы. Точка с запятой разделяет команды, поэтому добавленная команда обрабатывается уже не программой runasroot с SUID, а самой оболочкой и исполняется с правами пользователя веб-приложения mwconf. Но, как установлено ранее, этому пользователю разрешено запускать runasroot. Следовательно, команду внедрить можно, хотя непосредственно исполнить код от имени root пока не удается.

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

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

После выполнения команды уязвимая машина пытается подключиться к серверу X11 злоумышленника. Затем из xterm достаточно выполнить следующую команду, чтобы получить права суперпользователя:

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

Итоги

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

В главе были приведены два практических примера: статическое исследование исходного текста и дизассемблированного кода закрытой программы в IDA. Обратная разработка старой версии F-Secure Anti-Virus для Linux выявила в анализаторе формата ошибку, пригодную для удаленной эксплуатации. Простое чтение исходного кода PHP консоли eScan Antivirus для Linux позволило найти удаленное внедрение команд с последующим повышением привилегий.

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

Если целевой антивирус работает только в Windows, фаззер или хотя бы его инструментирующую часть лучше перенести в другую операционную систему, более удобную для автоматизации. Средний и крупный фаззинг в современной Windows затруднителен. Маленькие виртуальные машины удается создавать разве что с Windows XP. Для Windows 7 требуется 10-20 гигабайт дискового пространства, а Windows 8.1 и Windows 10 увеличивают минимальный размер еще сильнее.

Linux и другие системы Unix, например FreeBSD, позволяют создавать очень небольшие виртуальные машины. Иногда для системы с целевым приложением достаточно 1 гигабайта или даже 512 мегабайт диска. Чем меньше виртуальная машина, тем проще ею управлять.

Windows XP достаточно 1-2 гигабайт оперативной памяти, а иногда и 512 мегабайт. Для фаззинга в Windows 7 рекомендуется не менее 2 гигабайт, и на практике чаще всего хорошо работают 4 гигабайта. Меньший объем может породить множество ложных сбоев из-за нехватки памяти и отказов выделения.

Поскольку каждая новая версия Windows требует больше памяти и диска, возникает соблазн проверять приложения Windows из Linux посредством Wine, как кратко описано в главе 2. Название Wine раскрывается как «Wine не является эмулятором». Это свободная открытая реализация программных интерфейсов Windows для Linux. Она исполняет неизмененные двоичные файлы Windows в системах Unix и позволяет вызывать предназначенные только для Windows библиотеки из собственных приложений Unix.

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

Для фаззинга антивируса Windows в Unix полезны два подхода:

• провести обратную разработку основного ядра и перенести его в Unix посредством Winelib;

• что значительно проще, запустить в Linux или Unix через Wine самостоятельный сканер командной строки, если он существует.

Первый подход - исследовать ядро и написать интерфейс для конкретного антивирусного ядра Windows, например Microsoft Security Essentials - дает лучший результат, поскольку не зависит от Wine или другого слоя совместимости. Однако он требует очень много времени. Сначала необходимо восстановить интерфейсы загрузки ядра и запуска сканирования, определить структуры и перечисления, написать неофициальный комплект разработки и только затем создать программу для среды Unix. Для многих задач стоимость в человеко-часах запретительна. В длительном проекте подход оправдан, в небольшом - избыточен.

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

Фаззинг посредством Wine

Перенесем сканер командной строки T3Scan для Windows и запустим его в Linux. Программу можно загрузить по адресу <http://updates.ikarus.at/updates/update.html>.

Потребуются самораспаковывающийся файл t3scan.exe и база вирусов t3sigs.vdb. После загрузки запустим программу через Wine:

В появившемся окне предлагается извлечь файлы. Выберите текущий каталог и нажмите кнопку извлечения. Текущий каталог обычно доступен на виртуальном диске Wine Z:; можно также ввести точку (.). Другой вариант - распаковать инструменты в Windows и скопировать полученные T3Scan.exe и t3.dll в текущую папку.

Когда рядом находятся T3Scan.exe, t3.dll и база t3sigs.vdb, проверим работу T3Scan:

Если справка вывелась, T3Scan правильно работает под Wine. Теперь простой фаззер нужно приспособить к особенностям слоя совместимости. При запуске программы через os.system() в обычном Unix ошибка сегментации SIGSEGV возвращает код 139, SIGBUS - 138 и так далее. С Wine код следует сдвинуть вправо на 8 разрядов, а затем прибавить 128, чтобы получить номер сигнала. После такого преобразования прежний словарь RETURN_SIGNALS остается пригоден.

Добавим признак запуска через Wine. Различия в коде выглядят так:

После внесения изменений можно проверять предназначенный только для Windows сканер Ikarus так же, как ранее собственный сканер Bitdefender:

Продолжение вывода:

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

Проблемы, проблемы и новые проблемы

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

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

Поиск хороших шаблонов

Шаблоны фаззера - это исходные файлы, на которых основаны все изменения. В предыдущих примерах для проверки приложений Windows через Wine использовался файл LZH, а в самом первом запуске - файл ELF. Это лишь два формата из огромного перечня, поддерживаемого антивирусными ядрами.

Полный перечень обычно неизвестен, но почти все ядра поддерживают сжатые файлы и архивы, упаковщики исполняемых файлов, форматы Microsoft Office, HTML, JavaScript, VBScript, XML, ярлыки Windows LNK и многое другое.

Найти хороший шаблон означает выбрать не только поддерживаемый формат, например PE Windows, и его разновидность, например определенный упаковщик, но и содержательный образец этого формата. Если фаззинг контейнеров OLE2, включая документы Microsoft Word и Excel, основан лишь на простейших файлах, он проверит только возможности, задействованные данным корпусом, а не весь набор функций продукта.

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

• Первый образец запускается в целевой программе под двоичным инструментированием, например DynamoRIO или Intel PIN, и записываются исполненные базовые блоки.

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

• Новый файл принимается лишь тогда, когда покрывает код, которого не достигали предыдущие.

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

Автору известно лишь одно почти готовое средство такого отбора - PeachMinset. Описание его работы в прежней версии Peach 3 находилось по адресу <http://community.peachfuzzer.com/v3/minset.html>.

Работа PeachMinset состоит из двух этапов:

1. Сбор трасс для файлов-образцов.

2. Вычисление минимального набора.

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

Пример запуска PeachMinset.exe, который внутри использует Intel PIN, для набора файлов PNG и программы их обработки:

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

Поиск файлов-шаблонов

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

• Google. Индексированные каталоги в Интернете ищутся запросом intitle:"index of /" .lzh, который находит файлы с расширением .lzh.

• Другие запросы Google. Полезен запрос filetype:LZH, хотя из результатов, вероятно, придется исключить страницы Facebook.

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

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

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

• samples/av/clam/clam.sis

• samples/av/clam/clam.odc.cpio

• samples/av/clam/clam.exe.html

• samples/av/clam/clam.ole.doc

• samples/av/clam/clam.d64.zip

• samples/av/clam/clam.mail

• samples/av/clam/clam_cache_emax.tgz

• samples/av/clam/clam.cab

• samples/av/clam/clam.arj

• samples/av/clam/clamav-mirror-howto.pdf

• samples/av/clam/clam.newc.cpio

• samples/av/clam/clam.exe.rtf

• samples/av/clam/clam.7z

• samples/av/clam/clam.ppt

• samples/av/clam/clam-v2.rar

• samples/av/clam/clam.tar.gz

• samples/av/clam/clam.pdf

• samples/av/clam/clam.impl.zip

• samples/av/clam/clam.zip

• samples/av/clam/clam.bin-le.cpio

• samples/av/clam/clam.exe.szdd

• samples/av/clam/clam.chm

• samples/av/clam/clam-v3.rar

• samples/av/clam/clam.exe.bz2

• samples/av/clam/clam.exe.mbox.base64

• samples/av/clam/clam.tnef

• samples/av/clam/clam.exe.binhex

• samples/av/clam/clam.bin-be.cpio

• samples/av/clam/clam.exe.mbox.uu

• samples/av/clam/clam.bz2.zip

Полезен и набор PROTOS Genome Test Suite c10-archive: это большой корпус измененных сжатых файлов следующих форматов и объемов:

• ace - 91 518;

• arj - 255 343;

• bz2 - 321 818;

• cab - 130 823;

• gz - 227 311;

• lha - 176 631;

• rar - 198 865;

• tar - 40 549;

• zip - 189 833;

• zoo - 163 595;

• всего - 1 632 691.

Набор доступен по адресу <https://www.ee.oulu.fi/research/ouspg/PROTOS_Test-Suite_c10-archive>. Хотя он общедоступен и, вероятно, уже входит во внутренние испытательные наборы многих поставщиков, число отказывающих на этих файлах антивирусов может удивить. Если взять их как основу для дальнейших мутаций, результат окажется еще показательнее.

Увеличение покрытия кода

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

Если в покрытом наборе возможностей ошибок не найдено, остаются два подхода:

• найти больше образцов в надежде задействовать новые возможности;

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

Рассмотрим второй подход. Среди наиболее интересных исследуемых и применяемых способов выделяются следующие:

• **Символьное исполнение и решатели SMT.** Инструмент переводит исполненный или найденный в двоичном файле код, извлекает его предикаты, абстрагирует их, строит формулы SMT, после чего решатель ищет изменения входных данных, способные покрыть новые участки.

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

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

Существует по меньшей мере одно впечатляющее открытое средство наподобие SAGE - egas из набора MoFlow, доступного в репозитории проекта. Однако, по словам одного из авторов, версия egas 2014 года не предназначалась для входных буферов крупнее 4 килобайт, поскольку плохо масштабировалась. С настоящими целями и средними либо крупными данными расчет, вероятно, занял бы слишком много времени.

Автор испытывал средство на неназванном антивирусе, но после недели работы и потребления примерно 4 гигабайт оперативной памяти остановил его без результата. Такие инструменты действительно находят настоящие ошибки, однако подходящая конфигурация пока слишком велика для домашнего проекта. egas - качественный и работоспособный исследовательский проект, но на данный момент он ограничен небольшими входными данными.

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

• **American Fuzzy Lop (AFL)** - фаззер с учетом покрытия кода, созданный известным исследователем безопасности Михалом Залевским.

• **Blind Code Coverage Fuzzer (BCCF)** - фаззер из каркаса Nightmare, написанный одним из авторов книги Джоксеаном Коретом.

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

Фаззер слепого покрытия кода

Средство BCCF из Nightmare умеет выполнять следующие задачи:

• Увеличивать возможности образцов - расширять покрытие кода, достигаемое одним исходным шаблоном.

• Находить ошибки - задействовать возможности, которых исходный файл не покрывал.

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

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

• для редкого или устаревшего формата удалось найти лишь несколько образцов;

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

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

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

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

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

Для работы BCCF потребуется комплект Nightmare, доступный в репозитории проекта. Клонировать его в выбранный каталог Linux можно командой:

После клонирования доступны следующие файлы и каталоги:

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

В этом опыте применяется версия 4.2.0-3 для Linux, но подойдет и более новая, поскольку BCCF обращается лишь к стандартному DrCov. Распакуйте комплект в выбранный каталог. Затем скопируйте fuzzers/bcf.cfg.example из Nightmare под именем fuzzers/bcf.cfg и укажите в нем расположение DynamoRIO. Как минимум нужны следующие строки:

После настройки инструментирования и его пути установим Radamsa. Это генератор испытательных данных для проверки устойчивости, то есть фаззер или мутатор. Он пытается вывести грамматику входных файлов, а затем создает результаты в соответствии с ней. Автор считает Radamsa лучшим доступным мутатором. Загрузить и установить его можно командами:

Проверим установленную программу из командной строки:

Radamsa изменяет исходную строку Testing 123, создавая разные варианты. Теперь настроим BCCF для целевой программы, снова взяв Bitdefender. В bcf.cfg добавим:

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

После установки всех зависимостей и настройки можно запустить BCCF. Справка bcf.py выводится без аргументов:

Увеличим покрытие Bitdefender для одного образца следующей командой:

BCCF пытается увеличить покрытие файла sample.lnk не более чем за 100 итераций и сохраняет результаты в out. Через некоторое время появляется сообщение:

Исходный файл покрывал не более 24 594 базовых блоков, а увеличенная версия - 24 702, то есть на 108 больше. Новый файл можно использовать как шаблон дальнейшего фаззинга.

Если убрать последний аргумент, BCCF будет увеличивать покрытие не заданное число итераций, а до ручной остановки:

Продолжение вывода:

В этом примере BCCF создал несколько файлов с увеличенным покрытием. На момент проверки последняя итерация подняла максимум с 24 588 до 30 074 базовых блоков - на 5486 блоков.

Комплект фаззинга Nightmare

Nightmare - это распределенный комплект фаззинга с централизованным управлением. Он ориентирован на серверы Linux, но столь же хорошо работает в Windows и macOS. С его помощью будут динамически проверены разные антивирусы. Адрес проекта уже приводился выше: <https://github.com/joxeankoret/nightmare/>.

Клонировать последнюю версию можно командой:

После загрузки откройте doc/install.txt и выполните все указанные действия. Копия инструкции также доступна в Интернете.

Основные зависимости Nightmare:

• Python - по умолчанию установлен в Linux и macOS, но не в Windows.

• Сервер MySQL - хранит сведения об аварийных завершениях.

• Привязки Capstone для Python - интерфейс к встраиваемой библиотеке дизассемблирования; загрузка доступна на сайте <https://www.capstone-engine.org/download.html>.

• Beanstalkd - в Linux устанавливается командой apt-get install beanstalkd.

• Radamsa - один из нескольких мутаторов Nightmare; исходный адрес проекта: <https://code.google.com/p/ouspg/wiki/Radamsa>.

Для некоторых мутаторов, например понимающих форматы Mach-O и контейнеры OLE2, а также для двоичного инструментирования дополнительно нужны:

• DynamoRIO - открытый набор двоичного инструментирования, доступный на <https://www.dynamorio.org/>.

• Zzuf - универсальный фаззер, устанавливаемый в Linux командой apt-get install zzuf.

• macholib для Python - анализатор файлов Mach-O, полностью написанный на Python и доступный на <https://pypi.python.org/pypi/macholib/>.

После установки зависимостей и создания схемы базы MySQL завершим настройку Nightmare:

Команда запускает веб-сервер, по умолчанию принимающий соединения на localhost:8080. Откройте в браузере <http://localhost:8080>, перейдите к настройкам и задайте пути к образцам, шаблонам и установленному комплекту, адрес сервера очереди Beanstalkd и его порт, по умолчанию 11300, как на рисунке 13.1.

Рисунок 13.1. Итоговая настройка комплекта фаззинга Nightmare

После заполнения полей остается настроить проверяемые цели.

Настройка Nightmare

Первой целью станет ClamAV для Linux. Установим его командой:

Чтобы добавить в Nightmare новую цель, перейдите к проектам. Откроется страница, похожая на рисунок 13.2.

Рисунок 13.2. Создание проекта фаззинга в Nightmare

Заполните поля: имя проекта, необязательное описание и вложенную папку внутри $NIGHTMARE_DIR/samples/ со всеми файлами-шаблонами. Укажите префикс канала Beanstalkd, куда помещаются задания для рабочих процессов, максимальное число постоянно находящихся в очереди образцов для многопроцессной или многоузловой обработки и предельное число итераций без сбоя, после которого проект следует остановить. Затем добавьте проект.

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

• Radamsa multiple - создает архив ZIP с десятью измененными файлами.

• Simple replacer multiple - также создает ZIP с несколькими файлами, но вместо Radamsa заменяет один случайный знак случайно выбранным фрагментом исходного буфера.

• Charlie Miller multiple - действует сходным образом, используя алгоритм, который Чарли Миллер продемонстрировал на CanSecWest в 2008 году.

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

Поиск образцов

Следующий шаг - найти подходящие образцы. Если собственных файлов нет, выберите соответствующий пункт интерфейса: Nightmare автоматически загружает через Google файлы заданного формата. Для проверки ClamAV попробуем получить несколько документов PDF, заполнив форму, показанную на рисунке 13.3.

Рисунок 13.3. Поиск образцов средствами комплекта Nightmare

Процесс займет некоторое время. В итоге свежие файлы PDF появятся в подкаталоге samples/av.

Настройка и запуск фаззера

Перейдите в nightmare/fuzzers, откройте generic.cfg и добавьте следующие строки:

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

Появится примерно такой вывод:

Фаззер начинает бессрочно ждать задания. Для настоящего запуска проекта нужна еще одна команда. В другом терминале создайте образцы:

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

Фаззер наконец работает. Он запускает целевой clamscan под отладочным интерфейсом и записывает каждый сбой проекта. Статистику и результаты можно увидеть во внешнем веб-приложении. Вернитесь к нему и откройте страницу статистики, похожую на рисунок 13.4.

Рисунок 13.4. Статистика проекта ClamAV в Nightmare

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

Рисунок 13.5. Просмотр результатов фаззинга

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

Итоги

Динамический анализ объединяет методы извлечения сведений о поведении приложения во время исполнения. В этой главе были рассмотрены фаззинг и покрытие кода.

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

• Мутаторы изменяют шаблон, входной файл, спецификацию протокола или формата.

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

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

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

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

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

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

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

В целом фаззер работает следующим образом:

1. Получает файл-шаблон и целевую программу.

2. Изменяет шаблон и создает новый файл.

3. Передает его целевой программе, работающей под инструментированием.

4. Записывает аварийные завершения вместе с вызвавшими их файлами.

5. Входные данные, которые привели к исполнению новых блоков, могут стать шаблонами следующей итерации.

6. Все перечисленное составляет один цикл. Процесс повторяется неограниченно, пока не будет выполнено нужное число итераций или найдено достаточно ошибок.

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

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

понять, что образец уже проверялся. Поскольку файлы отличаются лишь байтом или двойным словом, компрессор обработает их чрезвычайно эффективно. Архив ZIP, 7z или RAR с огромным числом вложений останется очень маленьким.

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

Поиск слабостей эмуляторов Intel x86, AMD x86_64 и ARM

Антивирусное ядро обычно содержит не один, а несколько эмуляторов. Чаще всего встречается Intel x86, но нередки AMD x86_64, ARM и даже байт-код Microsoft .NET. Следовательно, злоумышленник может писать сложные части нагрузки на любом поддерживаемом машинном языке.

Отдельные этапы можно разместить в разных файлах Windows PE для разных архитектур. Используя архив, первый файл реализует часть атаки в коде Intel x86, второй продолжает ее на AMD x86_64, а последний выполняет нужное действие на ARM.

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

Использование JavaScript, VBScript и ActionScript

Ранее JavaScript был исключен как средство создания сложной нагрузки или распыления кучи, характерное для браузеров и Adobe Acrobat Reader. Но существует ли интерпретатор или эмулятор JavaScript в антивирусном сканере? В некоторых продуктах - да.

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

У сценарного языка есть два преимущества:

• писать на языке высокого уровня проще, чем на чистом ассемблере;

• добиться эмуляции или интерпретации JavaScript легче, чем файла PE, ELF или Mach-O.

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

Кроме Intel x86, AMD64, ARM и JavaScript, встречаются эмуляторы VBScript и ActionScript. Каждый поставщик или ядро реализует их по-своему.

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

Определение поддерживаемых средств

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

Например, расположение эмулятора машинного кода Zoner AntiVirus для Linux ищется так:

Эмулятор находится либо в zavcli, либо в zavcore.so. Такие компоненты обычно реализуются в библиотеках. Команда rabin2 из комплекта обратной разработки Radare2 перечисляет символы zavcore.so и отбирает имена, возможно относящиеся к эмулятору:

По видимым признакам библиотека поддерживает виртуальную машину файлов PE, на что указывает PE_VMCTX, а также виртуальную машину RAR, реализованную архиватором этого формата. Эти сведения показывают, какие машины можно исследовать на ошибки и эксплуатировать в Zoner AntiVirus.

Поиск ссылок на сценарные движки ничего не находит:

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

У продукта с заведомой поддержкой сценариев, например Comodo, результат иной:

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

Comodo Antivirus поддерживает JavaScript и VBScript, поэтому нагрузку можно написать на любом из этих языков.

Запуск окончательной нагрузки

Выше показано, как определить поддерживаемые эмуляторы и интерпретаторы, использовать архивы для нескольких этапов одной атаки и создать нагрузку. Но как запустить ее заключительную часть? Единого ответа нет: доставка из JavaScript или VBScript совершенно не похожа на доставку из эмулируемого PE.

Во всех случаях действуют следующие правила:

• антивирус анализирует любое содержимое, записанное на диск;

• любое новое содержимое, вычисляемое или исполняемое во время работы, тоже анализируется;

• к каждому новому файлу или буферу применяются все процедуры сканирования.

Если нагрузка написана на ассемблере Intel x86, нужно создать файл, записать в него буфер и закрыть. Антивирус автоматически обработает данные всеми обычными процедурами.

В эмуляторе JavaScript или VBScript достаточно вызвать eval(). Эта функция обычно перехватывается для поиска шаблонов и других проверок вновь созданного буфера. Например, в libSCRIPTENGINE.so Comodo имеется строка:

Перекрестная ссылка приводит к eval(CParamsHelper &):

При каждом вызове eval антивирус сканирует буфер. Если обнаружена угроза, интерпретатор JavaScript останавливается. Следовательно, простой вызов eval позволяет доставить нагрузку, направленную на Comodo Antivirus. По наблюдениям автора, другие антивирусные механизмы тоже часто перехватывают эту функцию, что чрезвычайно полезно для разработчика атаки.

Эксплуатация служб обновления

Служба обновления - одна из уязвимых клиентских частей антивируса. Ее эксплуатация совершенно не похожа на обычное повреждение памяти в анализаторе формата. Обычно необходимо тем или иным способом перехватить соединение между клиентом и сервером загрузки. В локальной сети это делается подменой протокола разрешения адресов (ARP).

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

При поиске уязвимостей службы следует ответить на вопросы:

• используется ли SSL или TLS;

• проверяется ли сертификат сервера;

• подписаны ли обновления;

• проверяет ли служба подпись;

• применяется ли библиотека, позволяющая обойти проверку подписи.

Почти все исследованные автором антивирусы передавали обновления открытым текстом, обычно через HTTP, без SSL или TLS. Любые данные между сервером и клиентом можно было изменить без предупреждения. В редких случаях SSL/TLS применялся только как канал связи, но не для подтверждения личности сервера.

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

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

Даже при проверке подписи старая версия OpenSSL, что встречается нередко, может принять намеренно неправильную подпись. В описании ошибки CVE-2008-5077 говорилось:

Несколько функций OpenSSL неправильно проверяли результат EVP_VerifyFinal, из-за чего искаженная подпись принималась как допустимая. Ошибка затрагивала проверку ключей DSA и ECDSA в SSL/TLS.

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

Следовательно, клиент службы обновления с OpenSSL версии 0.9.8 или более ранней подвержен этой ошибке.

Создание средства эксплуатации службы обновления

Рассмотрим простое средство атаки на службу обновления Dr.Web для Linux и Windows. По меньшей мере в версиях 6.x компоненты загружались через обычный HTTP, а их подлинность якобы подтверждалась простым алгоритмом контрольной суммы CRC. При таких условиях эксплуатация становится элементарной.

Dr.Web обращался к жестко заданному набору серверов обычного HTTP:

• update.geo.drweb.com;

• update.drweb.com;

• update.msk.drweb.com;

• update.us.drweb.com;

• update.msk5.drweb.com;

• update.msk6.drweb.com;

• update.fr1.drweb.com;

• update.us1.drweb.com;

• update.kz.drweb.com;

• update.nsk1.drweb.com.

Подмена ARP и отравление DNS для этих доменов в локальной сети позволяют злоумышленнику отдавать собственные обновления. Сначала клиент выбирает один из серверов и получает файл с отметкой времени, чтобы узнать о наличии новой версии:

Возвращается отметка Unix времени последнего доступного обновления. Затем по drweb32.flg проверяется текущая версия продукта:

Ответ содержит ссылку на последнюю версию, исключенные операционные системы и другие параметры. Затем начинается особенно интересная часть протокола: Dr.Web запрашивает сжатый LZMA каталог всех обновляемых файлов.

Внутри сжатого файла находится примерно такой перечень:

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

• изменить загруженный каталог LZMA и вернуть поддельный перечень с правильной суммой особого компонента, который будет установлен в системе;

• изменить один из файлов, добавить собственную нагрузку и компенсировать CRC, сохранив прежнюю сумму.

Первый вариант гибче и дает больше контроля, тогда как второй сложнее и не нужен. Достаточно сформировать собственный сжатый каталог с суммами устанавливаемых файлов. Размещение не ограничено папкой Dr.Web: как в Linux, так и в Windows можно записывать данные куда угодно.

После загрузки каталога клиент сравнивает CRC. Отличающиеся файлы загружаются и устанавливаются. В Linux каждый файл скачивается отдельно, в Windows - набор исправлений. Запрос набора имеет вид:

Если он недоступен, Dr.Web запрашивает полный установочный файл новой версии:

Атака на службу обновления проходит по следующим этапам:

1. Провести атаку посредника против одной или нескольких машин локальной сети. То же возможно в глобальной сети, но выходит за рамки книги.

2. Подменой ARP и DNS перехватить соединения клиентов с перечисленными серверами обновлений. Для этого используется открытое средство Ettercap.

3. Создать на своей машине поддельный сервер обновлений Dr.Web на Python.

4. Когда уязвимый клиент запросит файлы, вернуть вместо настоящего обновления исполняемый файл Meterpreter, совместимый с Metasploit.

Ниже показано создание нагрузки Meterpreter с помощью каркаса Veil-Evasion, чтобы она не обнаруживалась антивирусом:

Теперь Ettercap должен выполнить подмену ARP и DNS. В дистрибутиве Linux на основе Debian графическая версия устанавливается командой:

Запустите ее с правами суперпользователя:

Параметр -G включает графический интерфейс. В меню выберите единый режим перехвата и нужную сетевую карту. Затем выполните поиск узлов локальной сети и откройте их перечень. В качестве первой цели выберите сетевой маршрутизатор, второй - машину с Dr.Web.

Включите отравление ARP и перехват удаленных соединений. Затем измените etter.dns, в Ubuntu расположенный в /etc/ettercap/etter.dns, добавив подменяемые домены:

После сохранения вернитесь в Ettercap, откройте управление подключаемыми модулями и включите dns_spoof. Теперь на все запросы цели к доменам *.drweb.com возвращается адрес злоумышленника.

Последний шаг использует написанное автором публикации на habrahabr.ru средство на Python:

Продолжение программы:

Код просто имитирует протокол обновления Dr.Web и с помощью программы LZMA из Linux возвращает измененные файлы и сжатый каталог. После запуска средства и попытки обновить антивирус появляются запросы:

На машине злоумышленника запускается обработчик обратного соединения HTTP Metasploit:

Если все выполнено правильно, при обновлении Dr.Web загружает созданную нагрузку Meterpreter. После ее установки в консоли Metasploit появляется новый сеанс, как на рисунке 15.1.

Рисунок 15.1. Успешный захват Dr.Web

На этом все. Как видно, создать средство атаки на уязвимую службу обновления оказалось совсем несложно.

Серверная эксплуатация

Серверная эксплуатация - это удаленная атака на сетевую службу через соседнюю локальную сеть или глобальную сеть, то есть Интернет. К серверным компонентам антивируса, помимо прочего, относятся:

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

• Консоль управления, принимающая предупреждения о заражении клиентских машин, которые затем обрабатывает администратор.

• Сетевые службы, развернутые продуктом: веб-сервер, сервер FTP для обновления клиентов той же сети и другие программы, принимающие соединения.

Различия клиентской и серверной эксплуатации

В общем случае серверная эксплуатация значительно отличается от клиентской, хотя большинство ранее рассмотренных правил сохраняется:

• Средства затруднения эксплуатации усложняют задачу атакующего.

• Ошибки антивирусов, включая отключенную ASLR, неправильно примененную DEP и страницы RWX с постоянными адресами, помогают преодолеть эти препятствия.

Главное отличие заключается в отсутствии серверного программного интерфейса для создания нагрузки. При атаке определенной сетевой службы антивируса обычно нельзя исполнить JavaScript или даже код Intel x86 для формирования нагрузки и распыления кучи.

С другой стороны, эксплуатация антивирусной сетевой службы или сервера обновлений все равно легче, чем атака на OpenSSH, Apache или Microsoft Windows Update. Как и на клиенте, антивирусная служба оказывается более простой целью, чем широко используемая серверная программа, разработчики которой серьезнее относятся к безопасности.

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

Эксплуатация ASLR, DEP и страниц RWX с постоянными адресами

Ошибки отключения DEP, отсутствия ASLR хотя бы у одного модуля и постоянных страниц RWX действуют на сервере так же, как на клиенте:

• при перезаписи стека можно исполнить код непосредственно со стека, если антивирус отключил DEP;

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

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

В этом отношении между клиентской и серверной эксплуатацией нет настоящей разницы.

Итоги

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

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

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

• отсутствие ASLR у одного или нескольких модулей либо системное внедрение в другие процессы библиотек без рандомизации;

• намеренное отключение DEP для исполнения кода со стека или сохранения совместимости со старыми компонентами;

• страницы памяти с правами чтения, записи и исполнения (RWX), особенно по постоянным адресам.

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

Серверные компоненты и сетевые службы защищены теми же средствами и подвержены тем же слабостям. Однако у них есть дополнительные направления атаки:

• серверы обновлений подвержены подмене ARP;

• подпись и целостность передаваемых файлов могут проверяться неправильно, например алгоритмом CRC32 вместо подписи на основе инфраструктуры открытых ключей (PKI);

• защищенный транспорт может применяться неверно, например используется HTTP вместо HTTPS.

Последние два недостатка были наглядно показаны в практической атаке на службу обновления Dr.Web.

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

* * *

Часть IV. Современные направления и рекомендации

В этой части:

• глава 16: современные направления антивирусной защиты;

• глава 17: рекомендации и возможное будущее.

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

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