как проверить сигнатуру файла windows

Как проверить подлинность файла, защищенного цифровой подписью

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

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

Как проверить цифровую подпись файла

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

Предположим, вы скачали кошелек Bitcoin Core и хотите проверить его подлинность. На официальном сайте Bitcoin Core вам нужно скачать еще два файла — SHA256SUMS.asc по ссылке «Сверить контрольные суммы релизов» и ключ для подписи релизов laanwj-releases.asc соответствующей версии.

Также вам понадобится программа Gpg4win, предназначенная для шифрования файлов и электронных сообщений. Загрузить ее вы можете с официального сайта www.gpg4win.org/get-gpg4win.html.

В результате вы получите файл sha256sum.txt с хэшем проверяемого приложения.

Если хэши совпадают, идем дальше.

Теперь проверим цифровую подпись. Она содержится в этом же SHA256SUMS.asc и начинается с BEGIN PGP SIGNATURE, смотрите этот скриншот.

Кликните правой кнопкой мыши по файлу SHA256SUMS.asc и выберите в меню «Расшифровать и проверить».

В результате в окошке модуля Kleopatra появится имя предполагаемого владельца, выделите его и нажмите «Импорт».

Предложение заверить сертификат можно отклонить, нажав «Нет».

Готово, нажмите в окне программы «Журнал аудита».

И удостоверьтесь, что в журнале есть запись «Действительная подпись пользователя».

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

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

Источник

Методы обнаружения «склеенных» файлов

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

UNIX: cat image1.jpg archive.rar > image2.jpg
WINDOWS: copy /b image1.jpg+archive.rar image2.jpg

Или же при наличии hex-редактора.

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

Методы детектирования склеенных файлов можно разделить на три группы:

Есть ли жизнь после конца файла?

Для нахождения ответа на этот вопрос, необходимо углубиться в спецификации формата, который является «родоначальником» склеенных файлов и понять его структуру. Любой JPEG начинается с сигнатуры 0xFF 0xD8.

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

Первые восемь байт PNG-файла занимает следующая сигнатура: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Сигнатура конца, которая заканчивает поток данных: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.

Общая сигнатура для всех rar-архивов: 0x52 0x61 0x72 0x21 (Rar!). После неё идет информация о версии архива и прочие сопутствующие данные. Опытным путем было установлено, что архив заканчивается сигнатурой 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46.

Таблица форматов и их сигнатур:

Формат Начальная сигнатура Конечная сигнатура
JPEG 0xFF 0xD8 0xFF 0xD9
PNG 0x89 0x50 0x4E 0x47 0x0D 0x0A 0x1A 0x0A 0x49 0x45 0x4E 0x44 0xAE 0x42 0x60 0x82
RAR 0x52 0x61 0x72 0x21 0x0A 0x25 0x25 0x45 0x4F 0x46

Алгоритм проверки на склейку в данных форматах предельно прост:

GIF и PDF

Формат Начальная сигнатура Конечная сигнатура
GIF 0x47 0x49 0x46 0x38 0x00 0x3B
PDF 0x25 0x50 0x44 0x46 0x0A 0x25 0x25 0x45 0x4F 0x46

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

Особенность ZIP-архивов заключается в наличие трех различных сигнатур:

Сигнатуры Описание
0x50 0x4B 0x03 0x04 Сигнатура обычного архива
0x50 0x4B 0x05 0x06 Сигнатура пустого архива
0x50 0x4B 0x07 0x08 Сигнатура архива, разделенного на части

Структура архива такова:

Local File Header 1
File Data 1
Data Descriptor 1
Local File Header 2
File Data 2
Data Descriptor 2
.
Local File Header n
File Data n
Data Descriptor n
Archive decryption header
Archive extra data record
Central directory

