“Dude. What the fuck?!”

During her keynote at the Global CIO Banking Summit held in Frankfurt in October, Alissa Knight never actually screams this, but you get the feeling she would like to.

Instead, she has reduced the phrase to a graphic, and it’s included on almost every one of the slides she uses in her presentation at the conference, a video of which can be seen on her YouTube channel. These slides are screenshots of the vulnerabilities Knight found in the mobile apps of major banks—hardcoded credentials, session tokens, and open password directories—during research she conducted in early 2019.

It’s been almost a year since Knight, a senior analyst at Aite Group, conducted the six-week project, and she has presented on it at some 15 conferences since, including the Frankfurt one. But her incredulity still sounds fresh as she tells WatersTechnology about her findings.

“The findings were pretty shocking—they were just things that you would think large banks would not be doing. It was unbelievable what I was seeing,” Knight says. “There were hardcoded private keys with no password, so I was able to import keys into my keychain and not be prompted for a password.”

Knight was able to hack the mobile apps of 30 banks, stock trading apps, crypto wallets, and money transfer agencies, through vulnerabilities in their APIs. The banks included in the exercise were not small, underfunded community banks; they were major European and US institutions. Knight chose them from Wikipedia’s list of top 100 banks. Within 29 of the 30 apps she tested, she found hardcoded credentials, tokens for third-party payments processors, and AWS and S3 bucket credentials.

Her process was simple. The research took about six weeks, but once she had the hang of it, Knight could take 8.5 minutes on average to crack each app. Knight began not knowing how she would go about it, doing her research as she went along. “I went into this not knowing to spell ‘API,’” she said during her presentation at the banking conference. She knew, however, that these mobile apps had to authenticate with a back-end API somehow, so she looked for tokens and credentials.

First, Knight would download the app from the Google Play Store. Then, using another Android app, she would extract the APK file—APK is the file format used for distributing and installing mobile apps—to her workstation. From there, using MobSF, an app with a web-based GUI used for pen testing and malware analysis, she could decompile the APK file. And then she just searched for keywords in the directory, such as “API key” and “private key.”

“And in some cases, we had some banks kind enough to hardcode credentials. And then I had one bank even hardcode some customer data in their source code,” Knight said, her voice rising in disbelief. “I still have no idea why that was the case.”

Knight, who explodes with energy and charisma onstage, with her long brown ponytail and leather-look trousers—is not the kind of speaker one usually sees delivering keynotes at banking conferences. Arrested while still a teenager for hacking into a government network under the codename Loki (the charges were dropped), Knight had worked in government intelligence and sold her first startup by the time she was 20.

She describes herself now as a recovering hacker turned influencer, combining hacking with writing about hacking for various organizations. Her most recent gig was hacking connected cars for automotive companies, but she is now turning her attention to APIs because of the immense interest she is seeing from her audiences.

“The interesting thing about the API security project was that the apps were full of [other] vulnerabilities,” Knight tells WatersTechnology. “There were SQL injection possibilities, remote code execution possibilities, with a lot of these apps. But the API security took on a life of its own and the project started becoming just about the API vulnerabilities. It’s almost as if the audience has started to care less about other kinds of vulnerabilities and that is what financial services companies are radically focused on right now—trying to understand, well, we have to put these API keys and tokens in our apps, how do we do it if we are not supposed to hardcode them?”

Monoliths to Microservices

This interest is not difficult to explain. One of the most fundamental shifts of the digitization of businesses over the past few years has been the move from monolithic systems to microservices architectures.

While a monolithic enterprise application might be made up of a database, a user interface, and a server-side application, and available through one web app, a microservices architecture connects the capabilities of a business to users via open APIs. Because these are built in standardized formats like REST, they provide a means for software systems to “talk” to each other and facilitate integrated apps. APIs can be bundled into architectural frameworks like API gateways, which act as a single point of entry for multiple APIs.

APIs have thus become the connective tissue of the tech industry. Akamai, one of the world’s largest computing platforms, which sees almost a third of all web traffic, said earlier this year that 83% of the traffic on its content delivery network was API calls.

While this is a well-established trajectory for tech firms and other sectors, in the more conservative capital markets the opportunities for seamless connection are only just starting to seep into the minds of strategists. But as the so-called “API economy” takes hold in this horizontal, financial services firms are going to have to pay more attention to API security.

APIs are, by nature, well-documented. A typical large business now has hundreds. Often the services to which these APIs connect are only a small part of what the business does and could fall beneath the notice of chief information security officers (CISOs).

REST API developers use HTTP as the underlying protocol, so these are vulnerable to the same threats as web applications, such as code injection, man-in-the-middle attacks and denial-of-service attacks.

