Exploit for Veeam Recovery Orchestrator auth bypass available, patch now

A proof-of-concept (PoC) exploit for a critical Veeam Recovery Orchestrator authentication bypass vulnerability tracked as CVE-2024-29855 has been released, elevating the risk of being exploited in attacks.

The exploit was developed by security researcher Sina Kheirkha, who also published a detailed post on his site. The post showcased that the flaw is practically more straightforward to exploit than the vendor's bulletin suggested.

Critical authentication bypass

CVE-2024-29855, rated 9.0 as per CVSS v3.1 ("critical"), is an authentication bypass vulnerability impacting Veeam Recovery Orchestrator (VRO) versions 7.0.0.337 and 7.1.0.205 and older.

The flaw allows unauthenticated attackers to log in to the Veeam Recovery Orchestrator web UI with administrative privileges. 

The problem arises from the use of a hardcoded JSON Web Token (JWT) secret, which enables attackers to generate valid JWT tokens for any user, including administrators.

More specifically, the JWT secret creates and validates tokens without any randomness or uniqueness in each installation, making it predictable and static enough to be exploitable.

Veeam's security bulletin suggests upgrading to the patched versions 7.1.0.230 and 7.0.0.379 and also describes the conditions required to exploit the flaw. These conditions include knowing a valid username and role and targeting a user with an active session.

"The attacker must know the exact username and role of an account that has an active VRO UI access token to accomplish the hijack," reads Veeam's bulletin.

However, as Kheirkha showcases in his write-up, some of these requirements can be bypassed with little effort, making this vulnerability more formidable and impactful.

Overcoming requirements

Kheirkha found that determining the role can be easily overcome as there can only be five roles (DRSiteAdmin, DRPlanAuthor, DRPlanOperator, and SiteSetupOperator).

The exploitation script was designed to iterate between these roles when generating JWT tokens until it finds a match.

To find a username to use in the attack, the researcher notes that the SSL certificate, obtained simply by connecting to the target endpoint, typically contains enough clues to derive the domain and potential usernames to use in a token spraying attack.

"The "knowing the username" problem "kind of" can be solved with the following solution: assuming there exists a user named [email protected], one can find the domain name by looking at the CN field of the SSL certificate, and the username can be sprayed," explains the researchers at the Summoning Team.

Finally, concerning the "active session" requirement, Kheirkha's PoC script generates and tests JWT tokens over a range of timestamps to increase the chances of hitting an active session.

A more targeted and stealthy approach would be to investigate user activity times. There's also the 'brute force' approach, which involves continuous attempts until an active session token is matched.

As the exploit for CVE-2024-29855 is now publicly available, attackers will likely try to leverage it against unpatched systems, so applying the available security updates as soon as possible is crucial.