Больше всего интересна центральная директория, которая содержит метаданные о файлах в архиве. Центральная директория всегда начинается с сигнатуры 0x50 0x4b 0x01 0x02 и заканчивается сигнатурой 0x50 0x4b 0x05 0x06, после которых следует 18 байт метаданных. Что интересно, пустые архивы состоят только из конечной сигнатуры и 18 нулевых байт. После 18 байт следует область комментария к архиву, которая является идеальным контейнером для скрытия файла.

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

Размер имеет значение

Структура AVI-файла следующая: каждый файл начинается с сигнатуры RIFF (0x52 0x49 0x46 0x46). На 8 байте идет уточняющая формат сигнатура AVI (0x41 0x56 0x49 0x20). Блок на смещении 4, состоящий из 4 байт, содержит начальный размер блока данных (порядок байт — little endian). Чтобы узнать номер блока, содержащего следующий размер, необходимо сложить размер заголовка (8 байт) и размер, полученный в блоке 4-8 байт. Таким образом вычисляется полный размер файла. Допускается, что вычисленный размер может быть меньше, чем реальный размер файла. После вычисленного размера файл будет содержать только нулевые байты (необходимо для выравнивания границы в 1 Кб).

Пример вычисления размера:

Смещение Размер Следующее смещение
4 31442 8+31442=31450

Как и AVI, WAV-файл начинается с сигнатуры RIFF, однако, у этого файла сигнатура с 8 байта — WAVE (0x57 0x41 0x56 0x45). Размер файла вычисляется таким же образом, как и AVI. Реальный размер должен полностью совпадать с вычисленным.

MP4 или MPEG-4 – формат медиаконтейнера, используемый для хранения видео- и аудиопотоков, также предусматривает хранение субтитров и изображений.
На смещении 4 байта расположены сигнатуры: тип файла ftyp (66 74 79 70) (QuickTime Container File Type) и подтип файла mmp4 (6D 6D 70 34). Для распознания скрытых файлов, нас интересует возможность вычисления размера файла.

Рассмотрим пример. Размер первого блока находится на нулевом смещении, и он равен 28 (00 00 00 1С, порядок байт Big Endian); он же указывает на смещение, где находится размер второго блока данных. На 28 смещении находим следующий размер блока равный 8 (00 00 00 08). Чтобы найти следующий размер блока, необходимо складывать размеры найденных предыдущих блоков. Таким образом, вычисляется размер файла:

Смещение Значение Следующее смещение
0 28 28+0=28
28 8 28+8=36
36 303739 36+303739=303775
303775 6202 303775+6202=309977

Этот широко используемый формат является также контейнером MPEG-4. MOV использует проприетарный алгоритм сжатия данных, имеет похожую на MP4 структуру и используется в тех же целях — для хранения аудио и видеоданных, а также сопутствующих материалов.
Как и MP4, любой mov-файл имеет на 4 смещении 4-х байтную сигнатуру ftyp, однако, следующая сигнатура имеет значение qt__ (71 74 20 20). Правило вычисления размера файла не изменилось: начиная с начала файла вычисляем размер следующего блока и складываем.

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

Проверяем Compound File Binary Format

Этот формат файла, разработанный в Microsoft, также известен под названием OLE (Object Linking and Embedding) или COM (Component Object Model). Файлы DOC, XLS, PPT принадлежат к группе CFB-форматов.

CFB-файл состоит из 512-байтного заголовка и секторов одинаковой длины, хранящих потоки данных или служебную информацию. Каждый сектор имеет свой собственный неотрицательный номер, исключение составляют специальные номера: «-1» — нумерует свободный сектор, «-2» — нумерует сектор, замыкающий цепочку. Все цепочки секторов определены в FAT-таблице.

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

Аномальный размер файла

Как было сказано выше, любой CFB-файл состоит из заголовка и секторов равной длины. Чтобы узнать размер сектора, необходимо считать двухбайтное число на 30 смещении от начала файла и возвести 2 в степень этого числа. Данное число должно быть равно или 9 (0x0009), или 12 (0x000C), соответственно, размер сектора файла равен 512 или 4096 байт. После нахождения сектора необходимо проверить следующее равенство:

