Исследователи из Tanto Security обнаружили цепочку уязвимостей в компоненте RadAsyncUpload, входящем в состав Progress Telerik UI for ASP.NET AJAX. Она позволяет неаутентифицированному злоумышленнику последовательно расшифровать и подменить критичные данные конфигурации, а затем выполнить код на сервере приложений. Проблема затрагивает версии с 2010.1.309 по 2026.2.519 включительно, исправление выпущено в версии 2026.2.708, известной как 2026 Q2 SP1.
Детали уязвимостей
Корень цепочки - использование режима AES-CBC без проверки целостности зашифрованных данных. Такой режим сам по себе не защищает от изменений: если приложение не проверяет подлинность шифротекста с помощью отдельного механизма аутентификации, злоумышленник может менять отдельные байты и наблюдать за реакцией сервера. В случае Telerik разница в ответах на корректную и некорректную набивку PKCS#7 позволяет превратить сервер в так называемый оракул набивки. Злоумышленник циклично модифицирует зашифрованный ввод и по ответам восстанавливает содержимое блоков один за другим, не зная ключа шифрования.
Исследователи обнаружили два пути к оракулу: через обработчик RadAsyncUpload и через постбэк страницы, когда состояние контроля передаётся обратно на сервер. Даже при включённом скрытии подробных ошибок сервер выдаёт различия во времени обработки запросов, поэтому атаку можно провести и по таймингу, хотя это существенно усложняет и замедляет её. Найденный оракул позволяет не только прочитать зашифрованные поля конфигурации, но и сформировать собственные значения. Внутренние настройки RadAsyncUpload хранятся в формате JSON, и атакующий способен переопределить такие параметры, как список разрешённых расширений загружаемых файлов. Например, подделанная конфигурация может разрешить приём DLL-файлов.
Вторая часть цепочки связана с небезопасной обработкой типа .NET при разборе результата загрузки. В одном из внутренних компонентов Telerik расшифровывает метаданные, содержащие имя типа, и передаёт управляемое атакующим значение в метод подстановки типа. При обращении серверного обработчика к свойству результата загрузки происходит десериализация JSON в объект указанного типа, причём без проверки допустимости этого типа. Используя известные классы .NET, можно спровоцировать загрузку произвольной сборки с диска по заданному пути. Таким образом, после подмены конфигурации и загрузки вредоносного файла злоумышленник добивается выполнения кода на сервере.
Эксплуатация возможна не для каждой инсталляции Telerik. Нужно, чтобы на сайте была доступна страница с контролом RadAsyncUpload, при этом серверный обработчик должен обращаться к результату загрузки через свойство UploadResult. Кроме того, в конфигурации должен быть задан явный нестандартный ключ шифрования Telerik.AsyncUpload.ConfigurationEncryptionKey. Эти условия не выполняются в конфигурации по умолчанию, однако именно такой ключ рекомендован в документации как усиление безопасности, поэтому они могут присутствовать в корпоративных приложениях.
Исследователи подготовили два варианта вредоносной нагрузки. Первый записывает в корень веб-сайта зашифрованный ASPX-файл, который превращается в командную оболочку при обращении к нему. Второй работает полностью в памяти: он внедряется в процесс IIS и перехватывает запросы, отвечая на команды при наличии специального HTTP-заголовка. Обе нагрузки используют смешанную DLL на C++/CLI, которая исполняет нативный код уже на этапе загрузки, до вызова управляемых методов. Такой подход обходит требования к подписи и позволяет выполнить произвольный код сразу после загрузки файла.
В процессе исследования выяснилось, что в промежуточной версии 2026.1.421 разработчики закрыли один из векторов оракула, однако второй остался доступным. Более того, исследователи показали, что добавленные в этой версии защитные механизмы, включая CSRF-токен и привязку к идентификатору страницы, обходятся при использовании свежего зашифрованного префикса, полученного с легитимной страницы. В итоге цепочка сохранялась вплоть до версии 2026.2.519.
Проблеме присвоены идентификаторы CVE-2026-13181, CVE-2026-13182, CVE-2026-13183 и CVE-2026-13184. Первый относится к опасной подстановке типа, второй - к основному оракулу набивки, третий - к тайминговому варианту атаки, четвёртый - к предсказуемому ключу HMAC в определённых конфигурациях. Progress Software устранила все четыре уязвимости в версии 2026.2.708, заменив AES-CBC на аутентифицированное шифрование AES-GCM.
Переход на GCM принципиально меняет картину. Теперь каждый зашифрованный блок сопровождается проверочным тегом, и сервер отклоняет любые изменённые данные до расшифровки. Кроме того, в GCM нет набивки, поэтому исчезает сам признак, по которому оракул отличал корректные данные от повреждённых. Это закрывает и видимый, и тайминговый канал.
Организациям, использующим Telerik UI для ASP.NET AJAX, следует немедленно обновить компоненты до версии 2026.2.708 или более поздней. Дополнительно стоит проверить, какие страницы с RadAsyncUpload доступны из интернета, проанализировать обработчики загрузки на предмет обращений к UploadResult и поискать в системах необычные DLL-файлы или подозрительную активность процессов IIS. Даже при выполнении всех условий для атаки, она требует значительного числа запросов, поэтому в логах могут остаться следы в виде серий ошибок или аномального трафика к страницам с контролом.
История с RadAsyncUpload - очередное напоминание о том, что шифрование без аутентификации оставляет брешь, даже когда ключ недоступен злоумышленнику. Оракулы набивки периодически находят в зрелых продуктах, и единственным надёжным решением остаётся использование аутентифицированных режимов шифрования. Обновление до AES-GCM в Telerik - шаг в правильном направлении, и пользователям не стоит откладывать установку исправления: лабораторная эксплуатация цепочки уже подтверждена, а условия для неё могут существовать в реальных корпоративных средах.
Ссылки
