CyberWire Daily - Keeping APIs on the radar: Evaluating the banking industry. [Research Saturday]

Episode Date: January 15, 2022

This episode features guest Alissa Knight, former hacker and partner at Knight Ink, along with Karl Mattson, CISO from Noname Security, discussing findings on severe API vulnerabilities in U.S. banking applications research that was conducted by Alissa and funded by Noname Security. The research, “Scorched Earth: Hacking Bank APIs,” unveils a number of vulnerabilities in the banking, cryptocurrency exchange, and FinTech industries. 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. Three lessons learned include: API security vulnerabilities affect all enterprises, API security needs to be operationalized across the enterprise, and API security requires posture management, runtime security, and active testing. Details can be found here: White paper: Hacking Banks and Cryptocurrency Exchanges Through Their APIs Blog post: 3 API Security Lessons from “Scorched Earth: Hacking Bank APIs” Press release: New Research Shows Vulnerabilities in Banking, Cryptocurrency Exchange, and FinTech APIs Allow Unauthorized Transactions and PIN Code Changes of Customers Alissa's presentation at Money 20/20. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. JoinDeleteMe.com slash N2K and use promo code N2K at checkout. The only way to get 20% off is to go to JoinDeleteMe.com slash N2K and enter code N2K at checkout. That's JoinDeleteMe.com slash N2K, code N2K. Hello everyone and welcome to the CyberWire's Research Saturday. I'm Dave Bittner and this is our weekly conversation with researchers and analysts

tracking down threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. With this particular vulnerability research, we were hacking financial services and fintech mobile apps and APIs, which NoName was a sponsor of. That's Alyssa Knight. She's a partner at Knight Incorporated and a security researcher. Also joining us this week is Carl Mattson, CISO at NoName Security, who underwrote Alyssa Knight's research. The research we're discussing today is titled Scorched Earth, Hacking Bank APIs. And now, a message from our sponsor, Zscaler, the leader in cloud security.

Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. It's time to rethink your security. Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement,

connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI Thank you. The way we work with our clients in this specific capacity is that we have full final cut rights as far as the content is concerned,

meaning that we can say whatever we want and our clients don't have any say as far as what we can and cannot say in that content. So they just sponsored the research. And so, Carl, what is in it for you? What's the decision-making process here to underwrite something like this? We've seen research that Alyssa has put together throughout the years, in particular the things she's done with healthcare and medical APIs. We just saw this as a way to continue to keep APIs on the radar of the security profession.

APIs are not commonly understood risk surface. And so any opportunity to sort of illustrate and give the community a tangible evidence and tangible insight into what API security is about and what risk exposure is present, we're glad to sign up for. Well, let's dig into the actual research here then. Alyssa, how did you get your start? What kicked you off on this investigative journey here? Yeah, so this actually started back when I was an analyst and wanting to create a different kind of white paper. And that was just taking my 20 plus years of experience as a hacker and combining that with my love to create content. And so I'm basically merging these two worlds

and this dichotomy that I have as a hacker and as a content creator. And producing content that I think really speaks volumes to the people that's either reading it or watching it in the form of a film. And so I've been doing this for about 21 years. And I originally was arrested as a hacker when I was 17. Went to go work for the U.S. intelligence community in cyber warfare shortly after that once the charges were dropped. And have been a

white hat ever since. So, you know, this allows me to really break out of that bash shell, if you will, or that meterpreter prompt and really combine hacking with, you know, a form of content marketing, which were really disrupting. Well, let's dig into the specifics of this particular case here. When you decided to come at these API keys in banking apps, where do you begin? So the methodology that I follow is starting with the mobile app itself and doing what's called static code analysis. I use an open source framework called Mobile Security Framework, or MobSF. And so originally you start with downloading the Android app to my Android device,

and then extracting it, ironically enough, with APK Extractor, which I install from the Google Play Store. And extract that mobile app off of the device, place it onto my analyst workstation, and then load it into MobSF, which actually takes the APK file and deconstructs it or decomposes it back to its source code. It allows me to then comb that code