(FileSize — 512) mod SectorSize = 0

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

Неизвестный тип сектора

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

FileSize = 512 + CountReal * SectorSize, где FileSize — размер файла, SectorSize — размер сектора, CountReal — количество секторов.

Определим также следующие переменные:

Очевидно, что при неравенстве CountClassified и CountReal можно сделать вывод о возможной склейке файлов.

Источник

Сигнатурные дела: Анализатор файлов и антивирус — своими руками

Содержание статьи

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

Слово автора

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

Сигнатурный анализ

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

Точно так же описываются некоторые признаки, по которым можно определить, что исполняемый файл упакован тем или иным криптором или упаковщиком (например, банальным ASPack). Если ты внимательно читаешь наш журнал, то точно слышал о такой тулзе как PEiD, способной определять наиболее часто используемые упаковщики, крипторы и компиляторы (в базе есть большое количество сигнатур) для переданного ей PE-файла. Увы, новые версии программы давно не выходят, а недавно на официальном сайте и вовсе появилось сообщение, что дальнейшего развития у проекта не будет. Жаль, потому что возможности PEiD (особенно учитывая систему плагинов) вполне могли оказаться мне полезными. После недолгого анализа все-таки стало ясно, что это не вариант. Но покопавшись в англоязычных блогах, я быстро нашел то, что мне подошло. Проект YARA (code.google.com/p/yara-project).

Что такое YARA?

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

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

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

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

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

Установка

Как я уже сказал, проект написан на Python’е, поэтому легко может быть установлен и на Linux, и на Windows, и на Mac. На первых порах можно просто взять бинарник. Если вызвать приложение в консоли, то получим правила для запуска.

$ yara
usage: yara [OPTION]. [RULEFILE]. FILE | PID

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

Свой антивирус

Самый главный вопрос: где взять базу сигнатур известных вирусов? Антивирусные компании активно делятся такими базами между собой (кто-то более щедро, кто-то — менее). Если честно, я поначалу даже сомневался, что где-то в Сети кто-то открыто выкладывает подобные вещи. Но, как оказалось, есть добрые люди. Подходящая база из популярного антивируса ClamAV доступна всем желающим (clamav.net/lang/en). В разделе «Latest Stable Release» можно найти ссылку на последнюю версию антивирусного продукта, а также ссылки для скачивания вирусных баз ClamAV. Нас прежде всего будут интересовать файлы main.cvd (db.local.clamav.net/main.cvd) и daily.cvd (db.local.clamav.net/daily.cvd).

Первый содержит основную базу сигнатур, второй — самую полную на данный момент базу с различными дополнениями. Для поставленной цели вполне хватит daily.cvd, в котором собрано более 100 000 слепков малвари. Однако база ClamAV — это не база YARA, так что нам необходимо преобразовать ее в нужный формат. Но как? Ведь мы пока ничего не знаем ни о формате ClamAV, ни о формате Yara. Об этой проблеме уже позаботились до нас, подготовив небольшой скриптик, конвертирующий базу вирусных сигнатур ClamAV в набор правил YARA. Сценарий называется clamav_to_ yara.py и написан Мэтью Ричардом (bit.ly/ij5HVs). Скачиваем скрипт и конвертируем базы:

В результате в файле clamav.yara мы получим сигнатурную базу, которая сразу будет готова к использованию. Попробуем теперь комбинацию YARA и базы от ClamAV в действии. Сканирование папки с использованием сигнатуры выполняется одной единственной командой:

Игра по правилам

Итак, правило — это основной механизм программы, позволяющий отнести заданный файл к какой-либо категории. Правила описываются в отдельном файле (или файлах) и по своему виду очень напоминают конструкцию struct<> из языка С/С++.

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

