Un exploit de validation de principe (PoC) pour une vulnérabilité critique de contournement de l’authentification de Veeam Recovery Orchestrator répertoriée comme CVE-2024-29855 a été publié, augmentant le risque d’être exploité dans des attaques.

L’exploit a été développé par le chercheur en sécurité Sina Kheirkha, qui a également publié un article détaillé sur son site. Le message montrait que la faille était pratiquement plus simple à exploiter que ne le suggérait le bulletin du fournisseur.

Contournement d’authentification critique
CVE-2024-29855, classée 9.0 selon CVSS v3. 1 (« critique »), est une vulnérabilité de contournement d’authentification affectant Veeam Recovery Orchestrator (VRO) versions 7.0.0.337 et 7.1.0.205 et antérieures.

La faille permet aux attaquants non authentifiés de se connecter à l’interface utilisateur Web de Veeam Recovery Orchestrator avec des privilèges administratifs.

Le problème provient de l’utilisation d’un secret JSON Web Token (JWT) codé en dur, qui permet aux attaquants de générer des jetons JWT valides pour tout utilisateur, y compris les administrateurs.

Plus précisément, le secret JWT crée et valide des jetons sans aucun caractère aléatoire ou unique dans chaque installation, ce qui le rend suffisamment prévisible et statique pour être exploitable.

Le bulletin de sécurité de Veeam suggère de passer aux versions corrigées 7.1.0.230 et 7.0.0.379 et décrit également les conditions requises pour exploiter la faille. Ces conditions incluent la connaissance d’un nom d’utilisateur et d’un rôle valides et le ciblage d’un utilisateur avec une session active.

« L’attaquant doit connaître le nom d’utilisateur et le rôle exacts d’un compte disposant d’un jeton d’accès VRO UI actif pour accomplir le piratage », lit-on dans le bulletin de Veeam.

Cependant, comme le montre Kheirkha dans son article, certaines de ces exigences peuvent être contournées avec peu d’effort, ce qui rend cette vulnérabilité plus redoutable et plus percutante.

Surmonter les exigences
Kheirkha a constaté que la détermination du rôle peut être facilement surmontée car il ne peut y avoir que cinq rôles (DRSiteAdmin, DRPlanAuthor, DRPlanOperator et SiteSetupOperator).

Le script d’exploitation a été conçu pour itérer entre ces rôles lors de la génération de jetons JWT jusqu’à ce qu’il trouve une correspondance.

Le script d’exploitation de Kherikha en action

Pour trouver un nom d’utilisateur à utiliser dans l’attaque, le chercheur note que le certificat SSL, obtenu simplement en se connectant au point de terminaison cible, contient généralement suffisamment d’indices pour dériver le domaine et les noms d’utilisateur potentiels à utiliser dans une attaque par pulvérisation de jetons.

« Le problème de » connaître le nom d’utilisateur « peut être résolu avec la solution suivante: en supposant qu’il existe un utilisateur nommé [email protected], on peut trouver le nom de domaine en regardant le champ CN du certificat SSL, et le nom d’utilisateur peut être pulvérisé », explique les chercheurs de l’équipe d’invocation.

Enfin, en ce qui concerne l’exigence de « session active », le script PoC de Kheirkha génère et teste des jetons JWT sur une plage d’horodatages pour augmenter les chances d’atteindre une session active.

Une approche plus ciblée et furtive consisterait à enquêter sur les temps d’activité des utilisateurs. Il existe également l’approche de la « force brute », qui implique des tentatives continues jusqu’à ce qu’un jeton de session actif soit mis en correspondance.

Comme l’exploit pour CVE-2024-29855 est désormais accessible au public, les attaquants tenteront probablement de l’exploiter contre des systèmes non corrigés, il est donc crucial d’appliquer les mises à jour de sécurité disponibles dès que possible.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *