Issue 111: API vulnerabilities in AWS, Tesla Backup Gateway, Twitter 🦃

Researchers at Unit42 found that 22 APIs across 16 different AWS services can be exploited to leak Identity and Access Management (IAM) users and roles.

For improved user experience, AWS is trying to help users avoid mistakes when creating often complex resource-based policies and calls APIs to validate various fields present in the policy. One of these calls is to validate the AWS principal in the policy. See a couple of examples in the screenshots below:

While surely being helpful to the user, this also means that an attacker could use API calls to determine which identities (users and roles) exist for the account. To make matters worse, the messages on any failures appear in the attacker’s account logs. Nothing is logged in the target account, so victims do not even detect that they are under attack.

This is effectively a combination of OWASP issues API3:2019 — Excessive data exposure and API10:2019 — Insufficient logging and monitoring.

As an API provider, to avoid this kind of issue:

• Be mindful of the balance between usability and data exposure, especially when designing your error messages. Sadly, security and being user-friendly are often hard to combine.
• Make sure that logging and monitoring happens so that it can be used to detect attacks.

Unfortunately for AWS customers, the problem still persists. If you are one of them, here’s some advice from Unit42:

• Remove inactive users and roles to reduce the attack surface.
• Add random strings to usernames and role names to make them more difficult to guess.
• Log in with identity provider and federation, so that no additional users are created in the AWS account.
• Log and monitor all the identity authentication activities.
• Enable two-factor authentication (2FA) for every user and IAM role.

Derek Abdine has looked into API security in Tesla Backup Gateways, which are part of the Powerwall and Powerpack systems. Gateways determine when to charge the batteries, when to send the power back to the power grid, and what combination of solar, battery, and grid energy to use to power the house.

The gateways are connected to the internet and expose API endpoints. These APIs are not officially published as part of Tesla’s documentation but have been discovered (unsurprisingly) and documented by the community.

Some of the APIs do not require authentication, and thus publicly expose data on the individual installation, such as energy consumption and production data, display name, country and state, name of the utility company, and so on. Even this seemingly innocent data can be used for nefarious purposes, such as timing burglary when the energy consumption is low, indicating an empty house.

The APIs that manage the system are quite sensitive because of the potential to damage the system itself and possibly even the grid to which these systems are connected. These APIs are secured, but the default credentials to these APIs are quite weak. The default password are the last five characters of the serial number. That serial number is printed on the device and so accessible to anyone in the neighborhood if it is installed outside. In fact, some counties publish households’ installation permits for Tesla Solar and Powerwall to the internet, making physical location of the systems public.

Even worse, the gateways also expose WiFi access points that always follow the same SSID naming pattern: TEG-XXX , where Xs are the last three characters of the serial number. These characters, also used in the default passwords, can be found in various WiFi SSID catalogs. This significantly reduces the scope of brute-force attacks to find out the default password from five to just two alphanumeric characters!

Read for full story for more details on the potential exposure. This can serve as another warning on the potential physical risks of API security in the world of IoT, and the dangers of non-random default passwords.

Twitter Fleets are the newly launched ephemeral media posts that are supposed to disappear after 24 hours.

However, a researcher found out that the APIs behind the feature allow access to older fleets.

Adding to the trouble, accessing fleets through API does not trigger read notifications — there is a separate API call to do that.

This is one of the typical examples of what happens when the user interface is viewed as the security boundary and the underlying API as mere implementation detail. APIs are very easy to discover these days, making it easy to circumvent the security on the UI.

Treat APIs as the security boundary and implement all your limits and security controls there!

The silver lining of the pandemic is that it has forced all industry events to go virtual, making it possible to attend them without having to travel around the world, and DeveloperWeek New York on December 9—10, 2020 is no exception.

There’s a lot of good content, and I will be presenting a session on how to secure REST APIs if they are implemented as microservices in Kubernetes. My session “API Security in a Kubernetes World” is at 1:30 pm EST on December 9th.

If you need a free pass, you can get one from my speaker quota here. 😉