Orca, a business that specializes in cloud security, has disclosed information on four server-side request forgery (SSRF) vulnerabilities that affect several Azure services. Two of these vulnerabilities might have been exploited without the need for authentication.
They were able to attack two vulnerabilities without needing any authentication on the service (Azure Functions and Azure Digital Twins). This gave them the ability to make requests in the name of the server even though it did not own an Azure account.
The vulnerabilities in Azure SSRF that were discovered allowed an attacker to scan local ports, find new services, endpoints, and files. This provided valuable information on potentially vulnerable servers and services to exploit for initial entry, as well as the location of information that could be targeted.
SSRF vulnerabilities are particularly dangerous due to the fact that if attackers are able to access the host’s IMDS (Cloud Instance Metadata Service), this exposes detailed information on instances. This information includes the hostname, security group, MAC address, and user-data, and it could potentially allow attackers to retrieve tokens, move to another host, and execute code (RCE).
A server-side request forgery, also known as SSRF, is a web security vulnerability that enables an attacker to abuse a server-side application by making requests to read or update internal resources as well as submit data to external sources. This type of vulnerability is known as a server-side request forgery.
Server-Side Request Forgery (SSRF) attacks often fall into one of these three categories:
Blind SSRF is a sort of SSRF attack that takes place when an attacker is able to influence a server to make requests, but the attacker does not get the answer that the server sends back to them. Because of this, determining whether or not the attack was effective is much more difficult.
Semi-Blind SSRF is a form of SSRF attack that is very similar to Blind SSRF. The only difference is that the attacker is able to view part of the answer from the server, such as the response headers or the status code. This may provide the attacker the ability to obtain some limited information about the system they are attacking.
Non-Blind SSRF, also known as Full SSRF, is a subtype of SSRF attack that takes place when an attacker has the ability to control a server in order to send requests and get the whole answer from the server. This gives the attacker the ability to learn more about the system they are targeting and gives them the opportunity to perhaps conduct other attacks.
The four SSRF vulnerabilities that we found all fall into the third category, which is known as Full SSRF (sometimes referred to as Non-blind SSRF). To give you an idea of how easily these vulnerabilities can be exploited, Non-blind SSRF flaws can be leveraged in a variety of different ways, such as SSRF via XXE, SSRF via SVG file, SSRF via Proxy, SSRF via PDF Rendering, SSRF via vulnerable query string in the URL, and many more. These are just some of the ways that these vulnerabilities can be exploited.
It is essential to keep in mind that each and every SSRF vulnerability may be exploited to get unauthorized access to sensitive information or to launch further attacks against a target. This is the case regardless of the kind of SSRF attack that is being deployed. For this reason, it is essential for businesses to take the necessary precautions to protect their servers and networks against the kinds of attacks described above.
They were not successful in gaining access to any of the IMDS endpoints because Microsoft had implemented a variety of SSRF defenses, one of which was the environment variable known as X-IDENTITY-HEADER. However, even in the event that an attacker was unable to access the IMDS services, there was still a significant amount of potential harm that they might do, as was previously discussed.
After bringing Microsoft’s attention to the security flaws, the company moved quickly to fix them.
Cyber Security Specialist with 18+ years of industry experience . Worked on the projects with AT&T, Citrix, Google, Conexant, IPolicy Networks (Tech Mahindra) and HFCL. Constantly keeping world update on the happening in Cyber Security Area.
