Невидимая подпись: как драйвер с повреждённым сертификатом обходит проверки Windows
Обнаружил неподписанный драйвер, который успешно загружается в систему. Я протестировал его на всех основных версиях Windows, и он был принят без ошибок. При более глубоком анализе выяснилось, что внутри драйвера присутствует скрытая цифровая подпись. Сам файл содержит подпись, однако встроенный в него сертификат WinAuth 2.0 (смещение 0x1C00–0x3598, размер 0x1998) повреждён.
По всей видимости, механизм проверки в пользовательском режиме Windows (например, в проводнике или через sigcheck) отличается от того, который используется при загрузке драйвера в ядре. Похоже, пользовательский анализатор пытается распарсить всю структуру целиком, что приводит к ошибке. В то же время загрузчик драйвера, вероятно, ищет только определённую DER-последовательность и извлекает из неё минимально необходимые данные.
Это довольно любопытно. Я работал с сертификатами и разбирал структуры DER ранее, и не припоминаю, чтобы openssl выдавал ошибку при корректной структуре. Подпись в PE-файлах обычно оформлена в виде структуры DER. Хотя некоторые значения и сами сертификаты могут быть захэшированы в рамках цепочки доверия, структура в целом не подписана. Это сделано намеренно — чтобы можно было изменять или удалять сертификаты без нарушения подписи. Однако в данном случае, по всей видимости, структура DER была намеренно нарушена таким образом, чтобы вводить в заблуждение пользовательские анализаторы, не мешая при этом загрузке драйвера ядром.
Возможно, это эксплуатирует известную, но не исправленную в ядре Windows уязвимость или некорректную реализацию парсера DER, которая уже была устранена в библиотеках вроде OpenSSL.
Обнаружил неподписанный драйвер, который успешно загружается в систему. Я протестировал его на всех основных версиях Windows, и он был принят без ошибок. При более глубоком анализе выяснилось, что внутри драйвера присутствует скрытая цифровая подпись. Сам файл содержит подпись, однако встроенный в него сертификат WinAuth 2.0 (смещение 0x1C00–0x3598, размер 0x1998) повреждён.
По всей видимости, механизм проверки в пользовательском режиме Windows (например, в проводнике или через sigcheck) отличается от того, который используется при загрузке драйвера в ядре. Похоже, пользовательский анализатор пытается распарсить всю структуру целиком, что приводит к ошибке. В то же время загрузчик драйвера, вероятно, ищет только определённую DER-последовательность и извлекает из неё минимально необходимые данные.
Это довольно любопытно. Я работал с сертификатами и разбирал структуры DER ранее, и не припоминаю, чтобы openssl выдавал ошибку при корректной структуре. Подпись в PE-файлах обычно оформлена в виде структуры DER. Хотя некоторые значения и сами сертификаты могут быть захэшированы в рамках цепочки доверия, структура в целом не подписана. Это сделано намеренно — чтобы можно было изменять или удалять сертификаты без нарушения подписи. Однако в данном случае, по всей видимости, структура DER была намеренно нарушена таким образом, чтобы вводить в заблуждение пользовательские анализаторы, не мешая при этом загрузке драйвера ядром.
Возможно, это эксплуатирует известную, но не исправленную в ядре Windows уязвимость или некорректную реализацию парсера DER, которая уже была устранена в библиотеках вроде OpenSSL.
