This week, we take a look at the recent API vulnerabilities in smart prayer beads, Kubernetes, and Harbor, as well as analogies between API security and airport security.
Vulnerability: ClickToPray eRosary
Vatican has released ClickToPray eRosary, the smart rosary beads that โ naturally โ come with the accompanying mobile app. Unfortunately, the app had a couple of API vulnerabilities that allow full account takeover.
Alongside login with Google or Facebook account, the third login option the app developers chose was just to ask for the email address of the user and send a 4-digit PIN to the supplied address. The user could then log in to the app with the received PIN code. However, the API powering the email login had two flaws:
- The first one could be classified as OWASP API3: Excessive Data Exposure. The
POSTrequest to submit the email address to request the PIN actually included the generated PIN code in the API response:Sample request:
Sample response:
This meant that attackers didn’t need to access the victim’s mailbox to get their hands on the PIN. They could simply make thePOSTcall with the victim’s email address, retrieve the PIN from the API response, and log in to the app with it. - The second vulnerability was API4: Lack of Resources and Rate Limiting.While the mobile app did not allow more than one login attempt in every 60 seconds, the API did not have any limitation. A simple script iterating over all possible 4-digit PIN numbers would allow attackers simply to brute-force their way in.
Vulnerability: Kubernetes
We talked about the “billion laughs” attack against Kubermetes API Server just a couple weeks ago. The latest patch releases for Kubernetes include a fix for another API vulnerability.
This time, the vulnerability affects configurations where Kubernetes API Server is behind an authentication proxy. If the proxy and Kubernetes had different ways of treating HTTP headers, attackers could authenticate as any user using an invalid header.
According to the RFC, HTTP headers should not have a space between the header name and the colon after it. However, the Go library that Kubernetes API Server used did not follow the RFC and accepted such headers.
Attackers could exploit this vulnerabilities with the following scenario:
- An attacker wants to get authenticated as Bob but does not have Bob’s credentials.
- The attacker sends a request with the HTTP header
X-Remote-User : Bob(this field is used to identify the user). Note the space in front of the colon. - Some authentication proxies only enforce blacklist rules for specific headers. For them,
X-Remote-User :(with space) is not the same asX-Remote-User:(without space). Thus, instead of stripping the header out, they let it through to Kubernetes. - Kubernetes accepts the call and interprets it as an authenticated request from Bob.
Vulnerability: Harbor
A critical API vulnerability was found in the popular container registry software, Harbor. Their internal team has flagged an issue with broken access control.
Details are a little scarce, but from what we know, it looks like an authorization issue. Project administrators of one project could use the Harbor APIย and create a robot account with unauthorized push and pull access permissions to another project for which they had no access to or control over.
This is a second API vulnerability at Harbor in the last few weeks. Back in September we covered a Mass Assignment flaw in Harbor self-registration API.
Opinion: API Security & Airport Security
Nial Darbey has posted an article in which he explores the analogy of API security and airport security. He covers the following API security best practices:
- Distributed authentication
- Authorization
- Minimal scope
- API decomposition
- Behavior monitoring and anomaly detection
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
