Issue 105: API vulnerabilities in HashiCorp, Azure App Services, and Qiui adult devices

Felix Wilhelm from Google’s Project Zero has written a very detailed write-up on an authentication bypass he found in the Amazon Web Services (AWS) and Google Cloud Platform (GCP) integration of HashiCorp Vault. As a central storage of credentials, Vault makes an attractive target for attackers, and therefore a vulnerability in it is also very bad news. Looking for the silver linings, this attack was definitely quite advanced, and thus not easily exploitable.

In both cases, the attack effectively boiled down to forging JSON Web Tokens (JWT) that satisfied the parameters expected by Vault:

• For AWS, attackers could set up a minimal OpenId Connect identity provider, use that to sign a specifically crafted JWT, and send the request to the authentication service in AWS. The way Go XML decoder would parse the  response from AWS would mislead Vault to consider authentication successful.
• With GCP, attackers would have to successfully impersonates a GCE instance with right configuration.

In both cases, the end result would be the same: attackers get a valid session token, enabling them get access to secrets stored in the Vault server

As is evident from Wilhelm’s write-up, this exploit was not clear-cute, self-evident, or easy to find, so it may be unlikely that they have been exploited. According to Wilhelm:

“In the end, Hashicorp fixed the vulnerability by enforcing an allowlist of HTTP headers, restricting requests to the GetCallerIdentity action and stronger validation of the STS response.”

Positive security, allowlists, and locked-down implementations in your APIs are still the best way to minimize your attack surface. Security and especially security integrations can be riddled with pitfalls, so making sure your APIs are in good shape adds an important layer to the security.

Paul Litvak found API vulnerabilities in Azure App Services: the APIs of KuduLite, the app service administration component for Linux lacked access checks.

KuduLite is hosted on the manager node of the service, while the application is hosted on a separate application node. The application node could send requests to the KuduLite API without any access validation. Thus, anyone taking control over an app service in Azure (for example, with a Server Side Request Forgery (SSRF) attack) could get file system access via a GET call to the KuduLite VFS API:

or even remote code execution capabilities by doing a POST call to the KuduLite Command API:

This is another example on how important it is to apply correct authentication and authorization checks even to API calls within the system. Microsoft has since fixed the vulnerability.

This API vulnerability generated quite a lot of click-bait headlines and broke even to the mainstream media: Pen Test Partners found the APIs behind the Qiui CellMate “male chastity” devices that allow remote control to partners to be highly vulnerable.

The API allowed attackers to locate user records by supplying a 6-digit invitation code — something they could easily enumerate. This gave full access to the user records and all its details, allowed to retrieve all user information, including geographic location, and allowed taking over the devices and locking them in a way that prevented the users from unlocking them. Perfect material for further phishing or blackmail campaigns, and a full-blown nightmare for users.

Details are still scant because, although the vendor released version 2 of the API with some security fixes, they have still left the version 1 in use, continuing to expose the vulnerabilities. There is no indication that the vendor plans to fully fix the issue.

On a consumer-level this is yet another example that physical security needs to be considered any time smart devices are bought, especially from vendors lacking good security reputation.

On the vendor side, the key lessons learned would be:

• OWASP API2 Broken Authentication can apply to a variety of APIs. Not just your main /login path but also various password reset and invitation flows.
• Any codes need to have short expiration periods and measures need to be taken to prevent enumeration and brute-force attacks on them (longer, more complex codes, rate limiting, and so on)
• Be careful of leaving insecure earlier versions of APIs online. This exposes you to the OWASP API9 Improper Assets Management vulnerability.
• And be responsive to security researchers!

There’s a new educational API security video from Katie Paxton-Fear.

This time she is covering the basics of finding information disclosure flaws in JSON and XML responses. Worth checking out if you are starting with APIs and API security:

OWASP API Security Top 10 vulnerabilities can be addressed on different stages of API life cycle with different tools: static analysis during development, dynamic testing as part of the QA and release, and runtime protection during the operation.

42Crunch has posted a matrix of how their solution protects APIs against the vulnerabilities at each stage.

Next Wednesday, October 21, Isabelle Mauny is also doing a webinar on that same topic: practical approach of addressing each of the OWASP API Security Top 10 vulnerabilities. She will explain the steps needed for each of them during design, development, as well as testing and runtime. Click on the link and register to reserve your spot.