🐞 CVE-2026-40372: Improper verification of cryptographic signature in ASP.NET Core

Microsoft сама сравнивает эту уязвимость, исправленную на днях, и получившую CVSSv2 9.4, с MS10-070 (2010 год) — классической padding oracle атакой на legacy ASP.NET ViewState/encryption infrastructure. Обе уязвимости разрушают криптографические гарантии целостности, позволяя подделывать подписанные данные. Разница в том, что MS10-070 требовала множественных запросов для oracle-атаки, тогда как CVE-2026-40372 позволяет напрямую подделывать payload'ы, поскольку HMAC-проверка фактически отсутствует.

ASP.NET Core Data Protection — это встроенный фреймворк для симметричного шифрования и HMAC-подписи конфиденциальных данных «на лету». Он применяется повсеместно в ASP.NET Core приложениях: шифрование и подпись authentication cookies, защита antiforgery-токенов, шифрование TempData, защита session state и любых пользовательских payload'ов через IDataProtector.Protect() / Unprotect().

🐛 Уязвимость

В .NET 10.0 разработчики переписали часть кода ManagedAuthenticatedEncryptor — managed-реализации аутентифицированного шифрования, которая используется на Linux, macOS и других не-Windows платформах (на Windows используется отдельный путь через CNG, который этой уязвимостью не затронут).

Регрессия была внесена в метод CalculateAndValidateMac класса ManagedAuthenticatedEncryptor. Ошибка заключалась в двух вещах:

HMAC вычислялся по неправильному диапазону байт payload'а — вместо (IV + ciphertext + AAD) использовались некорректные смещения, из-за чего подпись фактически покрывала не те данные.

Вычисленный хеш в ряде случаев отбрасывался — результат HMAC-вычисления не сравнивался с тегом из входящего payload'а, либо сравнивался с массивом нулевых байт.

Вот, как выглядел уязвимый код код (упрощенно):

// ManagedAuthenticatedEncryptor.CalculateAndValidateMac

private void CalculateAndValidateMac(
    byte[] payloadArray,
    int ivOffset,
    int macOffset,      // смещение, где начинается HMAC-тег в payload
    int eofOffset,      // конец payload
    ReadOnlySpan<byte> validationSubkey,
    byte[] validationSubkeyArray)
{
    using var hmac = new HMACSHA256(validationSubkeyArray);
    byte[] computedMac = hmac.ComputeHash(
        payloadArray,
        ivOffset,
        ivOffset       // <-- ОШИБКА: должно быть (macOffset - ivOffset), хэш считается по пустому буферу
    );
}

В результате любой payload с произвольным содержимым и нулевыми (или любыми) байтами вместо HMAC-тега проходил валидацию.

🧑‍💻 Атаки

Подделка authentication cookie

Формат cookie: Base64Url( [key_id:16B] [IV:16B] [AES-CBC(AuthTicket):NB] [HMAC:32B])

Атакующий формирует поддельный cookie:

var forgedTicket = CreateAuthTicket(
    claimsIdentity: new ClaimsIdentity(new[] {
        new Claim(ClaimTypes.Name, "admin"),
        new Claim(ClaimTypes.Role, "Administrator")
    }, "Cookies")
);

byte[] iv = RandomBytes(16);
byte[] ciphertext = AesCbcEncrypt(arbitraryKey, iv, Serialize(forgedTicket));

byte[] fakeHmac = new byte[32];

// (key_id публично доступен — он передаётся в каждом cookie)
byte[] payload = Concat(knownKeyId, iv, ciphertext, fakeHmac);

string forgedCookie = Base64UrlEncode(payload);

Обход antiforgery-токенов

ASP.NET Core Antiforgery также опирается на Data Protection. Атакующий может аналогичным образом подделать и antiforgery-токен и выполнять CSRF-атаки, обходя стандартную защиту.

Расшифровка защищённых данных

Поскольку MAC-валидация не работает, атакующий может использовать приложение как оракул: отправлять модифицированные payload'ы и по ответам приложения (ошибка расшифровки vs. успех) побайтово восстанавливать ключ шифрования. После чего — расшифровать любые перехваченные ранее protected-payload'ы.

Ну и 🍒, напоследок: если во время окна уязвимости атакующий подделал cookie и аутентифицировался как привилегированный пользователь, приложение выдало ему легитимно подписанные токены — refresh-токены, API-ключи, ссылки для сброса пароля. Эти токены остаются валидными и после обновления до 10.0.7, пока не будет ротирован Key Ring 😕

#уязвимости