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.