looking for hard-coded keys and tokens, or in many cases, usernames and passwords, believe it or not. Even though it's 2021, developers are still doing this, hard-coding API keys and tokens. Carl, I'm sure you've seen a lot of this as well. And then taking that attack further to the API backend themselves. So once I do this, what's called static code analysis or dead code analysis,

I then take it on to doing dynamic analysis, footprinting the API, and targeting the API based on what I like to call woman in the middle attack, where I sit in between the mobile app and the backend API and analyze that traffic, analyze how the app is interacting with the API by clicking on each button in the app, or in the case of a web form or web app, just clicking every option. Seeing what the stimulus and response is between the app and the backend,

and then taking that stimulus and then putting it into an API client like Postman. Or in the case of Burp Suite, where I'm intercepting the traffic, replaying that traffic once I've intercepted it, and then checking the backend API for things like broken object level authorization or broken authentication vulnerabilities that allows me to request data that doesn't belong to me,

which a lot of APIs that I've been testing have been vulnerable to. It's a systemic problem. Well, let's dig into the actual findings here, because reading through them here, they're pretty grim, yeah? Yeah, so one of the banks that I worked with, so the target categories of apps were banks, neobanks, and cryptocurrency exchanges. And the individual findings themselves,

I would definitely urge people to go download the white paper as well because it's got all the empirical data in it from the researchers beyond these numbers. But the bank apps, there were 30 of those apps, 27 lacked obfuscation, 30 were vulnerable to women in the middle attacks, and 30 contained hard-coded API keys and tokens. The neobank apps, I tested 20 of those, 17 lacked obfuscation, 15 were vulnerable

to women in the middle attacks, and 17 contained hard-coded keys and tokens. In the cryptocurrency exchanges, there were 10 that lacked obfuscation out of the 11 I tested. 10 were vulnerable to women in the middle, and 7 contained hard code keys and tokens. So there's this very clear and present danger across all these different app categories. And then one of the banks that I worked with, actually several of them came to me and said, hey, Lissa, we really dig this research. We're really into what you're doing. We would like you to test our backend APIs.

And so in testing them, I actually was able to log in as myself and then request to change the pin code of any bank customer at the bank and move money in and out of accounts because of what are called BOLA vulnerabilities, or broken level authorization vulnerabilities, and broken object level authorization, as well as broken authentication. So these problems are allowing me to basically perform transactions or

change information that doesn't belong to me at the bank. I guess the best way I can describe it for your audience is I'm authenticated, but I'm not authorized to perform the functions that I'm performing or perform the API requests I'm requesting. Carl, you know, my perception certainly has been that if anybody had their ducks in a row, it was the banks. It was the financial services organizations because it's that old joke, that's where the money is. So my perception has been that they have the resources to secure these things. This research points that perhaps that's not the case. I think as a broad generalization, Dave, that that might be fair to look at financial services firms having, you know, achieved, generally speaking, higher levels of maturity because they oftentimes can invest a great deal in their security programs.

But API security is a little different in the respect that one of the things that Alyssa just mentioned was things like the use of third-party code or interrelationships with third parties. And API calls, whether it's a consumer using their mobile application to check their bank balance and move money, it usually is an interconnected network of first-party a mobile application and banking that is still a relatively new surface for bank or financial services organizations to undertake. And I think that we're seeing right now is we're seeing that sort of awakening. I know I have a high confidence level that this is research that really continues that journey of awakening. And we'll probably see financial services firms moving perhaps a little faster than other verticals in terms of addressing this risk surface. Yeah. And Dave, one thing I do want to add here is one of the findings is if anyone who follows me in your audience knows, I've done this

