Life hacks: Alissa Knight, Money20/20 and app hacking

By Matt High

Alissa Knight has many talents. Started hacking at the age of 13? Check. Arrested for hacking a government network at 17, only to subsequently work with the US intelligence community in cyber warfare (presumably to keep her on the right side)? Check. Serial entrepreneur now on her third company sale and exit – the first being sold when she was 20? Check? Hacking into a bank’s internal network through its CCTV cameras in the parking lot? Yes, that really did happen.

Alissa Knight – recovering hacker, entrepreneur and influencer – on being the bearer of bad news to the financial services industry

Most recently, Knight had the pleasure of addressing an eager Money20/20 USA audience comprised of visitors from the global financial services sector. She was there to tell them that, as part of a recent research project, she had hacked 29 of 30 mobile financial services apps from some of the biggest players in banking, stock trading, digital currency wallets and insurance. Each of them in less than eight minutes. Today, Knight is an ethical hacker or, ‘penetration tester’, if you don’t want to use the ‘H’ word. Regardless, whether it’s cars, financial services, or anything else, if it exists, she can hack it.

FinTech was fortunate to take some time with Knight towards the end of the event, during which we discussed her app research in more detail – the results of which she has been delivering on a whirlwind tour around the world – and picked her brains on cybersecurity in the financial services sector. “Generally, the reaction has kind of been ‘you have to be kidding me, this is crazy’,” she explained. “It’s a real problem and, basically, I’m the one that gets paid to be the bearer of bad news, which feels pretty cool.”

That ‘news’ is that Knight – has also spent her time in Stuttgart, Germany ‘penetration testing’ connected vehicles by taking control of their steering and braking – downloaded 30 leading financial services apps and reverse engineered them all, finding hard-coded API keys, tokens and credentials for the banks and their third-party payment processors, and having the run of their data in the backend. The results, she conceded, were “pretty bad”, adding that “the numbers were a lot higher than I thought they would be – I thought it would be around 50%. It’s clearly systemic, I really didn’t spend that long on the project, about a week in total, so when you put it in perspective that I hacked 29 banks in a week – we need to be doing better.”

The day prior to our meeting, Knight had presented the results of her findings in more detail. After her opening gambit – “are you guys all sitting down? I don’t think any of you are doing anything correctly” – she proceeded to explain that, contrary to what many may have expected, the research was not focused on community banks or small credit unions. Rather, she took the 100 largest banks from a Wikipedia list and set about her work. The one that survived was an (unnamed) German bank, the rest were large US and European financial institutions.

“There’s some really bad hygiene out there,” she explained to us. “There are so many vulnerabilities that have just kept reappearing over the last 20 years.” Over the next 20 minutes or so of her presentation, Knight blasted through some of her key findings, including the hard-coding of both bank and third-party payments processor keys; gaining access to credentials for the likes of Amazon Web Services and Amazon S3 buckets; banks publishing their API documentation so any hacker worth their salt can jump straight in; developers leaving access to merged production and private keys with no password; hard-coded credentials (“when I found it, it was an ‘oh my god, it’s amazing’ moment”) and more. In short, everyone, everywhere is not delivering on their cybersecurity developments.

And while she conceded that “the research took on a life of its own and became more about API security than the other vulnerabilities,” she added that “there were dozens of other vulnerability categories that were problematic across all the apps. I also looked at fintech apps. I actually thought that the smaller companies would have the most vulnerabilities, but it was the complete opposite. The cryptocurrency wallets in smaller companies have more secure code than their larger counterparts. It’s the weirdest thing – the bigger banks, the bigger institutions have the worst, most horrible apps.”

Our follow up question mirrored that likely on the lips of all those who attended her presentation: how? One of the main problems, she explained, is that contrary to popular belief, banks are outsourcing a large proportion of their development work. “It’s a case of a lot of outsourcing, but very little checking. The developers will approach the bank, needing the tokens and keys to work through the app and, once the banks have given the information over, they’re washing their hands of it so it ends up embedded in the app – there’s no visibility. I even encountered banks that made ownership of their app development a function of their marketing team.”

We live in an API-first world, Knight believes. The problem with that world is that many organisations don’t understand how to secure their APIs. “If all you have is a hammer, everything looks like a nail,” she said. “They’re securing them with web application firewalls or API gateways, and that’s wrong. In many API breaches, the organisations had API gateways in place, but they’re not using API security gateways. And that’s because we’re not shifting left in security, meaning that when we’re developing the app, we need to be implementing security controls in the development process, sending our developers to secure development training, and budgeting for that. We need to be looking at APIs differently.”

And it’s the last point that lies behind one of Knight’s several recommendations to counter the problem: hire hackers, not developers. The latter, she told Money20/20, “are drunk on their own Kool-Aid,” insisting that banks should “hire people like me and hack yourselves before somebody else does, and then tries to sell you their findings. Banks should also focus on static and dynamic code analysis of the applications of mobile apps too. If you’re not doing it, do it.”

It’s clear from watching Knight over the course of Money20/20 that she has little time for rest. Indeed, hot on the heels of breaking into some of the world’s largest financial apps, she’s in the midst of developing what she called “the sexiest thing anyone would hear about all show”. In essence, this is a large, fake bank – sexy, if you’re that way inclined. Knight is. “It’s based off the idea of Sun Tzu’s Art of War: if you’re going to defeat your enemy, you need to understand your enemy. So, we’ve created a fake bank complete with internet-facing APIs, and even a fake website; we want them to be hacked. It’s all about understanding and monitoring how our adversaries are breaching APIs so we can study their tactics, techniques and procedures.”

Knight calls the project, for which she has already gained multiple sponsors, ‘adversarial analysis’. As part of it, she explained, the data has been weaponised: once breached, the code grabs the hacker’s system info, the IP location and other data. “If they’re doing it to us, why shouldn’t we do it to them?” she asked. “The key thing is to figure out how we can get ahead of the threat.”

We couldn’t leave Knight without touching on the small matter of her gaining access to an unnamed bank’s internal network from the comfort of her own car in the parking lot (completely sanctioned, of course). “I just drove up to the parking lot, found their CCTV cameras on the wireless network and jumped straight to their internal network,” she said, making it sound far too simple.

There was a serious side, however. “Humans are always the weak link,” she explained, “and that will likely never change. If it can be made by humans, it can be broken by humans – this bank just didn’t look closely enough at its infrastructure and, like those companies in my app research, forgot the golden rule: implement network segmentation so your IoT devices aren’t on the same network as the rest of your critical production systems.

Please login to comment
  • No comments found