1. Каждое правило начинается с ключевого слова rule, после которого идет идентификатор правила. Идентификаторы могут иметь такие же имена, как и переменные в C/С++, то есть состоять из букв и цифр, причем первый символ не может быть цифрой. Максимальная длина имени идентификатора — 128 символов.

2. Обычно правила состоят из двух секций: секция определений (strings) и секция условия (condition). В секции strings задаются данные, на основе которых в секции condition будет приниматься решение, удовлетворяет ли заданный файл определенным условиям.

$my_text_string = «text here»
$my_hex_string =

4.В секции condition содержится вся логика правила. Эта секция должна содержать логическое выражение, определяющее, в каком случае файл или процесс удовлетворяет правилу. Обычно в этой секции идет обращение к ранее объявленным строкам. А идентификатор строки рассматривается в качестве логической переменной, которая возвращает true, если строка была найдена в файле или памяти процесса, и false в противном случае. Вышеуказанное правило определяет, что файлы и процессы, содержащие строку win.exe и один из двух URL, должны быть отнесены к категории BadBoy (по имени правила).

5. Шестнадцатеричные строки позволяют использовать три конструкции, которые делают их более гибкими: подстановки (wildcards), диапазоны (jumps) и альтернативный выбор (alternatives). Подстановки — это места в строке, которые неизвестны, и на их месте может быть любое значение. Обозначаются они символом «?»:

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

Данная запись означает, что в средине строки может быть от 4 до 6 различных байт. Можно реализовать также и альтернативный выбор:

Это означает, что на месте третьего байта может быть 62 В4 или 56, такой записи соответствуют строки F42362B445 или F4235645.

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

Если строка может находиться внутри определенного диапазона адресов, используется оператор in:

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

rule OfExample1
<
strings:
$foo1 = «dummy1»
$foo2 = «dummy2»
$foo3 = «dummy3»
condition:
2 of ($foo1,$foo2,$foo3)
>

Приведенное правило требует, чтобы файл содержал любые две строки из множества ($foo1,$foo2,$foo3). Вместо указания конкретного числа строк в файле можно использовать переменные any (хотя бы одна строка из заданного множества) и all (все строки из заданного множества).

7. Ну и последняя интересная возможность, которую надо рассмотреть — применение одного условия ко многим строкам. Эта возможность очень похожа на оператор of, только более мощная — это оператор for..of:

for expression of string_set : ( boolean_expression )

Данную запись надо читать так: из строк, заданных в string_ set, по крайней мере expression штук должно удовлетворять условию boolean_expression. Или, другими словами: выражение boolean_expression вычисляется для каждой строки из string_set, и expression из них должны возвратить значение True. Далее мы рассмотрим эту конструкцию на конкретном примере.

Делаем PEiD

Итак, когда с правилами все стало более менее ясно, можно приступать к реализации в нашем проекте детектора упаковщиков и крипторов. В качестве исходного материала на первых порах я позаимствовал сигнатуры известных упаковщиков у все того же PEiD. В папке plugins находится файл userdb.txt, который и содержит то, что нам нужно. В моей базе оказалось 1850 сигнатур.

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

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

Ну что, попробуем создать правило, скажем, для ASPack? Как оказалось, в этом нет ничего сложного. Сначала создадим файл для хранения правил и назовем его, например, packers.yara. Затем ищем в базе PEiD все сигнатуры, в названии которых фигурирует ASPack, и переносим их в правило:

У всех найденных записей флаг ep_only установлен в true, то есть эти строки должны располагаться по адресу точки входа. Поэтому мы пишем следующее условие: «for any of them : ($ at entrypoint)».

Чтобы проверить работоспособность полученной системы, достаточно выполнить в консоли команду:

Скормив туда пару приложений, упакованных ASPack’ом, я убедился, что все работает!

Готовый прототип

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

Источник

Операционные системы и программное обеспечение