Issue 123: API vulnerabilities VMWare vCenter and Facebook, mismatch between JSON parsers, API security fixes in VS Code

This week, we learn about the recent serious API vulnerability in VMware vCenter (if you have one, update ASAP!), why query and path parameters cannot be trusted for confidential data, how potential attacks can emerge from inconsistencies in JSON parser behavior, and how a VS Code extension can help fix API vulnerabilities.

Vulnerability: VMware vCenter

VMware vCenter and its sub-component vSphere let businesses virtualize and control their corporate infrastructure, thus is often located on internal networks. Any vulnerability there is thus a serious concern.

Mikhail Klyuchnikov from PT SWARM found a critical remote code execution (RCE) vulnerability in VMware vCenter (CVE-2021-21972).  In a nutshell:

1. One of the plugins enabled by default in vCenter allowed unauthorized users to access any URL it handled.
2. One of its paths included a POST operation to upload a .tar file
3. The implementation of the operation unpacked the .tar archive, iterated over the files in the archive, and created the files on the server by simply concatenating the folder path with the filename.
4. Creating filenames with ../ allowed Klyuchnikov to escape the plugin folder and upload arbitrary files to arbitrary folders on the server.
5. Klyuchnikov then just had to figure out the places where he could put his scripts to have them later executed by vCenter.

It’s worth noting that Linux was as vulnerable here as Windows pictured above.

Lessons learned with this one:

• Endpoints not covered by authentication are extremely dangerous and need to be avoided.
• Plugins expand your attack surface, especially if they expose APIs.
• You cannot trust any API caller, so strictly define all inputs and validate the data that you get.

Vulnerability: Facebook’s cache server

URLs of API calls (and thus path and query parameters in them) should not be used to pass any confidential data. They are visible to proxy servers, web browsers, browser extensions, and so on. They may also be stored in logs that these write. Thus, the confidential data might get stored who knows where outside your control.

Youssef Sammouda found a way to exploit that vulnerability at Facebook by exploiting their cache server. The cache endpoint allowed to check whether a specific URL was present in the cache. Sammouda could then just enumerate URLs by appending characters one by one to find the ones that existed.

Some of the data that could be thus exposed included, for example:

• Internal endpoints at Facebook
• Internal files
• JavaScript files
• Endpoints leaking access tokens and passwords in GET requests
• Other information about users or employees in URLs

The vulnerability has luckily since been fixed.

Do pay special attention to what kind of information gets included in query and path parameters. You never know where those could pop up, allowing attackers to find out much more details on your system that you might be comfortable with.

Attack vectors: JSON parsers

Modern REST APIs typically accept and exchange JSON payloads. Can this universal language that your product components are using to communicate with each other become an attack vector of its own? Jake Miller has found out that indeed it can.

The vulnerability lies in the ambiguity of the JSON standard itself and how it leaves some definitions open-ended or ambiguous. When a standard does not impose a strict implementation, it leaves room for interpretation and variation. In the context of a single JSON parser, these could be shrugged off as hardly significant quirks, but the picture changes when you have more than one JSON parser at play.

This is not at all an unlikely scenario in microservices-based systems. When your microservices are implemented in different stacks, they may end up using different JSON parsers. This in turn can lead to discrepancies in input and output values from different parts of the architecture, with unforeseen consequences. Attackers can exploit this by constructing a JSON payload that lets them benefit from these inconsistencies.

Miller’s post is thorough, illustrative, and completely fascinating, so do go and check it out. As a teaser, here are the main categories of identified discrepancies:

• Inconsistent duplicate key precedence:

  obj = {"test": 1, "test": 2}

  Imagine an online shop in which the shipping service API might read one quantity from a request payload, and the billing service another, much lower one.

• Key collision in character truncation and comments:
  problems in character interpretation:

  {"test": 1, "test\[raw \x0d byte]": 2} 
  {"test": 1, "test���": 2}
  {"test": 1, "test"": 2}
  {"test": 1, "te\st": 2}
  

  problems with comments:

  obj = {"description": "Duplicate with comments", "test": 2, "extra": /*, "test": 1, "extra2": */}

  Imagine an API call getting an admin role because the request had a role name that one service interpreted as a permissible custom role name (because it had some extra characters in the role name), while other services as a built-in admin role.

• JSON Serialization Quirks: For example, duplicate keys getting removed (or not) or reordered when an object is deserialized and serialized back. This can have exploit scenarios similar to the key precedence one mentioned earlier.
• Float and integer representation: Different JSON parsers may interpret a large number like 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 completely differently, like:

  999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
  9.999999999999999e95
  1E+96
  0
  9223372036854775807

  Or they might use different values as infinity representation.

• Permissive parsing and other bugs: For example, how different JSON parsers handle trailing garbage or malformed JSON.

See the full article for more details on the included JSON parsers.

It goes without saying that it is of utmost importance to ensure that the parsers you use have consistent behavior, or externalize your data validation. Or better yet, both.

Tools: Security fixes in the VS Code OpenAPI extension

VS Code OpenAPI (Swagger) Editor extension is a popular extension by 42Crunch, with more than 140 thousand active installs and many 5-star reviews.

Besides offering editing, navigating, and previewing your OpenAPI files in the IDE, it includes API Contract Security Audit as a built-in feature. This produces an audit report that helps developers identify potential security issues in the API contract they are working on already during the design time.

The latest version of the plugin takes this a step further and makes fixing the identified security issues quicker, with just a few easy clicks:

---

Get API Security news directly in your Inbox.

By clicking Subscribe you agree to our Data Policy

---