Issue 128: API flaws at VMware and GitLab, URL parameters and SSRF, webinar on recent breaches 🎬

VMware has just patched two critical security issues in their vRealize Operations API.  The patched vulnerabilities are CVE-2021-21975 and CVE-2021-21983, and affect the products Cloud Foundation and vRealize Suite Lifecycle Manager.

As it often happens with vendor patch announcements, details are scant. Hopefully, after the embargo period is over, the researcher who reported the issues (Egor Dimitrenko from Positive Technologies) will publish a detailed write-up on how he came upon them.

For now, all we have are these quotes from the VMware patch announcement:

• The vRealize Operations Manager API contains a Server Side Request Forgery. A malicious actor with network access to the vRealize Operations Manager API can perform a Server Side Request Forgery attack to steal administrative credentials.
• The vRealize Operations Manager API contains an arbitrary file write vulnerability. An authenticated malicious actor with network access to the vRealize Operations Manager API can write files to arbitrary locations on the underlying photon operating system.

Neither sounds very palatable, so if you are affected by these vulnerabilities, do go and install the patch as soon as possible.

And if you are on the API provider side, make sure to define and enforce strict patterns for URL parameters and enforce paths for all REST API calls.

Muthu Prakash found a vulnerability related to user permissions in GitLab. In private GitLab projects, users demoted to the Guest role lost their access to merge requests on the GitLab UI (as expected.) However, they could still get to the merge requests through APIs. GitLab has since fixed the issue.

This is an example of what happens when access to data and functionality is controlled by the UI. If (when) attackers go directly against the APIs behind the UI, they can simply bypass the UI limitations. They can find the required endpoints and parameters simply by proxying the calls while using a more powerful user account.

SSRF vulnerabilities (that already made their entrance here in the VMware case a few paragraphs up!) happen when attackers make API or web app servers invoke malicious HTTP requests that they supplied.

SSRF attacks can be very dangerous because the servers are within the API provider’s infrastructure and often run under powerful accounts. Calls from the server may be considered internal and could bypass a lot of security checks.

A researcher called secureITmania has written a nice case study on an SSRF vulnerability found in an undisclosed API for PDF generation. A quick recap:

1. The API accepted a URL as a parameter. Such APIs are often vulnerable to SSRF: https://www.example.com/api/v03/create_pdf?url=http://testsite.com&cookies=a&server=web
2. Replacing the URL with a Burp Collaborator link allowed the researcher to observe how the API backend interacted with the url parameter: https://www.example.com/api/v03/create_pdf?url=http://<burp-collaborator-link>&cookies=a&server=web
3. Adding the command `whoami` to the url parameter provided results showing that the command was indeed executed, indicating the vulnerability:
   
4. The researcher then managed to send in cat /etc/passwd request, thus extracting sensitive account information and proving the vulnerability:
   

This shows well how dangerous URL parameters are. Make sure you provide strict pattern definitions for them in your API definition and enforce the defined patterns before the value ends up in the backend for processing.

In this newsletter, we typically have a couple of API vulnerabilities every week, give a quick overview, and link it to the original story.

Next week, we will be trying out a new format: a webinar that goes into the details of a few of such vulnerabilities.

Next Thursday, April 15, at 8 am PST, yours truly (Dmitry Sotnikov) will be presenting a webinar: “Dissecting the Biggest API Breaches from Q1 2021“.

I will take a few of the illustrative API vulnerabilities from the first quarter of the current year and dig deeper into the details of them:

• The story behind the attack or vulnerability
• Potential or actual business impact
• What went wrong?
• The OWASP API Security classification
• What could have been done to prevent the attack?
• Relevant technology that could have helped
• Answers to questions from the audience

If this format proves successful, we plan to start hosting similar webinars regularly. Register here to reserve your spot, join the webinar, and do provide us feedback.