Skip to content
KitploitKITPLOIT
ИнструментыЭксплойтыБлог
Log in
Отправить
ИнструментыЭксплойтыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

ЛентыКонтактыКонфиденциальность© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
CVE-2020-15368 — CVE-2020-15368,又名“如何利用易受攻击的驱动程序” | Kitploit
Инструменты/GitHubGitHub/stong/cve-2020-15368
Повышение привилегийАнализ уязвимостейЭксплуатацияШелл-кодОбучение и ОбразованиеРазработка Полезной НагрузкиЭксплуатация Бинарных Файлов
GitHubstong/cve-2020-15368

CVE-2020-15368

CVE-2020-15368,又名“如何利用易受攻击的驱动程序”

Репозиторий
51549104 лет назадПроверено Kitploit

Популярное

Смотреть все →

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

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

Как эксплуатировать уязвимый драйвер Windows

Эксплойт и Proof of Concept (PoC) для CVE-2020-15368. Asrock перепаковал драйвер rweverything для своего инструмента настройки RGB-контроллера и подписал его. Они "защищают" его, шифруя свои ioctl'ы... lol. Мы случайно нашли этот CVE прошлым летом, и, насколько я знаю, драйвер до сих пор не пропатчен. Последствия, конечно, — выполнение произвольного кода в ядре и т.д. Так что наслаждайтесь этим "0day" lol.

Если вы хотите поспорить со мной, является ли это НАСТОЯЩИМ БОНА ФИДЕ CVE, пожалуйста, свяжитесь со мной в Twitter, мы можем устроить грандиозную ссору в публичных соцсетях, и это будет очень интересно для всех участников! Я даже куплю домен для этой ошибки, если вы так захотите. Всё дело в маркетинге!!!!

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

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Данная публикация предоставлена только в образовательных целях. Ответственность за соблюдение всех применимых местных, государственных и федеральных законов лежит на читателе. Автор(ы) данной публикации не несут никакой ответственности и не несут ответственности за любое неправильное использование или ущерб, причиненный программным обеспечением, содержащимся в данной публикации.

Предыстория

Застряв на карантине, мы с моими соседями (Pear0, Codetector) баловались на новой материнской плате Pear0 от Asrock. Ярко-красные светодиоды были крайне раздражающими, и настроить их в Linux было невозможно. Поэтому наш план состоял в том, чтобы реверсировать драйвер Windows, управляющий ими, и воспроизвести операции ввода-вывода в Linux.

Короче говоря, не прошло много времени, как мы поняли, что драйвер буквально является просто универсальным драйвером, предоставляющим произвольный доступ на чтение/запись ко всему. Это включает управляющие регистры, такие как CR3, CR4, физическую память и т.д. Такие драйверы предназначены для использования в качестве отладочного инструмента, и на сайте вендора это четко указано.

docs/lol.png

Нам это показалось крайне забавным. Очень волнительно впервые вызвать тройную ошибку (triple fault) и принудительную перезагрузку компьютера из пользовательского режима. (Возможно, в 20-й раз это менее волнительно.) В любом случае, мы сообщили об ошибке и забыли о ней на год.

Настройка

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

Вы можете просто создать службу для драйвера в Process Hacker (очевидно, требуются права администратора для загрузки драйверов). Затем просто кликните правой кнопкой мыши и запустите. Да, это действительно так просто.

docs/processhacker.png

Мы можем просмотреть наш объект Device в WinObjEx64.

docs/processhacker.png

Мы даже можем поиграть с устройством в FileTest.

docs/filetest.png

docs/filetest2.png

Все эти три инструмента потрясающие, особенно PH и FileTest. Они как швейцарский нож и обязательно должны быть в инструментарии каждого реверс-инженера Windows. Например, насколько я понимаю, Jonas L нашел бесчисленные уязвимости локального повышения привилегий в Windows, просто балуясь в FileTest. Так что в Windows действительно есть отличные инструменты для баловства. Хотел бы я такое же дерьмо в Linux.

Обход "безопасности"

Rweverything имеет ioctl, который принимает ioctl в качестве параметра, управляющего выполняемой операцией (чтение памяти, запись памяти, чтение MSR и т.д.), и объединение некоторых параметров, специфичных для операции, таких как адрес источника, адрес назначения и т.д. Когда мы сравниваем код двух драйверов:

docs/comparison.png

🤔🤔🤔🤔🤔🤔🤔🤔🤔

Тем не менее, драйвер делает жалкую попытку безопасности через сокрытие, требуя, чтобы все вызовы ioctl были соответствующим образом зашифрованы жестко закодированным ключом AES. Код (после некоторой очистки) выглядит так:

if ( IoControlCode == 0x22EC00 )
{

  char enc_key[32];
  memset(enc_key, 0, sizeof(enc_key));
  memmove(enc_key, "C110DD4FE9434147B92A5A1E3FDBF29A", 32ui64);
  memcpy(enc_key + 13, ioctl_args->key, 16);
  
  size_t cb_decrypted = 0;
  my_decrypted_cmd* decryptedCmd = NULL;
  DWORD iv_size = ioctl_args->iv_size;
  DWORD input_size = *(DWORD*)(ioctl_args + bufferLen - 6);

  // на самом деле просто вызывает BCrypt API для получения реализации AES
  if ( (unsigned int)decrypt_ioctl_params(enc_key, 32, ioctl_args->iv, iv_size, ioctl_args + bufferLen - input_size - 6, input_size, &decryptedCmd, &cb_decrypted) )
  {
    // Дешифрование не удалось
    if ( decryptedCmd )
      ExFreePoolWithTag(decryptedCmd, 0);
    irp->IoStatus.Status = 0xC000000D;
    goto Fail_Out;
  }
  IoControlCode = decryptedCmd->opcode;
  Rweverything_Args = &decryptedCmd->args;
}
else // не 0x22EC00
{
  if ( IoControlCode != 0x22E858 &&
       IoControlCode != 0x22E860 &&
       IoControlCode != 0x22E800 &&
       IoControlCode != 0x22E804 )// белый список кодов управления
    IoControlCode = 0; // блокировать всё остальное
}

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

Также интересно, что он позволяет пользователю указать часть ключа (???), зачем — понятия не имею. Код просто очень плохо написан.

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

Общение с драйвером

Мы открываем хендл к драйверу и используем DeviceIoControl для вызова ioctl, все стандартно.

HANDLE hDevice = CreateFileA("\\\\.\\GlobalRoot\\Device\\AsrDrv104", GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

// ... настройка зашифрованных данных ioctl

BOOL result = DeviceIoControl(hDevice, 0x22EC00, ioctl_data, in_buf_size, out_buf, sizeof(out_buf), &bytes_returned, NULL);

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

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

Скачать инструмент