Orca Security discovered four Azure services were vulnerable to server-side request forgery flaws, an attack vector that’s remained prevalent despite the significant threat it poses.
Microsoft’s affected cloud services — Azure API Management, Azure Functions, Azure Machine Learning and Azure Digital Twins — and the dangers of server-side request forgery (SSRF) attacks were detailed in a blog post Tuesday by Orca researcher Lidor Ben Shitrit. Three of the Azure flaws were rated as “Important” severity, while one was rated “Low.” Microsoft fixed all four SSRF vulnerabilities.
Shitrit was able to exploit flaws in Azure Functions and Azure Digital Twins with no authentication required by the services, giving him the ability to send requests without even having an Azure account. Microsoft implemented safeguards in 2020 to prevent SSRF attacks from being catastrophic, such as restricting access to the Azure instance metadata service (IMDS), that prevented Shitrit from reaching any IMDS endpoints.
However, Orca’s research showed attackers could still inflict damage. By exploiting the Azure vulnerabilities, Shitrit could scan local ports, find additional services and endpoints, and target sensitive information that could reveal other vulnerable areas that could be exploited for initial entry points.
“The most notable aspect of these discoveries is arguably the number of SSRF vulnerabilities we were able to find with only minimal effort (including another SSRF vulnerability we found last year in Oracle Cloud Services), indicating just how prevalent they are and the risk they pose in cloud environments,” Shitrit wrote in the blog.
The 2019 Capital One data breach, which began with an SSRF attack against Amazon Web Services, is another example of its risk to cloud environments. Shitrit told TechTarget Editorial the threat remains prevalent because SSRF vulnerabilities can be introduced and abused in a variety of ways such as insecure input validation or misconfigured server-side components.
“In my cases there was a lot of communications between different endpoints, so although they might seem prevalent, they are not easy to detect, and it takes great eyes, great instincts and yes-a bit of luck, to find with who and what my server is communicating and how I can abuse it,” Shitrit said in an email to TechTarget Editorial.
SSRF risks
Shitrit confirmed the four SSRF flaws are cloud vulnerabilities only, and do not affect local software in Azure customer environments. He said the Azure services were misconfigured from the start, which created the conditions for SSRF attacks.
Even though the SSRF flaws found by Orca could be accessed without even an Azure account, the Azure bugs received lower severity ratings. Shitrit attributed that to Microsoft’s countermeasures such as Digital Twins using specific URL prefixes; in the case of Azure Functions, it was almost impossible to reach IMDS.
In the blog post, he warned that accessing IMDS would expose “detailed information on instances, including hostname, security group, MAC address and user-data, allowing attackers to retrieve tokens, move to another host and execute code (RCE).”
“Thanks to various SSRF mitigations that Microsoft put in place, such as environment variable (X-IDENTITIY-HEADER), we did not manage to reach any IMDS endpoints. However, even without the ability to access IMDS services, there was still a lot of potential damage an attacker could achieve,” he wrote in the blog.
Another factor to account for is all four flaws fell under the non-blind or full SSRF category. Essentially, an authenticated threat actor could gain complete communication with the server. Non-blind is one of three main types of SSRF attacks Shitrit highlighted in the blog. It is the only one that allows attackers to receive a full response from the server.
While that can increase the potential damage, Shitrit emphasized how crucial it is for enterprises to properly secure servers and networks to prevent any of the three attack types. “It is important to note that no matter the type of SSRF attack, each SSRF vulnerability can be used to gain unauthorized access to sensitive information or launch further attacks against a target,” Shitrit wrote.
Orca said the key to protecting against these attacks is ensuring that all input is properly validated and that servers are configured to only allow necessary inbound and outbound traffic. Additionally, Orca recommended proper cloud security hygiene, using the principle of least privilege access and patching vulnerabilities to limit attack damage.
Microsoft’s response
Orca reported the flaws in four different Azure services to Microsoft beginning in October. They were all fixed within a month or so after disclosure. Orca applauded Microsoft for its swift response and for implementing measures in 2020 that “significantly reduced the potential damage of SSRF attacks on its Azure platform.”
Addressing cloud vulnerabilities can be complicated even though fixes fall solely on the cloud provider and often require no user interaction. Because of that, cloud vulnerabilities are not assigned CVEs, and providers sometimes choose to silently patch the flaws without publicly disclosing the issues to customers.
Additionally, there have been complaints from security researchers regarding transparency when it comes to the disclosure of cloud vulnerabilities. In June, Tenable accused Microsoft of just that after it reported two Azure Synapse Analytics flaws, which took Microsoft months to fix. Later that month, Wiz launched a cloud database to increase the transparency and document any security issues and fixes for major cloud services.
