Issue 101: Vulnerabilities in Giggle, Google Cloud Platform, SonicWall, New Relic, Tesla 🚗

Giggle is a women-only social network and mobile app. It is meant to be a safe place for everyone on the network but, turns out it was not all that safe: researchers from Digital Interruption found some serious API flaws in it.

The team ran the app through a proxy and observed the API traffic. They found that the API behind the app effectively had a query language:

This meant that they could query any user record:

The API returned full user info, even when the queried record was another user (classical BOLA/IDOR):

As you can see this includes very confidential information, such as name, email, picture, interests, exact geographic location…

To make things worse, operators in the API filter included contains, which opened up the system for enumeration attacks:

So, easily exploitable vulnerability that given the nature of the service could have serious consequences.

Quite a drama seems to have ensued from the attempts to responsibly disclose the vulnerability, but luckily it has now been fixed.

Ezequiel Pereira found an API flaw in Google Cloud Platform (GCP) that could allow attackers to obtain a list of service accounts in a GCP project and potentially gain access to unsecured resources.

Pereira was looking at the IAM API of GCP and figured out that the page token it used for pagination was a Base64 Protobuf-encoded string that contained his project ID. He could then forge page tokens for GCP projects he did not own and use the tokens to get results which he was not supposed to be able to access.

Pereira then expanded his attack and figured out a way to use GCP services to enumerate unsecured resources or GCP projects that in turn could provide more details on GCP customers, opening door to further, more directed attacks.

The fact that the  authorization check was not working on this API makes this a yet another BOLA/IDOR vulnerability.

SonicWall provides security appliances, such as firewalls, and API vulnerabilities involving security companies always feel doubly embarrassing. Pen Test Partners found that SonicWall’s cloud management platform APIs were susceptible to IDOR/BOLA attacks.

The management platform has a feature that lets you invite other users into your groups and delegate the management of SonicWall network security devices. Behind the scenes, this feature uses the API endpoint api/users/add-user.  The API request takes a parameter partyGroupID, a 7-digit sequential group ID that is unique to your group across all tenants. The user is added to the group with the specified ID. Sounds quite ordinary, right?

Just seven digits and sequential ID means that attackers could simply brute-force the group ID and use it when invoking the endpoint. SonicWall did check the parameter emailAddress, but if the email did not match the JSON WebToken (JWT) used for authorization, the user was still added to the group. In practice, this amounts to not having authorization in place at all. Because the group ID spanned the tenants, the user would be added to the group on all tenants.

All this could have allowed attackers to add themselves to any of the about 2 million groups in 500 000 organizations, giving them the ability to manipulate 10 million security devices any way they wished!

The vulnerability was eventually fixed, but it is unclear to what extent it has been exploited. Potential harm here is significant.

Jon Bottarini has disclosed about 30 (!) vulnerabilites in New Relic, a company specializing in cloud-based software that helps owners of websites and apps track the performance of their services.

A lot of the vulnerabilities are in New Relic APIs, and many are familiar faces:

• Broken Object Level Authorization (BOLA/IDOR)
• Excessive Data Exposure
• Broken Function Level Authorization

The link takes you to the actual HackerOne reports, so they include the detailed steps to reproduce the issue as well as the discussion threads with the vendor. This means they provide the full context and can serve as good examples for other penetration testers.

This vulnerability dates back all the way to 2017, but only got publicly disclosed now: how Jason Hughes managed to VPN into Tesla’s network on from his car and take over their main backend server.

This server controlled the whole Tesla fleet. Hughes discovered an unprotected API he could invoke for any car. All that he needed for that were the last six digits of the car VIN, and the control over the backend server handily provided him that information. He could then get the car’s location, status, start the car, and even make it move.

Click here to read the full report.

Lesson learned: no such thing as internal API exists these days. Even API on internal network should be protected.

On the topic of high-end smart cars, we recently also covered a similar vulnerability with Mercedes-Benz.

Broken Object-Level Authorization (aka BOLA or IDOR) is the number one and the most common issue in the OWASP API Security Top 10 list. Even just in this newsletter, all but one of our vulnerabilities directly involved BOLA!

Dohn Joe has put together a neat quick cheatsheet on how to find IDOR/BOLA on APIs.

Worth a read for all pentesters out there!

On next Thursday, September 24, Keith Casey (OKTA), David Stewart (CriticalBlue), and Isabelle Mauny (42Crunch) are hosting a webinar on the layers and alternatives in the confusing world of API security. Quoting from the webinar abstract:

This webinar was born from a chat around a coffee at a conference, when we discovered we all spent a lot of time explaining the paths towards better API security to customers. OAuth, OWASP, OIDC, SCA, IDPs, RPs, North-South, East-West, Meshes: welcome to the alphabet soup of API Security where there are no maps, lots of obstacles and detours, and threats from all sides.

Do you feel a bit lost? You are not alone.

To consider and apply API security effectively, we need to understand where we are and where we need to go. We need to know the tools we have available and who our allies are. Finally, we need a clear path and priorities on what we can accomplish and how. In this webinar, we’ll lay out a reference architecture to ensure we understand the scope, challenges, and approach to secure your APIs and organization as a whole.

We will use real use cases to illustrate the various threats and abuse APIs are exposed to.

Topics for discussion:
– What’s the landscape? What is in bounds vs out of bounds?
– What are the most common obstacles? How can we overcome them?
– Where have others failed before us? How can we avoid the same?

Click here to enroll and reserve your spot.

If you are using Jenkins, make sure to attend next week’s virtual DevOps World conference on September 22—24.

This is a free event offering a whopping 57 security-related sessions, including one specifically on APIs: “Using Jenkins Pipeline and DevSecOps for API Security”, presented by yours truly.