Issue 98: APIs as the next frontier in cybercrime

Another mandatory COVID-19 tracing app,  was found to leak personal information and health status of users. This time it was Aura, an app that Albion College in Michigan has made mandatory for all students.

Among other issues, such as hard-coded secret keys to the backend server, the app also had an API that allowed to enumerate account numbers. For a given account, one could get the COVID status of a student, the date of testing, and the student’s full name.

Lessons to be learned from this case are familiar:

• Never allow any sort of account enumeration in your APIs.
• Prevent IDOR/BOLA attacks by enforcing authorization and letting each account to access their own data only.

We have previously covered API vulnerabilities in various coronavirus tracing apps in our issues 83 and 86.

Do not think that localhost calls are automatically safe. Attacks are often stacked and hackers can expand their attacks once they have passed the initial defense. If there is a vulnerable local proxy on a system that automatically trusts it, attackers can use it for their malicious activity.

Unit42 researchers found a serious vulnerability in some Kubernetes deployments: the CVE-2020-8558 in Kubernetes kube-proxy combined with the insecure-port enabled on an  api-server allowed attackers to gain full control over Kubernetes clusters:

A security issue assigned CVE-2020-8558 was recently discovered in the kube-proxy, a networking component running on Kubernetes nodes. The issue exposed internal services of Kubernetes nodes, often run without authentication. On certain Kubernetes deployments, this could have exposed the api-server, allowing an unauthenticated attacker to gain complete control over the cluster. An attacker with this sort of access could steal information, deploy crypto miners or remove existing services altogether.

The vulnerability exposed nodes’ localhost services – services meant to be accessible only from the node itself – to hosts on the local network and to pods running on the node. Localhost bound services expect that only trusted, local processes can interact with them, and thus often serve requests without authentication. If your nodes run localhost services without enforcing authentication, you are affected.

The issue details were made public on April 18, 2020, and a patch released on June 1, 2020. We worked to assess additional impact to Kubernetes clusters and found that some Kubernetes installations don’t disable the api-server insecure-port, which is normally only accessible from within the master node. Exploiting CVE-2020-8558, attackers can gain access to the insecure-port and gain full control over the cluster.

Jason Kent published a write-up on why APIs are an easy target for criminals. He lists the following API vulnerability factors and the ways to mitigate them:

1. APIs too easy to discover:
   • Only share APIs with those authorized.
   • Use certificate pinning.
   • Obfuscate and control API requests.
2. APIs too verbose:
   • Don’t leak information in error responses, like whether or not an account exists in the system.
3. API objects with too many parameters / properties:
   • Limit the properties that APIs return to the bare minimum needed.
4. APIs have too much data:
   • Don’t store the data that you don’t need.
   • Don’t allow anonymous access to data.
   • Don’t expose any data related to the internal workings of applications or infrastructure.
5. APIs not designed for security
   • Review the security architecture of your applications.

DEF CON AppSec Village has published a session recording by two of the OWASP API Security Top 10 team members, David Sopas and Paulo Silva. In their presentation, they provide examples of the following attacks:

• Broken user authentication
• Broken object level authorization
• Broken function level authorization
• Excessive data exposure
• Security misconfiguration
• Injection