Эксперт Positive Technologies Дмитрий Скляров представил сравнительный анализ нашумевшего вируса-вымогателя NotPetya, атаковавшего компании в этот вторник, с образцом Petya от 2016 года и поделился своими наблюдениями по поводу возможности восстановления зашифрованных ими данных.

Мы исследовали части двух вирусов, отвечающие за шифрование MFT. Данное шифрование выполняется при наличии у вымогателя прав администратора.

Что делает NotPetya

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

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

— Признак того, что MFT не была зашифрована (значение 0)
— EncryptionKey (случайная последовательность длиной 32 байта)
— Nonce (случайная последовательность длиной 8 байт)
— Personal installation key (случайная последовательность длиной 60 символов из алфавита «123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz»)

Случайные данные получаются через функцию CryptGenRandom, которая считается криптографически стойкой.

В сектор 0x21 записывается 512 байт со значением 0x07.

В сектор 0x22 записывается оригинальный MBR, в котором каждый байт поXORен со значением 0x07.

После первой перезагрузки происходит зашифрование MFT. Перед этим:

— читается сектор 0x20,
— устанавливается признак зашифрования MFT (значение 1),
— EncryptionKey копируется во временный буфер,
— поле с EncryptionKey затирается нулевыми байтами
— сектор 0x20 записывается на диск,
— читается сектор 0x21 (все 0x07),
— его содержимое зашифровывается на EncryptionKey + Nonce,
— сектор 0x21 записывается на диск.

Затем сектора MFT зашифровываются на том же EncryptionKey + Nonce. Код алгоритма шифрования очень похож на алгоритм Salsa20, но есть отличия. Вместо константы «expand 32-byte k» используется константа «-1nvalid s3ct-id». И пока мне не удалось повторить результаты зашифрования на известном ключе. Возможно, у них где-то ошибка, что, похоже, подтверждается этим постом.

Алгоритм Salsa20 считается стойким.

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

Ключ должен быть строкой символов из набора «0123456789abcdef» длиной 32. Эта строка прогоняется через некую функцию, принимающую на вход произвольное кол-во байт, и выдающую 32 байта. Предположительно это хеш-функция SPONGENT (надо проверять). Затем выход циклически прогоняется через ту же функцию 128 раз, и этот результат принимается как EncryptionKey. Для проверки правильности ключа делается попытка расшифровать содержимое сектора 0x21, и если там оказывается ожидаемый открытый текст (все 0x07) – запускается процесс расшифрования MFT и восстановления MBR.

Могут ли злоумышленники расшифровать файлы пользователей

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

1. Personal installation key, который надо сообщить авторам вируса после выплаты выкупа, никак не связан с EncryptionKey. И то, и другое — случайные данные. Из одного невозможно получить другое, если только злоумышленники не знают что-то про CryptGenRandom. Еще вариант — они должны отправлять пару EncryptionKey + Personal installation key на свой сервер, но о такой активности вроде никто не сообщал (и я ее в коде не видел, хотя это не исключено на 100%).
   
   
2. Если я угадал с хеш-функцией SPONGENT, ключ расшифрования должен быть выходом хеша, и чтобы вычислить то, что должен ввести пользователь, надо этот хеш обратить (129 раз), что вряд ли реализуемо на современной технике.
   
   
3. Энтропия EncryptionKey составляет 32*8 == 256 бит. Энтропия hex-ключа, вводимого пользователем, составляет 32*4 == 128 бит. Любая операция может только уменьшить энтропию. Из 32 шестнадцатеричных символов невозможно получить 32 байта с определенными значениями.

Отличия от Petya образца 9 января 2016

Petya не захотел инфицировать мою тестовую машину. Может ему нужна сеть или что-то еще. Пришлось дампить из памяти.

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

Отличия:

1. Используются сектора 0x36-0x39 (против 0x20-0x23 у NotPetya).
2. Большинство сервисных функций (вывод текста, чтение/запись секторов) идентичны Petya.
3. Присутствует функция и строки для вывода баннера с черепом. В NotPetya очень похожая функция тоже есть, но, вероятно, она никогда не вызывается, а строки обнулены.
4. Длина Personal installation key составляет 90 символов (15 групп по 6 символов) против 60 у NotPetya. Используя алфавит из 58 символов можно закодировать максимум 527 бит информации (против 351 у NotPetya).
5. В дампе Petya видны строки secp256k1 и secp192k1, что подталкивает к мысли о том, что Personal installation key является производным от EncryptionKey, и вычисляется при помощи криптографии на эллиптических кривых.
6. Ключ, вводимый пользователем для запуска расшифрования, должен быть строкой из алфавита «123456789abcdefghijkmnopqrstuvwxABCDEFGHJKLMNPQRSTUVWX» длиной 16 символов.
7. Нет ничего похожего на SPONGENT (или какой-то другой хеш).
8. В Salsa20 используется оригинальная константа «expand 32-byte k». При этом, код функций почти идентичен, и если код Petya наверняка был сгенерирован компилятором (сработала оптимизация на повторяющихся символах), то в NotPetya, похоже, просто заменили константы.

Petya:



NotPetya:



Я бы предположил, что существовал другой образец Petya, на базе которого и был создан NotPetya путем замены констант и строк.

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

UPD

Среди различных версий вредоноса Petya от 2016 года, который под разными цветами (1, 2) выступал в дуэте с вымогателем mischa и еще в таком виде, следует обратить внимание на PetyaGoldenEye.malware, впервые отправленный на VirusTotal в декабре прошлого года.

Код, который NotPetya записывает при заражении в начало диска, и который запускается из MBR, чрезвычайно похож на код, записываемый PetyaGoldenEye: SHA256:b5ef16922e2c76b09edd71471dd837e89811c5e658406a8495c1364d0d9dc690.

Обнаруженные отличия NotPetya от PetyaGoldenEye:

• Изменены многие текстовые строки (исправлен текст сообщения о выкупе, убрана картинка с черепом);
• Изменены смещения до некоторых строк (начала строк «съехали» из-за изменения размера сообщений);
• В функции по адресу 0000:86E0 перепрыгивается (никогда не выполняется) кусок кода, отвечающий за вывод баннера (мигающего «черепа с костями») до нажатия любой клавиши;
• Там же изменен цвет баннера с желтого (0xE) на красный (0xC), но баннер все равно не показывается;
• По адресу 0000:848E убран (заменен на три инструкции NOP) вызов функции, очищающей буфер клавиатуры (не требуется, так как не ожидалось нажатие);
• В функции по адресу 0000:96D4 (expand для Salsa20) начальное состояние строки заменено с «expand 32-byte k» на «-1nvalid s3ct-id»;
• В функции по адресу 0000:998E (permute для SPONGENT) изменено начальное значение LFSR (linear-feedback shift register), вместо 0x9E используется 0xA3.

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

Хеш-функция SPONGENT

Код, реализующий SPONGENT был, вероятно взят отсюда. Если в функции permute() заменить начальное значение переменной «lfsr» и переписать функцию spongent() так, чтобы она принимала на вход не Null-terminated строку, а указатель на массив и длину массива, получится код эквивалентный использованному в NotPetya.
Примечательно, что начальное значение LFSR == 0x9E (как описано в оригинальной спецификации для SPONGENT-256/256/16) дает 140 раундов, а использованное в NotPetya начальное значение 0xA3 дает 152 раунда (криптостойкость слегка увеличена).

Функция шифрования Salsa20

Код, реализующий Salsa20 был, вероятно, позаимствован отсюда. Если в функции s20_expand32() заменить значение массива «o» и заменить тело функции s20_littleendian() строкой «return *(__int16*)b;», получится код эквивалентный использованному в NotPetya.

Из-за того, что функция s20_littleendian() реализована неправильно (вероятно, вследствие неправильного определения типа или ошибки 16-битового компилятора), значения двух из каждых четырех байт в массиве «keystream» никак не используются. Это фактически делает ключ шифрования 128-битовым, а не 256-битовым. Однако, полный перебор 128-битового ключевого пространства на современном уровне технологий считается нерешаемой задачей.

Выводы и предположения

Авторы Petya реализовали шифрование MFT при помощи стойких (хотя и не очень широко распространенных) криптографических примитивов, код которых был позаимствован из репозиториев на GitHub.

В процессе подготовки первой версии (Petya Red) были допущены ошибки, и это позволило расшифровывать данные без уплаты выкупа.

В последующих версиях (Petya Green, PetyaGoldenEye) ошибки частично были исправлены, и осталась только ошибка преобразования типов, снижающая эффективную длину ключа в два раза. Делались попытки реализовать атаку на исправленную версию, но к успеху они не привели.

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

Поиск способов вернуть файлы, зашифрованные NotPetya, продолжается.