Keeping APIs on the radar: Evaluating the banking industry.

Dave Bittner: 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.

Alissa Knight: With this particular vulnerability research, we were hacking financial services and fintech mobile apps and APIs, which Noname was a sponsor of.

Dave Bittner: That's Alissa Knight. She's a partner at Knight Incorporated and a security researcher. Also joining us this week is Karl Mattson, CISO at Noname Security, who underwrote Alissa Knight's research. The research we're discussing today is titled, "Scorched Earth Hacking Bank APIs."

Alissa Knight: 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.

Dave Bittner: And so, Karl, what is in it for you? What's the decision-making process here to underwrite something like this?

Karl Mattson: We've seen research that Alissa 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 a commonly understood risk surface, and so any opportunity to sort of illustrate and give the community tangible evidence and tangible insight into what API security is about and what risk exposure is present, we're glad to sign up for.

Dave Bittner: Well, let's dig into the actual research here then. I mean, Alissa, how did you how did you get your start? What kicked you off on this investigative journey here?

Alissa Knight: Yeah. So yeah, this actually started back when I was an analyst and wanting to create a different kind of white paper. And that was, you know, just, you know, taking my twenty-plus years of experience as a hacker and combining that with my love to create content. And so I'm really doing a merge – 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.

Alissa Knight: And so, I've been doing this for about twenty-one years. And you know, I originally was arrested as a hacker when I was seventeen, went to go work for the US 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 we're really disrupting.

Dave Bittner: Well, let's dig in to the specifics of this particular case here. When you decided to come at these API keys in banking apps, where do you begin?

Alissa Knight: 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, 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 loaded into MobSF, which actually takes the APK file and deconstructs it or decomposes it back to its source code. And it allows me to then comb that code looking for hardcoded keys and tokens, or, in many cases, usernames and passwords. Believe it or not, even though it's 2021, developers are still doing this – hardcoding API keys and tokens. Karl, I'm sure you've seen a lot of this as well. And then taking that attack further to the API backend themselves.

Alissa Knight: So, once I do this, what's called static code analysis or dead code analysis, I then take it on to doing, you know, dynamic analysis, footprinting the API, and targeting the API based on just what's – I like to call a 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, you know, in the case of a web form or web app, just clicking every option, seeing what the stimulus and responses between the app and the backend, and then taking that stimulus and then putting 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.

Dave Bittner: Well, let's dig into the actual findings here because. Reading through them here, they're pretty grim, yeah?

Alissa Knight: Yeah. So, one of the banks that I worked with, so this is the target categories of apps were banks, neobanks, and cryptocurrency exchanges. And you know, 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 thirty of those apps, twenty-seven lacked obfuscation, thirty were vulnerable to women-in-the-middle attacks and thirty contain hardcoded API keys and tokens. The neobank apps – I tested twenty of those – seventeen lacked obfuscation, fifteen were vulnerable to woman-in-the-middle attacks, and seventeen contain hardcoded keys and tokens. And the cryptocurrency exchanges – there were ten that lacked obfuscation, out of the eleven I tested, ten were vulnerable to woman-in-the-middle, and seven contained hardcoded keys and tokens.

Alissa Knight: 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, Alissa, you know, 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 these, what are called "BOLA" vulnerabilities, or broken level authorization vulnerabilities – 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. And I guess the best way I can describe it for audiences, I'm authenticated, but I'm not authorized to perform the functions that I'm performing, or perform the API requests I'm requesting.

Dave Bittner: Karl, 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, you know, it's that old joke – that's where the money is. So, my perception has been that, you know, they have the resources to secure these things. This research points that perhaps that's not the case.

Karl Mattson: I think as a broad generalization, Dave, that might be fair to look at financial services firms having 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 Melissa just mentioned was things like the use of third-party code or interrelationships with third parties. And API calls, whether it's – let's say 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 and third-party services that run behind that application. And so you're introducing a type of complexity in securing a mobile application in banking that is still 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.

Alissa Knight: Yeah. And Dave, one thing I do want to add here is one of the findings – if anyone who follows me in your audience knows – I've done this across different industries, taking remote control of 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 of these different sectors. And one of the things that I can say is, 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.

