Issue 107: Vulnerabilities in Waze, AWS, and NHS COVID-19 app, Forrester App Sec Tech Tide 🌊

Remember the fun “other cars” icons that Waze, Google’s social GPS navigation app providing travel times and route details by other users, is showing on the maps? Peter Gasper decided to have a look on the API behind them and found exposure of some sensitive data lurking there.

To look at the API, Gasper used Waze’s web page waze.com/livemap that also shows the car icons, just like the mobile app. The API behind takes the latitude and longitude coordinates as parameters and returns JSON with the car objects to draw nearby. Besides the coordinates, these JSON objects included identification numbers (IDs) that did not change over time.

This means that each number uniquely identified a particular Waze driver. So if there is a particular car passing you, the driver is a Waze user, and you want to track where it is going, you can start invoking the API sending GPS coordinates in its proximity and each time getting its new location.

Gasper created a proof-of-concept exploit by building a Chromium extension leveraging chrome.devtools component to capture JSON responses from the API behind the page, and tracking a car:

This is bad enough by itself: enabling virtual spying after strangers, discovering their routes over days, and potentially de-anonymizing Waze users that way.

It turned out that another Waze API leaked even more. Any time a user reported — or even just confirmed — an obstacle on the road, that API would include both that internal user ID and the Waze username of that user in the API response. With many people using their actual names as usernames, or reusing usernames across various profiles on the internet, that provided a way to go one step further and discover the real, offline identity of many drivers.

And just like with the first API, you do not need to be physically present to use the API. You could just invoke it with the coordinates of high traffic areas and harvest the ID to username mappings.

So, a pretty bad case of API3:2019 — Excessive data exposure vulnerability leading to personal privacy risks. To avoid such vulnerabilities in your APIs:

• Document, review, and enforce any and all API responses.
• Make sure not to return anything that your app does not actually need. Approximate GPS coordinates without IDs would have been more than enough to draw the icons in Waze.
• Do not leak internal identifiers.
• Whenever your API returns any data, ask yourself whether you yourself would be comfortable if someone gets their hands on that data. If not, think again.
• Do what you can to make it harder for attackers to bulk use your API for data harvesting.

Nick Frichette found that for a given AWS user or role, he could use the AWS API to enumerate permissions without having these calls logged to CloudTrail. The vulnerability affected 645 different API actions across 40 different AWS services.

The APIs that were vulnerable returned:

• A 403 response if the account did not have permission to call the API
• A 404 response if the account had permissions to call the API

Since the call was “malformed” – it did not actually retrieve the resource – the system didn’t consider it important enough to log the calls in CloudTrail. Thus, attackers who got a hold of an AWS account in the target system could run a script and quickly (and without being noticed!) find what else they can do with that account.

This is an example of OWASP API10:2019 — Insufficient logging and monitoring vulnerability. Make sure to log sensitive calls and failures, monitor the logs to detect attacks, and take action.

James ‘zofrex’ Sanderson checked out  the UK NHS Android COVID-19 tracing app and found a minor vulnerability in it.

Among other things, the app has the functionality to check into a venue by scanning its QR code. These QR codes are JSON Web Tokens (JWTs), issued and signed by the NHS to prevent fraud.

As James explains, the JWT standard can be tricky and error-prone to implement. It is extremely flexible and includes many features that can leave you unprotected. One such feature is the ability to specify the signing algorithm and the keys in the JWT itself.

Proper JWT implementations need to watch out for someone leading you to trust the algorithms and keys that are not yours. However, the creators of this app used the jjwt library for their JWT implementation, and this library did not make it obvious how to protect against such attacks. As result, someone could create a forged JWT token (and the QR code representing it) without any signature at all and specify alg=none as the algorithm to be used.

See James’ writeup for more details. Thankfully, there were no implications on things like privacy or personal data here, but nothing prevents a similar issue from cropping up in a more sensitive place, so worth taking lessons here.

For more information on JWT attacks and security, see the collection of conference talks that we had in our issue 72 .

Application security is a broad area, with multiple technologies that companies employ to cover all their bases.

These technologies are all in different stages of maturity, producing different return of investment. And with application security specialists more stretched than they have ever been, companies need guidance to prioritize their projects.

This is where the report Tech Tide report for Application Security Q4, 2020 by Sandy Carielli from Forrester comes in handy. Carielli ranks 20 major app sec technologies by business value and maturity, lists major vendors, and provides investment guidelines.

Quoting from the report abstract:

Application security is increasingly critical to firms’ ability to win, serve, and retain their customers. To accelerate their performance in application security, companies are evaluating and adopting a range of contributing technologies. This Forrester Tech Tide™ report presents an analysis of the maturity and business value of the 20 technology categories that support application security. Security pros should read this report to shape their firm’s investment approach to these technologies.

And most importantly for this newsletter, API security gets a strong recommendation to invest!