Microsoft recently patched three vulnerabilities in its Azure API Management service, two of which allowed server request forgery (SSRF) attacks that could have allowed hackers to access internal Azure assets. Proof-of-concept exploits serve to highlight common mistakes that developers might make when trying to implement blacklist-based restrictions for their own APIs and services.
Web APIs have become an integral part of modern application development, especially in the cloud. They allow services to communicate and exchange data, for non-browser clients such as mobile apps and IoT devices to securely access data and perform operations on behalf of users, and for businesses to abstract backends from older servers and quickly interconnect them with modern applications and services. APIs are standardized and easy to interact with instead of relying on custom, legacy protocols that weren’t built for the web.
With companies pushing APIs into production at a rapid pace in recent years, the number of attacks targeting them has increased as attackers increasingly realize that insecure APIs can provide a backdoor to databases and internal infrastructure. According to global content delivery network provider Akamai, the number of attacks targeting APIs and web applications grew 2.5 times in 2022 compared to 2021. One of the emerging attack vectors in the past two years has been SSRF. The ProxyLogon, ProxyNotShell, and OWASSRF flaws in Microsoft Exchange servers are notable examples that have seen massive exploitation.
Over the past two years, Akamai has seen a steady increase in both attack attempts and authorized vulnerability scan traffic looking for SSRF vulnerabilities in software other than Microsoft Exchange,” Akamai said in a recent report. “Also, we saw a newspaper. an average of 14 million SSRF attempts to probe the web applications and APIs of our App & API Protector customers, suggesting the growing prevalence of this vector. This growth and the potential impact that exploiting SSRF has on organizations is worth noting.”
SSRF via Azure API Management proxies
Microsoft’s Azure API Management is a service that allows companies to expose and monitor services hosted in Azure or within their private networks as APIs. It is a service aimed at API developers consisting of an API gateway, a management plan and a developer portal.
In an SSRF attack, the attacker must find a way to use the application’s proxy functionality to access internal resources, taking the server’s privileged position and accessing the internal network. In other words, if an application or API allows users to provide a URL and then crawl that URL and return the response, an SSRF attack is possible if additional security measures are not taken.
Azure API Management has this feature. Allows users to specify a schema for the structure of the JSON or XML data expected to be exchanged through the API they deploy. However, according to researchers at security firm Ermetic, the service can also be asked to determine the schema automatically by making a request to a user-supplied URL, this feature is called “Import from the URL”. “Once you’ve specified the schema URL, the Azure API Management CORS proxy retrieves the schema from the specified URL by sending an HTTP request to it,” the researchers said in their report.
Cross-Origin Resource Sharing (CORS) is an HTTP header-based mechanism that allows a web server to indicate to browsers other origins (servers) from which it is allowed to load resources such as scripts. In this case, the CORS proxy intercepts the requests and modifies the CORS headers to ensure that cross-domain requests between portal.azure.com and other servers are allowed.
After finding this feature, Ermetic researchers thought of providing http://localhost or http://127.0.1.1 (the loopback address) as the remote URL to get a scheme to see if the CORS proxy it would be addressed internally to the server itself, achieving SSRF. This resulted in an HTTP 403 (Forbidden) error, suggesting that there was a blacklist.
The researchers then registered a domain called localhost.me and then edited its DNS records to point to 127.0.1.1. So when the CORS proxy tried to access http://localhost.me, it would first resolve DNS and try to access the returned IP address, which points to itself without going through the blacklist. This worked. The response reflected by the CORS proxy was the HTTP error 404 (page not found), meaning that the server no longer rejected the request but did not have a page to serve.
The researchers also found that they could add custom headers to their requests and have the CORS proxy forward them to the target server, opening the door to even more complex attacks. They then tried accessing the internal server on different port numbers, not the default 80 to investigate if other services might be running on custom ports and noticed that when they tried port numbers that included “300” such as 300 , 3000 or 30000. , they got the 403 Forbidden error again.
“We understood that if a regular expression [regular expression] exists specifically for these ports, some important services must listen on these ports,” the researchers said.
A regular expression is a search and match rule that can be used to create blacklists. For example, the rule could match any URL that includes the term localhost and a port number starting from 300 in the request. The researchers inferred that if a regular expression exists, it must be applied to a value called “Ocp-Apim-Url” in the request headers that defines the URL reached by the CORS proxy. So they used a URL to a domain they controlled which then proxyed to http://localhost:30001 for example.
This worked and bypassed the blacklist once again, allowing researchers to discover and access internal services on different port numbers: 30001 – Authenticated Developer Portal View, 30004 – Azure Management API, 30005 – Management of the Azure Kudu API, 30006 – Unpublished (unauthenticated) developer site. Kudu is the engine that powers some management functions of Azure App Service, a service for hosting and deploying web applications on Azure.
SSRF vulnerabilities reveal blacklist weaknesses as a defense
This SSRF vulnerability through the CORS proxy is similar to the one Orca Security researchers found in the same service in November. Ermetic reported his findings to Microsoft in December and thought it might be the same vulnerability. However, his exploit bypassed the fixes Microsoft put in place after Orca reported the original flaw, making it a separate vulnerability. This highlights the difficulties of relying on blacklisting techniques such as regex as a defense mechanism for these types of functions, as there are always multiple ways to avoid them.
The Ermetic researchers didn’t stop their analysis there and found a second SSRF, this time in the Azure API Management Hosting Proxy, a different proxy used to dynamically configure the URL of the backend service an API when creating it.
“When a request is sent from the interface that the user specifies, the request will be sent to the input processing proxy and then to the specified backend,” the researchers said. In the process, the proxy will make modifications to the request based on user-defined policies for inbound and outbound processing.
The researchers found that a user could configure the set-backend-service policy to point to http://localhost instead of their actual API backend service URL, thus tricking the proxy to direct requests received from the API interface to itself.
“Since we had control over the interface and input processing policies, we could send the SSRF with an HTTP verb/method and custom headers of our choice,” they said. “We were able to access an internal HTTP port 80 for a POC [proof-of-concept].”
For both vulnerabilities, researchers halted their research to avoid damaging internal services and infrastructure or risking access to sensitive data using SSRF testing that would normally require authentication.
Path Traversal Vulnerability in API Management Developer Portal
Finally, the researchers were also able to find an unrestricted file upload feature in the API Management Developer Portal that resulted in the path traversal. This had the potential to affect self-hosted API management developer portals deployed by end users as well as their own infrastructure.
“We found that Azure does not validate the file type and path of uploaded files,” the researchers said. “Authenticated users can traverse the specified path when uploading the files, upload malicious files to the developer portal server, and possibly execute code there via DLL hijacking, iisnode configuration sharing, or any other relevant attack vector” .
Copyright © 2023 IDG Communications, Inc.
Source link
Azure API Management is a cloud-based service that provides a layer of security and management around Azure Application Program Interfaces (APIs). However, a recent security flaw has exposed server-side request forgery (SSRF) risks in developing APIs on Azure.
To understand what the flaw is and the impact, it is important to understand the fundamentals of request forgery. All web requests sent from clients to a web applications are often sent through a round-trip process. The request is sent from the client to the server, and the response is sent back from the server. If a malicious user is able to intercept the request and fabricate a malicious request before it reaches the server, then the server can unwittingly carry out the request as if it had originated from a legitimate request.
The SSRF flaw, detailed by security researcher Benoit Ancel, means malicious users can access critical infrastructures within a company’s network, such as databases, cloud service accounts and other internal networks.
Azure API Management specifically, allows the developer to secure an API operation by specifying which caller IP Addresses are allowed or not allowed. However, malicious users are able to bypass these filters by providing an IP address that the server interprets as a request to exfiltrate data via an SSRF attack.
At Ikaroa, we provide a holistic approach to endpoint security, including auditing for potential vulnerabilities related to request forgery, as well as other security risks. We strongly recommend that businesses using Azure API Management double-check their security settings and patch their systems if necessary. As request forgery, if not properly prevented, can have a damaging effect on the availability of a company’s data, it is paramount that vulnerabilities are addressed sooner rather than later.
Working with a team of experienced specialists can help companies identify and patch such vulnerabilities, ensuring that their data remains secure. As an experienced cloud security provider, we are committed to helping our customers stay safe and secure in an ever-changing landscape.