Hackers are paying attention to that and they know what APIs are a backdoor into a network, so they are targeting them. The problem is that CISOs just don’t know how to secure them properly. They are treating them like web apps and trying to secure them with web app firewalls and other antiquated solutions that don’t really work for APIs.

Alissa Knight, Aite

“Hackers are paying attention to that and they know what APIs are a backdoor into a network, so they are targeting them,” Knight says. “The problem is that CISOs just don’t know how to secure them properly. They are treating them like web apps and trying to secure them with web app firewalls and other antiquated solutions that don’t really work for APIs.”

Knight says that when she took the results to the banks that were part of the research, she discovered that in all cases, CISOs were not even involved.

“A lot of the larger banks outsource the development of their mobile app, and—are you ready for this, are you sitting down? Every single one of the banks considered their apps a function of marketing, so cybersecurity wasn’t even involved in the testing of the app before it was published to the app store. The marketing department considers the mobile app to be a brand, like their website,” she told the Frankfurt bankers conference.

Outsourcing the Risk

Chris Truce, head of fintech at Saxo Bank, says banks are generally well aware of the security risks of APIs.

Saxo has retail offerings, but a major part of its business is partnering with firms in the wholesale market. These firms consume Saxo’s platforms via its open API, which has transformed the business, as reported previously in WatersTechnology.

“In a platform world, where banks have built their own apps, they’re much more in control of the full stack of security,” Truce says. “The buck stops with them—it always has—but in an API world, where you want to do something super sexy in your UI, you will spend money there.”

This means banks spend less on infrastructure, and so partner with companies like Saxo. “Then you are reliant on another organization’s security protocols in the circle of life you are delivering to your client, so if the partner is a security risk, then you are delivering a potential risk to your end client,” Truce says.

Then you are reliant on another organization’s security protocols in the circle of life you are delivering to your client, so if the partner is a security risk, then you are delivering a potential risk to your end client.

Chris Truce, Saxo Bank

But, he adds, institutions are well-versed in exploring security before they start outsourcing partnerships, particularly for critical functions.

“We are a technology company, so when it comes to security and protocols, we are at a level above what the bank has ever done themselves. Typically, when we deal with big partners, there is a procurement process where they tell us they need the APIs to adhere to certain protocols. But what they specify will typically be much lower than the levels of security that Saxo has in its REST-based OpenAPI. Banks come from an industry where technology hasn’t been as deeply integrated as it has in the consumer industry, as you see in the Facebooks and Instagrams of the world.”

However, he continues, banks are starting to up their game regarding the security levels they require. “If they aren’t doing it themselves, they have to rely on external partners and they are increasing demands on their external partners,” he says.

Truce has confidence in Saxo’s level of security. Saxo uses OAuth for securing its RESTful OpenAPI and certificate-based authentication, more akin to a server-to-server setup, for other APIs, he says.

For Security, Shift Left

Knight says she is a believer in “shift-left security”—the notion that security is baked into the app from the beginning of the development cycle. “I am trying to educate businesses on this concept—that security needs to be part of the software development lifecycle and the initial development of the product—don’t wait until it’s launched,” she says. 

“Organizations are trying to wrap their heads around that. You see GitHub repos taken down all the time by banks because developers are publishing their mobile app code to GitHub with their keys nested in the app. People don’t really understand that API keys are like passwords and you have to protect them in the same way.”

She says that companies should not secure their apps in API gateways, but should rather use API security gateways.

“API gateway companies like Apigee and Mulesoft are coming to market with gateway solutions, saying you don’t need a security solution, we will secure it for you. But it’s security as a feature, rather than security that has been built from the ground up. And that’s why a lot of APIs still get breached,” she says.

Most of all, like Sun Tzu, Knight believes that in order to defeat the enemy, you need to know your enemy. And so she has, in partnership with Aite Group and some vendor supporters—including Sentinel One, Ping Identity and Ativo—set up a fake online retail bank. The bank seems legit; it has a website and you can even open an account there. But it is just a honeypot, set up to attract the interest of hackers and provide insight into how breaches happen in APIs.

The decoy bank uses APIs built on OFX/FDX, the standards for the secure sharing of consumers’ financial data, and for authentication protocols. “We are even going on dark web forums and saying, ‘Hey I just saw the API key for this bank, looks they have a broken representation of OFX or FDX, let’s go after them.’ And it’s really interesting the sophisticated adversaries this attracts,” Knight says.

APIs are here to stay in financial services, and the work to educate the industry on securing the wide attack surface they present is only just beginning.