Alissa Knight: And like, for example, the one of the banks that I hacked their APIs were being secured with a WAF. But the problem is is that web application firewalls are legacy technology that are designed to look for, like, bad things and the payload like SQL injection, and things that, like, you know, looking for a SQL statement within the payload. But if you look at the type of attacks 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, you know, in the payload and the header, whatever, but not exploitation of business logic, right? So, they're not designed to look for things where, oh, this person is is either legitimately or illegitimately authenticated, or they're requesting, you know, data that just simply doesn't belong to them. 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, you know, BOLA or broken authentication or mass assignment. You know, all of these things that WAFs just aren't going to see.

Dave Bittner: Why do you suppose we have this broad spectrum of problems in released versions of software? I mean, I'm left scratching my head with – just looking down this list, you know, things like hardcoded 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?

Alissa Knight: So, I think – and this is what I think is really interesting about today's show, is that we have Karl as a defender, you know, on the defense side and me as a breaker on the adversarial side. So I think you're going to get very two different, you know, probably two different answers here. But I can tell you from my perspective, I think it's – even still in 2021, where we're still not learning from the mistakes that we've made more than two decades ago. And that's, you know, 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 send their employees – they'll have their employees do that annual security awareness training, like, this is what a spearphish 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, you know, 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 Karl, I definitely urge you to offer your input here.

Dave Bittner: Yeah, Karl?

Karl Mattson: Yeah. Let me take 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 a 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 sort of development variables that should have been changed in production.

Karl Mattson: 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. Like, that's a standard scanning activity that you do on 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, hardcoded, or inadvisable for reasons. And that's where that's where our security team gets caught. If we were allowing switches and routers and firewalls to all have admin: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 kind of a responsible way. And the security teams are sort of just discovering that now, that this is another endpoint, where key management and credential management are kind of paramount to securing the asset.

Alissa Knight: Yeah. And Dave, I do want to expound on that here too as well, in the fact that not only was I finding hardcoded API keys in tokens in the apps for that particular fintech or finservice that I was testing, but also the hardcoded API keys and tokens for third parties as well – payment processors or, you know, in some cases, AWS workloads and S3 buckets. So, I mean, 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 look at the documentation, right there in plain sight, it's, do not hardcode 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 so I think I don't know if it's, you know, 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, you know, hey, we'll fix this later and they never get to it. You know, I just don't know, and I'm sure it's a different answer for every organization. But I mean, like you said, we're dealing with money here.

Alissa Knight: And then with one of the banks that I tested, I removed the cookie, there was no OAuth2 happening, so there were 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 in – I don't know what Karl'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 three hundred of its other clients. And so these vulnerabilities were then basically copied and pasted to all of 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.

Dave Bittner: Karl, 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, you know, our organization has APIs. How do you begin this journey? How do you level set for yourself to basically audit and find out where you stand?

Karl Mattson: Well, certainly what's old is new again applies in API security. SANS CIS critical control number one is, you know, 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. 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 what any customer we start with. It all begins with a discovery in the creation of an inventory. And then from that inventory deriving, then the characteristics so that we can paint the – what I call the "operating picture" for the organization. Your operating picture of APIs, that includes those third-party APIs that Alissa is 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 and but that know thyself principle applies to APIs as it does to any security discipline.

Alissa Knight: And Dave, at the end of the day, you can't protect what you don't know you have. And you know, 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 is a huge problem with shadow APIs and, you know, basically organizations – the IT department deploying APIs into production that the cybersecurity team doesn't even know exist. 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. 

Alissa Knight: You know, so I mean, I think, you know, the shadow API problem is a real issue. You know, you need to know your attack surface. Just like the US military knows exactly where its forward operating bases are, you know, 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 protecting your APIs.

Dave Bittner: Our thanks to Alissa Knight and Karl Mattson for joining us. The research is titled, "Scorched Earth: Hacking Bank APIs." We'll have a link in the show notes.

Dave Bittner: 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. Our amazing CyberWire team is Elliott Peltzman, Tre Hester, Brandon Karpf, Eliana White, Puru Prakash, Justin Sabie, Tim Nodar Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Gina Johnson, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Rick Howard, Peter Kilpe, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.