Banking API Security”: N26 API just a big Swiss cheese?

Vincent Haupert recently presented his findings on banking API security that had massive security holes during a 33C3 Congress event. He aptly named his talk “Shut Up and Take My Money!”. Not only was it possible to hijack the account and transfer the savings, but it was also possible to apply for a loan and create even greater damage.

Banking API security

The N26 Banking API had a number of problems like:

• very verbose API
• missing rate limiting
• bad security design

Find the full presentation recording (~30 minutes in English) here: Shut Up and Take My Money! -The Red Pill of N26 Security

Why is this an issue?

Well, N26 is a Fintech Company that recently evolved from a banking app into a full bank. It’s likely that other Fintechs will follow the same path, during a time the banking industry is moving towards providing better apps and services quicker and faster than ever. But, is security always considered the No. 1 priority? Speed for a quick go to market is for sure.

Not only have their own security controls failed but the Government seems to not have any processes to detect these flaws.

What went wrong and how to protect?

Too verbose API

In the examples Haupert has shown, the API provided a lot more information than the actual app was showing to the user. This is pretty often the case but what gets analyzed is the App because it’s the UI and the Frontend that is exposed. It’s a little bit like if you would judge the security of a phone call by looking at the phone only and not at the wiring and connection. The reason for too verbose APIs is usually the fear that Frontend Developers might need that information at a time when they are developing the App further, thus causing a problem with a new API version.

The easy solution, which applies to this case, is an insecure path to expose all and think about it later. It’s important to mention that in the N26 case, response messages also caused some issues like containing the secret URL to reset a password when a password rest was requested. API Management Systems actually help in filtering APIs, providing assistance with API Versioning, etc.

Missing Rate Limiting

Some of the methods used look pretty smart and they are but a lot of them are just table stakes. Not limiting an API on the number of calls it can be hit with just helps hackers to try out their ideas and progress with their research. If it gets slow or they get blocked they might spend a long time, which could have given N26 a way to respond or react to the suspicious behavior.  This is a pretty common issue, which has been detected by a recent study. Common API Gateways could have protected the API and helped N26 to look better with this.

Bad Security Design

In theory, security mechanisms were in place but seemed to lack end-to-end testing. Haupert also makes the point that customer support can be an important security issue too. If they are the ones to change all data without notice to customers on a second channel than they become an attractive target too. In this example, Haupert did not have to try too hard because all the information that would have been required to change things like email, name or unpair a phone would have been available to him and just a phone call away. Interested in this type of attack? Look here: This is how hackers hack you using simple social engineering

Overall the presented issues are not “Black Magic” they are logical and look pretty straight forward. Most of them would have been prevented with state of the art API security technology and some help from security experts or input from the IT security team. Both things are not difficult to get.

What else?

Overall, it’s worth mentioning that according to Haupert N26 responded professionally and quickly to his findings, which is one of the other key learnings. Be open for input from outside and react professionally and quickly on them.