Scorthter, Hacking Banks and Cryptocurrency Exchanges through their APIs
I am a content creator and my job is to create content that proves the efficacy of a security product by hacking something. Noname security (API security company) sponsored this research as a way to prove its capability to detect and prevent attacks on APIs so my idea was to hack into banks and cryptocurrency apps through their APIs since they really are the plumbing of our financial services and FinTech system today. 54 of the 55 apps that were reverse engineered contained hardcoded API keys and tokens and even usernames and passwords so even in 2021, we are still hard coding API secrets and usernames and passwords in mobile apps. This is an incredibly bad problem and a bad thing to do, of course. Developers need to stop doing this as it is a very common thing that’s systemic across multiple verticals.
Modus Operandi
What I did was I downloaded the 55 apps onto my Android device, used the APK extractor from the Google Play store to extract the APK files off of the Android device, load them onto my workstation and then reverse engineer them in mobSF (mobile security framework). This outsourcing led to the compromise of 300 other banks. To cut a long story short, a bank had approached me asking that I hack their APIs as part of the research. What I found out was that the vulnerabilities that I’ll talk about here shortly – broken object level authorization, or BOLA, and broken authentication – were due to the fact that the code was actually reused by a company that they outsource their development to. These vulnerabilities were then found in 300 other banks that were clients of this company. The point here, for those who outsource the development of their APIs and apps, is that you may trust but you need to verify. You want to always make sure that even though you’re outsourcing it, you understand that you’re abdicating it and you’re still responsible for making sure that those apps and APIs are penetration tested, and that they’re free of these issues. Many of the APIs were secured with WAFs (web application firewalls) that were unable to detect my attacks. The key takeaway that I have from this research is that you need to secure APIs with API threat management solutions. There is no point using legacy WAFs for protecting legacy web applications and monoliths. WAFs are not going to be able to detect logic based abuses, like broken object level authorization and broken authentication. They’re looking for things like SQL injection, and bad things in the payload and the headers and that means they won’t protect you as you are not using the right tool for the job.
The Targets
For those who are still doubtful about the targets and inclined to believe they were small community banks or neobanks or one or two person start-ups, here are a few facts: 55 financial services and fintech mobile apps covered 19 banks, 11 cryptocurrency exchanges and 21 neobanks. Out of the 19 banks, 4 had over 101k employees, 5 between 51 and 100k, 8 between 10 and 50k and 2 had between 1 and 10k. As you can see, we are not talking about small community banks. As far as the cryptocurrency exchanges are concerned, 2 had $10 to $50 Bn in crypto under management and 4 had over 500 employees. Again, we can’t say big companies don’t have these problems.
The Results
The APIs that were vulnerable to BOLA actually allowed me to change the PIN code for any ATM debit card of any customer in the bank. As long as I knew the ATM debit card number, I could change that pin code and it didn’t matter whether it belonged to me or not. The developers were authenticating me, they saw that I had a valid session but they didn’t check to make sure that I indeed actually had the authorization to change the PIN codes for these ATM debit cards. This affected tens of thousands of customers and the most shocking thing was that, due to lack of authorization being applied, it was possible to transfer funds between accounts as long as I knew the source and destination account numbers. Because of a flaw in the code and the absence of 0Auth 2 tokens, it was even possible to perform both attacks without authenticating and the bank didn’t find out until after the actual tests were done.
What To Do
The solution to this is to do a complete API inventory as you cannot protect what you don’t know you have. This includes associated data and metadata. You also need to know what APIs are in your attack surface (this is also referred to as attack surface management or the shadow API problem) and finally, make sure that your threat management solution has the ability to create a real time inventory of your APIs. Back when I started hacking around 21 years ago, a lot of organisations had a few 100 API endpoints. Now I’m working with an organisation that has over 6000 API endpoints. You need to know exactly what data those APIs are actually transmitting, processing and storing. It doesn’t make sense to pay the most attention to the API that’s not processing anything sensitive, you’ll want your diligence to be around the APIs that are processing PII, PHI or PCI. Organisations need better visibility into their traffic and the behaviour of their APIs, I can’t tell you how many of the organisations that I worked with and hacked, didn’t know that I was hacking them. They were not tapping into that traffic, and had no visibility into what went in and out of their APIs. My advice is to analyse that traffic and learn what is going on there so you can stop it when needed. Organisations also need to identify security gaps as part of their SDLC. I am a big believer of shift left security so make sure you train your developers on secure code development, make sure that you have checkpoints, as the code is being written, to ensure that there’s a penetration test being performed at key and critical steps before the code goes into production. Not after, we need to get away from this mindset of just quickly getting speed to market and being first to market. That leads to forgetting about security, until that kind of problem happens. The days of this polarised environment of developers vs Security are over and we are on the same team defending ourselves against a common enemy. That enemy wants to disenfranchise us, they want us to turn on each other, and not operate as one functional team. It doesn’t matter if you’re a developer or security engineer, or DevOps, we’re all defending the same battleground and we all need to work together to do that. The last key point within this solutions panel is to hack your own APIs. It is very important to bring in penetration testers to hack your code. We are constantly facing organisations that just rely on their developers to do static code analysis or even dynamic code analysis but it is just not enough. Developers inherently know their code and the potential issues it can have so you must use external pen testers who don’t have the visibility to hack your APIs and check for other loopholes. See it like a blackbox penetration test and have hackers that don’t know the environment, actually hack your apps. That’s it. The report will be published and will be made available on nonamesecurity.com.
Q&A Section
Q: What did you expect when you started the research?
A: When I was walking into this research, I wasn’t sure what I would be dealing with. I was thinking that with banks, especially cryptocurrency exchanges, I would not run into the kind of low hanging fruit that I was seeing. This is really Day one of Hacker School kind of stuff, OWASP, API security, top 10 Number one and number two. This definitely should have been harder. And the worst thing is that it isn’t even systemic to financial services. If you have a look at the vulnerability research reports I’ve published on healthcare, transportation and other sectors, you’ll find the same problems there.
Q: Did you see any difference, more security measures for example for cryptocurrency exchanges than for banks or healthcare companies?
A: No, it wasn’t like one sector was more secure, or less secure than the other, I was finding the same vulnerabilities across the different test subjects. When, when my report comes out, you’re going to be able to actually have an infographic that shows and breaks down the vulnerabilities by sector, and then by organisation type.
Q: Did you see at least one company that was doing the job really well?
A: If you look at the statistics, and what I’ve published, it was 54 out of the 55 that were vulnerable to attacks, where I have actually been able to go in there and analyse the traffic to the APIs and see how the APIs were working. This means there was only one app, on the banking side, where I wasn’t able to do that. The research is definitely ongoing and we’re going to continue to add more and more evidence and screenshots and vulnerabilities into the research report as we go into January, but right now, the cryptocurrency exchanges are definitely just as bad as banking. It’s almost like they’re outsourcing it all to the same developer.
Q: If it happens in healthcare, in banking, in cryptocurrency, it’s a bigger problem than just one company not doing the job. What’s the overall problem that everybody is facing there?
A: I think it’s the fact that we’re all remembering to authenticate but no-one is remembering to authorise. End developers need to understand that just because you’re authenticated, it doesn’t mean you’re authorised to see all of the data or manipulate all of the data. If you’re going to implement tokens, you need to do things like implement scopes, make sure that if Alyssa Knight is logged in, she shouldn’t be able to manipulate any of the data for someone else’s account. I would like to see the world move to more of a zero trust security framework where we don’t trust the data. We don’t even trust the app that we’ve developed to interact with our API. We don’t trust the human, we don’t trust anything. Or we can trust but verify everything.
Q: Developers should implement the least privilege concept?
A: Correct. The other thing that I noticed in my research is that we need to make sure thats when developers are implementing microservices, they also need to implement segmentation of databases. If you have different microservices, and you’re storing different types of data, don’t use one single data lake or one single mass database for all of these microservices and all these APIs. You want to definitely implement micro segmentation of data across different databases, and allocate them to different services. There was one instance where one company developed an app for one company, and then another company, and a lot of that data was actually being cross pollinated into a single data warehouse. If you have an actual segregation of data then you need to make sure you implement microsegmentation at the database.
Q: You advocate zero trust, and earlier, the CTOl of Dashlane was advocating zero knowledge. Will we end up with zero data?
A: Humans are the weakest link in security so it doesn’t matter that your CISO has a blank check for buying whatever they want. At the end of the day, humans are the weakest link. It could be the developers, it could be the fact that insecure code is being written and published into production, and no one’s testing it, or no one’s found the vulnerabilities in it. You just need to make sure that you’re sending your developers to secure code training and have that zero trust, zero knowledge approach. We can’t trust anything in the environment; you can’t force data to stay in one place that you have completely surrounded with security controls, it doesn’t work that way. Data is everywhere, even more so now, in this post pandemic economy when all of our employees are working from home. CISOs need to also think about the home networks of their employees that their children are gaming on. I believe this concept of a single intranet internal to a network that you’re deploying security controls on and securing is dying, and that we’re moving more towards Clouds.
Q: What do you think about the honeypot strategy?
A: I think it’s a great way to get adversarial knowledge on what tactics and techniques are being developed, what craft is being developed by blackhats and adversaries to target APIs. As a matter of fact, I was in the process of developing and launching a production API Honeynet to understand how attackers are targeting and breaching APIs.
Q: Is the digital infrastructure that we are building based on the API economy sustainable if there are so many holes and issues and breaches?
A: If you’re connected to the internet, and you have employees, you will be breached. I think the number of breaches will continue to rise. As a matter of fact, Gartner published a statement on this that API breaches are going to be the number one method of attack for adversaries in 2022. I believe in that. If you think about it, hacking is no longer about defacing websites. It’s about profiting and not just profiting but double dipping, lock and leak ransoming, encrypting and then also leaking the data and selling it again on the dark web. Where is that data being stored? Where is the honeypot? It’s the APIs because that’s where the data is. Your adversaries are going to begin targeting you at your APIs and right now it’s a very soft and gooey exterior. That’s what I am proving with the vulnerability research. If you go on my YouTube channel, I have videos and videos of hacking banks through their APIs, hacking federal and state law enforcement vehicles through their APIs because they’re vulnerable. We’re repeating the same sins that we were making 20 years ago, hard coding usernames and passwords and apps, that’s ridiculous.
