Эксперт 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.
Могут ли злоумышленники расшифровать файлы пользователей
На мой взгляд, возможность восстановления после оплаты не была предусмотрена авторами. И вот почему:
- Personal installation key, который надо сообщить авторам вируса после выплаты выкупа, никак не связан с EncryptionKey. И то, и другое — случайные данные. Из одного невозможно получить другое, если только злоумышленники не знают что-то про CryptGenRandom. Еще вариант — они должны отправлять пару EncryptionKey + Personal installation key на свой сервер, но о такой активности вроде никто не сообщал (и я ее в коде не видел, хотя это не исключено на 100%).
- Если я угадал с хеш-функцией SPONGENT, ключ расшифрования должен быть выходом хеша, и чтобы вычислить то, что должен ввести пользователь, надо этот хеш обратить (129 раз), что вряд ли реализуемо на современной технике.
- Энтропия EncryptionKey составляет 32*8 == 256 бит. Энтропия hex-ключа, вводимого пользователем, составляет 32*4 == 128 бит. Любая операция может только уменьшить энтропию. Из 32 шестнадцатеричных символов невозможно получить 32 байта с определенными значениями.
Отличия от Petya образца 9 января 2016
Petya не захотел инфицировать мою тестовую машину. Может ему нужна сеть или что-то еще. Пришлось дампить из памяти.
Я не успел посмотреть код, который формирует сектора, используемые из устанавливаемого вредоносом MBR, но посмотрел скриншоты и код, который выполнится после перезагрузки.
Отличия:
- Используются сектора 0x36-0x39 (против 0x20-0x23 у NotPetya).
- Большинство сервисных функций (вывод текста, чтение/запись секторов) идентичны Petya.
- Присутствует функция и строки для вывода баннера с черепом. В NotPetya очень похожая функция тоже есть, но, вероятно, она никогда не вызывается, а строки обнулены.
- Длина Personal installation key составляет 90 символов (15 групп по 6 символов) против 60 у NotPetya. Используя алфавит из 58 символов можно закодировать максимум 527 бит информации (против 351 у NotPetya).
- В дампе Petya видны строки secp256k1 и secp192k1, что подталкивает к мысли о том, что Personal installation key является производным от EncryptionKey, и вычисляется при помощи криптографии на эллиптических кривых.
- Ключ, вводимый пользователем для запуска расшифрования, должен быть строкой из алфавита «123456789abcdefghijkmnopqrstuvwxABCDEFGHJKLMNPQRSTUVWX» длиной 16 символов.
- Нет ничего похожего на SPONGENT (или какой-то другой хеш).
- В 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, продолжается.