across different industries, taking remote control federal and state law enforcement vehicles through APIs, hacking healthcare APIs and accessing millions of patient records because of these same vulnerabilities. They seem to be definitely endemic across all these different sectors. And one of the things that I can say is that, in my experience, a lot of these APIs are being protected with the wrong security control. And I think the mindset of the CISO is, APIs speak HTTP, so I'm going to fall back on what I've historically always known,

and that's to protect web servers with a web application firewall. And for example, one of the banks that I hacked, their APIs were being secured with a WAF. But the problem is that web application firewalls are legacy technology that are designed to look for bad things in the payload, like SQL injection and things that are looking for a SQL statement within the payload.

But if you look at the type of a text that I'm performing, like I'm a legitimate, authenticated user, but I'm requesting data that doesn't belong to me, that's not something a WAF is designed to look for. It's designed to look for bad things in the payload, in the header, whatever, but not exploitation of business logic. They're not designed to look for things where,

oh, this person is either legitimately or illegitimately authenticated, or they're requesting data that just simply doesn't belong. They're not designed to do that, which is why I'm a huge proponent of API threat management solutions. Not securing your APIs with an API gateway that's added security features,

but actually protecting your APIs with something that's been built from the ground up, that's purpose-built as an API security solution. Because it's designed to look for the very attacks that I'm using against these APIs, such as BOLA, or broken authentication, or mass assignment. All of these things that WAFs just aren't going to see. assignment, you know, all of these things that WAFs just aren't going to see. Why do you suppose we have this broad spectrum of problems in release versions of software? I mean, I'm left scratching my head with just looking down this list, you know, things like hard-coded API keys and tokens, you know, that to me, why are these things not being caught along the line here before these things are put out to the public?

So I think, and this is what I think is really interesting about today's show, is that we have Carl as a defender on the defense side and me as a breaker on the adversarial side. So I think you're going to get probably two different answers here. So I think you're going to get probably two different answers here. But I can tell you from my perspective, I think it's even still in 2021, we're still not learning from the mistakes that we made more than two decades ago. And that's shifting left security and shielding right. And I think in talking with some of the developers,

a lot of the organizations that I've spoken to, they'll have their employees do that annual security awareness training like, this is what a spearfish looks like. This is how you're going to be targeted with social engineering. That annual required training. But they're not sending their developers to secure code training. They're doing the required entire employee body

security awareness training, but if they're writing code, their developers aren't being sent to secure code training. It's not like they want to write insecure code. It's not like they want to do this. I think it's just a lack of knowledge, a lack of understanding, and a lack of training. But Carl, I definitely urge you to offer your input here.

Yeah, Carl? Yeah, let me take developers off the hook in two scenarios for a second, because the things that I've run across, number one, an API that was developed as an internally facing only API eight years ago, unbeknownst to the developer, then becomes publicly exposed.

And that authentication is inadequate for a public-facing API. So we do see those old APIs being exposed that shouldn't have been. Then the second scenario is where an API developer maybe hardcodes a credential or SSH keys as part of their development effort because they're testing their APIs. But as that API then graduates to subsequent cycles of release, it goes into release without having changed the development variables that should have been changed in production. So an example that I come back to would be on the network side, when we install a new switch, let's say in the organization, we scan it to ensure that it's not using default

admin passwords. That's like a standard scanning activity that you do in the organization, we scan it to ensure that it's not using default admin passwords. That's like a standard scanning activity that you do in the network level with Tenable, Qualys, Rapid7, et cetera. We haven't yet pivoted to also scanning APIs as an endpoint asset and whether its credentials are static, hard-coded, or inadvisable for reasons.

And that's where a security team gets caught. If we were allowing switches and routers and firewalls to all have admin as their login and password, we'd be in a lot of trouble. And on the API side, that's kind of what we've allowed to happen is these static credentials are not changed when they move into production, or they're not leveraging authentication in a responsible way. And the security teams are just discovering that now, that this is another endpoint where key management and credential management are paramount

