Issue 87: Vulnerabilities in Digilocker, Facebook, VMware Cloud Director 🌩️

A critical API vulnerability in India’s digital wallet system, Digilocker, exposed personal documents of more than 38 million citizens. This app lets you store your key documents, such as driver’s license and national identity card, in digital format instead of carrying the physical documents with you. Ashish Gahlot and Mohesh Mohan have both reported this issue independently of one another.

Both the mobile and the web app of Digilocker use APIs to communicate with the backend. As it often happens with REST APIs, one can find a vulnerability by invoking them in a different sequence  than the intended one.

To protect access, the system was meant to send a one-time password (OTP) to the phone number associated with the record and require users to provide their 6-digit personal identification number (PIN). However, Mohan and Gahlot could break into the system by first completing the OTP and logging in with a valid account, but then calling POST /signup/set_pin for a different account. The backend did not verify that the identities match and allowed to reset the PIN and access the documents of the other user.

The vulnerability was swiftly fixed after it was reported. Lessons learned here:

• Do not rely on your web or mobile UI as the security edge and the surface to enforce scenarios. Attackers will invoke your APIs directly in any sequence they want.
• Authorization is key. You cannot trust the parameters of API calls.
• Any OTP, PIN, or password reset API calls should be treated as high security, at the level of scrutiny that you would apply to authentication.

You can read more about BOLA/IDOR vulnerabilities in the API1:2019 — Broken object level authorization API security encyclopedia article.

Facebook has fixed a broken object level authorization (BOLA, also known as IDOR) API vulnerability that Pouya Darabi reported.  The vulnerability allowed attackers to delete any image from any user’s profile.

The culprit here was the recently added Series feature in Facebook for Business (not in the common Facebook) that lets you group your images and videos together. If you delete your Series, all content in it is also deleted from Facebook.

On Facebook Creator Studio UI, you can only add content that you own in your Series. However, if you bypassed the UI and called the API behind it directly, you could add images that belonged to other users simply by supplying the object ID of the image as a parameter in the API call.

Thus, to delete someone else’s images, attackers only had to make an API call to add the image to their Series and then delete the Series.

Although at first the case looks very different from the Digilocker above, the similarities in the lessons here are obvious:

• Do not trust the UI to enforce security, attackers just bypass it and go directly for your APIs.
• You cannot trust any ID parameters supplied in API calls. Or any parameters, for that matter.
• Authorization needs to be checked on all calls.
• Even non-sensitive calls need to be handled with caution because they might become part of scenario that has sensitive operations down the line. Expect there will be human error down the line as your API continues to be developed, and plan for it in advance.

This is not the first time Facebook has API vulnerabilities related to photos. We have covered a previous case, for example, in our issue 46.

VMware has just fixed a code injection vulnerability in their Cloud Director product that allowed unauthorized administrative access.

Researchers from Citadelo experimented with trying different values for different parameters. They noticed that when they supplied ${7*7} as the SMTP server name (obviously not a valid name for a server), the received error response said: String value has invalid format, value: [49].

The fact that the error said 49, not ${7*7} that the researchers had submitted, was an indicator that the backend had a code injection problem. They could then exploit this vulnerability by supplying various Java expressions, accessing various Java classes, and eventually getting full system access.

This is serious because a lot of service providers use VMware Cloud Director, meaning that attackers could get administrative access to a system hosting multiple customers, racking up the impact significantly.

Lessons learned in this one:

• API inputs cannot be trusted (didn’t we say this already?).
• Any parameter and API payload schema needs to be strictly defined (type, limits, regular expressions) and enforced.
• Responses are important, too. They might reveal details that attackers can use in further attacks, as seen here so vividly.

In her latest video, Katie Paxton-Fear demonstrates REST API enumeration/recon, and finding endpoints, hidden parameters, and bugs. The demos include Burp, Ffuf, and Arjun. Check it out:

And if you have not seen Katie’s earlier video on API pentesting, check it out in our issue 83.