This Cloud is on Fire! Microsoft Azure Site Recovery EoP
Discovering and Exploiting CVE-2024β21364
Adversary Academy recently completed a long-term red team (assume breach) assessment for a large restaurant franchise. While performing the assessment an Azure Site Recovery server was found to be an attractive target in the environment. Part of our service offering is our targeted vulnerability research (TVR) program. The challenge Iβve seen with most pentest or redteam providers is that there is typically a lack of vulnerability and exploit research capabilities. Meaning if there are not known vulnerabilities with public exploit code affecting a network or environment the pentest provider can't find exploitable systems. Pentest providers typically lack full-time exploit and vulnerability development capabilities. In order to address that issue we run a program that allows our researchers to spend time attacking interesting systems theyβve encountered on customer networks, long after the engagement is overβ¦ or in this case during an engagement.
Typically on a penetration test a tester's βspidey sensesβ will go off at some point when you encounter a system that just feels vulnerable, or impactful if it were to be vulnerable. Our spidey senses went off when we gained access to an Azure Site Recovery (ASR) server because there appeared to be a large number of services communicating both inbound and outbound to the server as well as traffic to the customer's Azure environment. Documentation revealed that when fully deployed ASR has rights to read and write virtual machines from on-site VMware or Hyper-v systems and upload them to the Azure cloud for cloud-to-cloud disaster recovery.
While performing the engagement the research phase began immediately and we discovered a number of interesting bugs on the SRM server after we gained access toΒ it.
Beginning our research we found that Azure SRM is site disaster recovery for one Azure region to another region or physical to theΒ cloud.
SRM can replicate on-premises hypervisors VMware, Hyper-V, physical servers (Windows and Linux), or Azure Stacks to AzureΒ sites.
Basically, Microsoft said, βWe will support anything other than AWS orΒ GCP!β
As we started our research we found roughly 20 previous CVEs affecting Microsoft Azure SRM, most were EoP and most were found in 2022. Hopefully, we could find something new.
Our research mindset typically includes mapping out application behaviors and what could go wrong with misconfigurations, logic flaws, or historically problematic issues (in this caseΒ EoP).
We started by reviewing features, capabilities, and processes in Azure SRM and foundΒ that:
- the SRM process and config server runs a web server listening for replication events to the backup server on portΒ 9443
- Process server must have permission to read all properties from all systems being backedΒ up
- Process server must have the ability to read/write to Azure for synchronization, and deployment ofΒ agent
- SRM server connects to clients via WMI/ credentials stored in theΒ DB
- This WMI connection deploys the SRM mobility agent responsible for the agent to serverΒ comms.
Once this behavior was documented we decided that the web server privileges might be important, and the WMI credentials stored in the local database were definitely valuable targets to begin attacking.
Reviewing files accessed on startup by the services showed us that a config file named amethyst is read on startup. Here was the first bug weΒ found.
The amethyst config file contains the plaintext mysql DB root username and password, this allows us to interact with the local database asΒ root.
Connecting to the mysql database we began to debug and monitor the mysql queries that were executed by the server. Here we found our attackΒ target.
We found php code responsible for executing the query that decrypts and uses the credentials we want access to. The first roadblock encountered is that we are not able to read the Encryption.key file as a standardΒ user.
After some research and failed attempts, we found a Solution!
If the process responsible for handling the php / mysql queries has access to the key, we must become theΒ process.
As our standard user account on the server, we donβt have the SeImpersonatePrivilege, we don't have an admin account on the server either. So we needed to find a bug affecting the webΒ server.
Further research allowed us to find a directory on the server where the web server / php code isnβt properly secured. We can write a webshell to this directory and βbecomeβ the web serverΒ process.
- The web services are running as IUSR which DOES have the SeImpersonatePrivilege
We then can use SEImpersonatePrivilege to read the encryption.key
The final challenge was overcoming some weird character-handling behavior by MySQL which can't handle the characters in the encryption.key inline, so store it as a variable to use the key and decrypt the admin credentials.
After discovering the bugs and disclosing the credentials used by SRM the team was able to access the Vsphere environment, took snapshots of the domain controllers, and performed offline attacks to recover Enterprise and Domain admin access. After exploiting the issues we reported the vulnerability to Microsoft and received recognition for CVE-2024β21364 with a patch becoming available several monthsΒ later.