to securing the asset. Yeah, and Dave, I do want to expound on that here too as well. And the fact that not only was I finding hard-coded API keys and tokens in the apps for that particular fintech or fin serve that I was testing, but also the hard-coded API keys and tokens in the apps for that particular FinTech or FinServ that I was testing, but also the hard-coded API keys and tokens for third parties as well, payment processors or in some cases AWS workloads and S3 buckets.

It's a real problem and in the documentation from these third parties it even says in many of the sites that I went to to look at the documentation from these third parties. It even says in many of the sites that I went to to look at the documentation, right there in plain sight, it's do not hard code this without obfuscating it, without applying any kind of white box or obfuscation, white box encryption or obfuscation. And they're doing it anyway. And I hate to make it look like I'm picking on developers here,

but I don't know if it's just laziness or if it's, hey, we'll fix this later and they never get to it. I don't know, and I'm sure it's a different answer for every organization. But like you said, we're dealing with money here. And then with one of the banks that I tested, I removed the cookie. There was no OAuth 2 happening, so there was no tokens. I removed my cookie and it still allowed me to perform these attacks.

I could still move money in and out of accounts. I could still change ATM debit PIN codes without authentication. So there was something obviously very broken about these APIs. And I think probably, and I don't know what Carl's favorite part of the report is, but my favorite part of the report is the fact that one of these banks outsourced it to a third-party developer and rinsed and reused that same vulnerable code

across 300 of its other clients. And so these vulnerabilities were then basically copied and pasted to all these other financial institutions who were using that company to develop their APIs and mobile apps. And so it created this massive attack surface for me as an adversary where this same vulnerability could be found in other financial services companies.

Carl, let me ask you this. So for that CISO who's listening and is scratching her head and saying, I don't know where I stand with this. We know our organization has APIs. How do you begin this journey? How do you level set for yourself to basically to audit and find out where you stand? Well, certainly what's old is new again applies in API security.

SAN's CIS critical control number one is know your assets. And so I think the diagnostic process of where your posture is at has to begin with an accounting for the inventory and from that inventory, then deriving levels of detail about that inventory, about what's public-facing, what's not, how the APIs are authenticating,

whether there's misconfigurations and vulnerabilities present. And I think APIs are—there's good news. And the good news is APIs are not that difficult to find. What we can do with an API is discover those APIs. They have the distinct advantage of being structured data. And structured data is not impossible to find on the network. And so that's what we do almost uniformly, regardless of where a company is starting from

and any customer we start with. It all begins with a discovery and the creation of an inventory. And then from that inventory, deriving then the characteristics so that we can paint what I call the operating picture for the organization. Your operating picture of APIs that includes those third-party APIs that Alyssa's talking about, that includes the custom-developed ones, that includes the inner APIs that may be service-to-service workload calls that we might take for granted typically. But that know-thyself principle applies to APIs

as it does to any security discipline. And Dave, at the end of the day, you can't protect what you don't know you have. And that's ultimately what I think is the most important thing for any CISO and any organization is make sure that the API threat management solution that you have has the ability to create an asset catalog or an asset register of your APIs,

keeping them updated. There's a huge problem with shadow APIs. Basically, organizations, the IT department, deploying APIs into production that the cybersecurity team doesn't even know exists. That the cybersecurity team doesn't know to make part of their patch management strategy or vulnerability management strategy because they didn't even know the API was there. I think this shadow API problem is a real issue.

You need to know your attacks. Just like the US military knows exactly where its forward operating bases are, knowing that they have to protect the base and the personnel in there. That's knowing what you've got in order to protect it. And the same principles need to be applied to Our thanks to Alyssa Knight and Carl Mattson for joining us. The research is titled Scorched Earth, Hacking Bank APIs. We'll have a link in the show notes. Cyber threats are evolving every second, and staying ahead is more than just a challenge. It's a necessity. That's why we're thrilled to partner with ThreatLocker,

a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely. Thank you. The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Thanks for listening. We'll see you back here next week.