It’s become an “API-first world,” and organizations must act now to take stock of the hundreds or even thousands of application programming interfaces running in their environments, according to API hacker, author and cyber entrepreneur Alissa Knight in a keynote presentation at HackerOne’s [email protected] virtual conference.
Additionally, businesses must better understand how these API connections increase their attack surface area, and what tools and techniques attackers can use to hack them.
APIs effectively serve as translators that allow communication and interaction between various devices and/or apps. “The average business actually runs over 620 APIs… and there's organizations that I've worked with – and work with currently – that have over 1,000 APIs in their environment,” said Knight, who also cited a 2020 Akamai report that found that nearly 20% of credential abuse attacks between 2017 and 2019 were launched against API endpoints.
“As more and more API breaches occur, there's more and more statistics being collected around this,” said Knight, who in recent years has performed a series of authorized, research-related API hacks against connected cars, banks and healthcare institutions.
According to the Open Web Application Security Project, or OWASP, the most common API-related vulnerability is BOLA – broken object-level authorization, which occurs when an application checks to see if a user has authorized access privileges, but doesn’t actually verify that he or she has the correct privileges. Knight likened the scenario to a coat check where the employee behind the counter looks at a person’s claim number but doesn’t notice that the number had been changed with a marker.
“I'm authenticated, I'm allowed to be there because I have that coat check ticket, but I'm not authorized to bring home that [other] person's coat and purse,” said Knight. “So basically, it's the same thing with an API. I'm authenticated because I have an API key or token, but I'm not authorized to request those patient records. I’m not authorized to lock and unlock those doors.”
Knight has rooted out and exploited BOLA and other web and mobile API vulnerabilities using a number of research tools, including Burp Suite, Mitmproxy, the Mobile Security Framework, APK Extractor, Postman, Kiterunner and RESTler. For instance, with the blessing of law enforcement authorities, Knight studied connected police vehicles and identified a slew of API flaws, which gave her ability to remotely lock and unlock car doors and start and stop the engines of any vehicle that had an active telematics subscription with the particular automaker she was investigating.
“If a friend of mine is has been arrested, and they're in the backseat, me being able to remotely unlock those doors so they can jump out is a real problem,” quipped Knight.
Indeed, by abusing one vulnerability, Knight needed only a user’s message ID number in order to send an API request to control his or her vehicle, and then actually approve said request on behalf of the victimized vehicle operator. The tactic works, she said, “as long as you know the message ID that the message was sent to – and there’s an API request that you can send that will lift the legitimate user’s or victim’s messages, and in the list of messages is the message ID.”
“This is the only way that the automaker's authenticating the request” – through the message ID, Knight continued. And what's worse, “it even identifies vehicles as a law enforcement vehicle. Shame. Shame,” she added.
Knight also noted that the car apps did not properly use a process known as certificate pinning, which prevents man-in-the-middle attacks against APIs. Pinning was turned on when she first authenticated, “but as soon as I logged in with my username and password, the pinning was turned off… So all I had to do was disable the proxy on my phone during the authentication process. As soon as I authenticated, I was able to log in.”
Once gaining access, Knight was able to view a slew of hard-coded keys and tokens, including tokens for third parties. “This was shocking to me,” she stated. Indeed, the API server “gave me a total dump from the database of all the vehicle details… It gives you all the information that you need as long as you know the VIN.” And a VIN is easy enough to attain by either physically walking up to a car and taking a photo of it or by iteratively cycling through the possible numbers in a brute-force-style attack, she added.
Knight has presented additional details on these findings in her recently published book "Hacking Connected Cars: Tactics, Techniques and Procedures," at this past year’s DEF CON event and on her own YouTube channel.
And this is not just a police car issue: “While this [research] was commissioned by the police, these [API vulnerabilities] affect every car on the road for this automaker,” and similar issues exist in others cars made after 2001, Knight said. “If you think that you're impervious to being hacked because you don't drive around in a Tesla, think again if your car was made after ’01," she continued, noting that "several of these vulnerabilities have still not been fixed.”
For another hacking research campaign, Knight hacked 30 financial services and fintech companies via APIs in one week’s time. “I could actually change the PIN code of any bank customer or wire funds in and out of the accounts,” she said. “Even deposit money into the accounts – because, remember, banks aren't literally moving paper cash around anymore; it's just moving around ones and zeros.”
But that’s not all: “You didn't even need to be authenticated,” Knight added.
In one instance, she proved to one CISO that she could deposit $10 million into her account. “She almost wrecked her car when that happened,” said Knight. “It rivals the law enforcement vehicle hack. It's right up there.”
Knight said she ended up meeting with the company that developed the API and mobile app for this particular bank – and it turned out this was a biggest issue than she initially realized. “The interesting thing here is: A lot of banks outsource this. And so this company's vulnerabilities was systemic across every single one of its banks,” Knight said. “It was over 100 banks that were vulnerable to this.”