Issue 137: Vulnerabilities in VMware vCenter and Apache Pulsar, GraphQL and CSRF attacks

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.

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:

1. Attackers take a valid token and decode it into JSON.
2. 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.
3. The attackers replace the original signing algorithm name in the JWT header with "alg":"none", indicating that no signature algorithm is specified.
4. The attackers encode the JSON back to a token and include this newly forged token in the bearer header in their API calls.
5. 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.

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-Search attacks (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 GET requests for state-changing operations.
• Make sure GET requests, too, are covered by enhanced CSRF protection.

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.

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!

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):