This week, we take a look at the recent API vulnerabilities in VMware vCenter and Apache Pulsar, how GraphQL implementations may be vulnerable to cross-site request forgery (CSRF) attacks, an upcoming webinar on API Security and Postman, a DZone webinar with this newsletter’s author next week, and a video onย how the API security vendor landscape looks like.
Vulnerability: VMware vCenter
A recently patched vulnerability in VMware vCenter is now being actively exploited.
The vulnerability in question, CVE-2021-21985, is a critical one: it has a severity level of 9.8 out of 10 and it allows remote code execution (RCE). As mentioned, VMware has already released a patch, but attackers are now actively going after unpatched instances of vCenter.
The root cause lies in the lack of validation of JSON payloads in API calls. Attackers have found a sequence of 6 POST calls where the JSON payloads allow them to take control over the system. All they need is accessing the vCenter system over the network (HTTPS, so port 443.)
The proof of concept code for the exploit is โ unfortunately โ also publicly available, flying this vulnerability off the criticality charts.
If you are a vCenter customer, make sure this vulnerability is patched as quickly as possible. If you are an API provider, make sure you have strict data validation on all JSON payloads.
We have previously covered vulnerabilities in VMware vCenter in our issue 123.
Vulnerability: Apache Pulsar
JSON Web Token (JWT) is one of the popular formats of API security tokens. This is a Base64 encoded JSON structure that contains arbitrary claims (information about the token and the user) and that is signed to prevent token forgery.
Apache Pulsar has recently fixed a JWT alg:none vulnerability (CVE-2021-22160) that allowed account takeovers. Only systems that were configured to accept JWT (just one of the supported authentication schemes in Apache Pulsar) were vulnerable.
The alg:none attacks work as follows:
- Attackers take a valid token and decode it into JSON.
- The attackers manipulate the claims in that JSON, for example, to grant themselves an administrative role, or change their ID to that of another user.
- The attackers replace the original signing algorithm name in the JWT header with
"alg":"none", indicating that no signature algorithm is specified. - The attackers encode the JSON back to a token and include this newly forged token in the bearer header in their API calls.
- If the API implementation is vulnerable, it blindly trusts the incomingย JWT header values, sees that no signature algorithm is specified, and accepts the unsigned, forged token without signature verification.
We have covered JWT, JWT attacks, and the ways to protect against them in several of our previous issues. For example, see the recent webinar recording on JWT attacks and their remediation that we posted in issue 118.
Attack vectors: GraphQL and CSRF
CSRF attacks occur when malicious sites or apps cause a web browser to perform an unwanted action on behalf of an authenticated user. Browser requests automatically include all cookies โ including session cookies โ and the site cannot distinguish between legitimate requests and forged requests.
GraphQL developers rarely consider CSRF but Tomasz Swiadek and Andrea Brancaleoni from Doyensec have found a few scenarios when such vulnerabilities might exist. They provide details on:
-
POST-based CSRF -
GET-based CSRF -
XS-Searchattacks (when attackers can determine the existence of objects based on the speed of the response)
Swiadek and Brancaleoni do promote their open-source GraphQL InQL Burp extension as a tool that can be used to locate such vulnerabilities.
Plus, finally, they give some advice from us on how to prevent CSRF attacks on GraphQL:
- Use modern frameworks with built-in CSRF protection.
- Verify origins.
- Double-submit cookies.
- Base the protection on interaction with the user instead of under-the-hood processes.
- Do not use
GETrequests for state-changing operations. - Make sure
GETrequests, too, are covered by enhanced CSRF protection.
Webinar: API Security in Postman
Postman is a popular API testing tool. Next week, on June 16th, Postman’s Kin Lane and Isabelle Mauny from 42Crunch will be doing a webinar on how one can use 42Crunch API Security technology inside Postman.
See details and register here.
DZone meetup: Latest API Security Vulnerabilities and Q&A
Next Tuesday, DZone is hosting a virtual meetup in which we will go through a few of the recent API vulnerabilities and breaches from this newsletter, and answer any questions that you might have.
This will be live on DZone, Facebook, Twitter, Twitch, and LinkedIn. See you there!
Market overview: API security
As the readers of this newsletter know, API security is a hot market. Companies implementing API security programs have to separate the wheat of the marketing pitches of prospective vendors from the chaff of the reality of what the pushed products actually do.
Security researcher Alissa Knight recently dedicated her webcast to exactly that. See the recording of Alissa’s “API Threat Management Buyers Guide” (fast forward the first 10 minutes to get to the actual start):
https://youtu.be/4X3ni0-4YWA?t=599
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
