3 API Security Lessons from “Scorched Earth: Hacking Bank APIs”

Ethical hacker Alissa Knight opened the eyes of the banking industry yesterday in her Money 20/20 keynote presentation entitled “Scorched Earth: Hacking Bank APIs”.

In her presentation, Alissa revealed that she was able to gain access to 55 different banks and change PIN codes and move money in and out of accounts.

Below are the key findings from the press release.

The full report is now available here.

• 54 of the 55 mobile apps that were reverse engineered contained hardcoded API keys and tokens including usernames and passwords to third-party services
• All 55 apps tested were vulnerable to woman-in-the-middle (WITM) attacks, allowing Knight to intercept and decrypt the encrypted traffic between the mobile apps and backend APIs
• 100% of the APIs tested were vulnerable to Broken Object Level Authorization (BOLA) vulnerabilities allowing Knight to change the PIN code of any bank customer’s Visa ATM debit card number or transfer money in/out of accounts
• 100% of the APIs tested were vulnerable to Broken Authentication vulnerabilities allowing Knight to perform API requests on other bank customer accounts without authenticating
• One of the banks tested outsourced the development of their code; the developer reused that same vulnerable code across hundreds of other banks allowing the same attacks to be employed against those other bank targets

Enterprises across all verticals can learn from Alissa Knight’s research. Here are the top 3 lessons learned:

1. API Security Vulnerabilities Affect All Enterprises

API usage has surged into a sprawl for businesses of all shapes and sizes. Words and phrases like “digital transformation”, “cloud migration”, “apps”, and “microservices” all mean the same thing — lots and lots of APIs.

In Alissa Knight’s research, she found the same API security vulnerabilities in banks that had 25,000 customers and a few million in managed assets as she did in banks that had 68 million customers and $7.7 trillion in assets under management. Large, mature, and well-funded security teams are not able to keep pace with API security challenges with traditional tools and processes.

2. API Security Needs to be Operationalized Across the Enterprise

Many teams play critical roles at securing APIs. Developers need to write code with security in mind; cloud and platform teams need to use APIs that are configured properly; and security teams need to detect, investigate, and respond to incidents. Often, especially in larger organizations, APIs are deployed to production faster than they can be secured and there often isn’t a clear line of communication across enterprise teams.

Specific to Knight’s research, the APIs she exploited were developed by a third party — introducing yet another variable. Whatsmore is that the hack wasn’t detected at any of the banks. This highlights the fact that API security needs to be operationalized across more enterprises to ensure that vulnerabilities are detected and remediated before an attack. And it’s not just the responsibility of a single team. Developer, DevOps, DevSecOps, and security teams need to standardize, collaborate, and communicate how they build, deploy, and secure APIs.

3. API Security Requires Posture Management, Runtime Security, and Active Testing

It’s very easy to jump to conclusions when exploits or attacks make headlines. But detecting and blocking behavior like Alissa Knight’s is only a piece of the API security puzzle. Enterprises need to think about API security across 3 core areas:

• API Security Posture — organizations need a complete API inventory (including associated data and metadata) so they have a stronger sense of their security posture. It’s imperative to identify and remediate misconfigurations and vulnerabilities before an incident occurs. As evidenced in Knight’s research, many organizations are completely exposed and won’t be aware until after an attack has occured.
• API Runtime Security — organizations need better visibility into the traffic and behavior of their APIs. This provides better detection and response to anomalous and suspicious behavior so attacks can be prevented in real-time when something out of the ordinary occurs (like Alissa Knight’s hack).
• API Security Testing — organizations need to identify security gaps as part of the software development lifecycle. For example, at no point should business critical APIs be deployed into production if they couldn’t pass basic security checks (e.g. lack of authentication). Active testing ensures confidence in your APIs throughout the lifecycle of an API.

Our goal at Noname Security is to help enterprises have trust and peace of mind with their APIs. And we chose to work with Knight because there is still so much education that needs to happen.

Together, we look forward to pioneering and shaping API security maturation across all industries.