How API attacks work, and how to identify and prevent them

In early May, fitness company Peloton announced that it had exposed customer account data on the internet. Anyone could access users’ account data from Peloton’s servers, even if the users set their account profiles as private. The cause: a faulty API that permitted unauthenticated requests.

Application programming interfaces (APIs) allow for easy machine-to-machine communication.  API use has seen explosive growth lately. According to Akamai, API communications now account for more than 83% of all internet traffic.

They’re also the cause of a lot of security issues. In addition to Peloton, other companies in the news recently for API-related cybersecurity problems include Equifax, Instagram, Facebook, Amazon and Paypal.

API use and attacks growing

According to a report released in February by Salt Security, 91% of companies had security problems last year related to APIs. Most common were vulnerabilities, with 54% of respondents, authentication issues at 46%, bots at 20%, and denial of service (DoS) at 19%.

Eighty percent of organizations do not believe their security tools can prevent API attacks effectively. Salt Security’s survey found that two-thirds of organizations have slowed the rollout of a new application into production because of API-security related concerns. Salt customers, all of whom had web application firewalls (WAFs) and API gateways in place, all had experienced multiple API attacks per month, meaning that the API attacks were getting past those security tools. In fact, according to Salt, WAFs and API gateways miss 90% of the OWASP API Security Top 10 threats.

However, more than a quarter of organizations run critical API-based applications with no security strategy. Peloton, for example, originally made user data accessible via APIs to anyone, anywhere, without any authentication, says Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center. “The first step Peloton took in securing their API was to restrict access to subscribers, but that still meant that any user could access the data of any other user independent of privacy settings,” he says. “Data ranging from a user’s age and gender, their profile image, and some activity data was accessible.”

Leaky APIs aren’t rare. According to the Salt Security report, 82% of organizations lack confidence in knowing API details such as whether the APIs include personally identifiable information (PII) such as customer proprietary network information, protected health information, and cardholder data, and 22% of organizations say they have no way to know which APIs expose sensitive data.

Peloton’s mistake was to use unauthenticated APIs vulnerable to broken object level authentication, says Roshan Piyush, security research engineer at Traceable. Other companies that ran into the same problem include Panera, Fiserv, LifeLock and Kay Jewelers, he says. “And the list goes on.” It usually comes down to overlooked authentication and authorization protection for the APIs in the development process, he says.

One bank’s API growth story

Jeff, manager of cybersecurity technology at a medium-sized financial institution who did not want his last name published, says that his company’s use of APIs has grown dramatically over the past few months. Today, the APIs connect about 3,000 endpoints, which include internal applications and those belonging to business partners as well as customer-facing websites and mobile devices.

That’s just the start, Jeff says. “We’re two years into a five-year expected process and the next three years will be a rapid acceleration. We got a new CISO about 16 months ago, and he comes from the API development side, so he has definitely increased that velocity.”

So far, he says, they’ve mostly been laying the groundwork. “We’re actually on a path right now where we’re on a timeline to eliminate all on-prem data centers and move to web services and APIs for everything,” Jeff says.

The API calls go through four main URLs, Jeff says, with different services including different parameters in their API calls. This approach creates a layer of protection. “With the APIs, due to how risky they were, we actually obfuscated some of our API endpoint names to be harder to do transversal attacks or to do discovery on.” The institution has also been consolidating multiple API gateways into one primary gateway over the past six months.

For the API gateway, the company uses Apigee, an API security vendor acquired by Google in 2016. “This is the one gateway you’re going to use and this is how it’s going to be protected,” Jeff says.

Some companies have had problems trying to get all the developers onboard with a single gateway, or were worried about potential bottlenecks, single points of failure, or DDoS attacks. Jeff says that this wasn’t the case for his institution. “Our developers actually prefer the API gateway method,” he says. “It is SaaS-based and multiregional and actually gives them better availability and lower latency. They don’t have the gateway constraints that a traditional API gateway has because they know it’s going to auto-scale.”

For example, one API was expected to see 10 million transactions a month, but it had 200 million in the first two weeks after it was launched, Jeff says. “They have not felt any latency or any performance degradation.” Right now, the production environment sees about 2 billion API calls a month, he says, up from around 800 million two years ago.

For authentication, the company’s mobile and web-based apps use an older Java technology, Jeff says, “but we’re in the process of moving it all over to an API-based authentication using a software development kit. It’s an important part of our transition right now and has taken multiple departments a lot of collaboration.”

The new approach completely changes how the institution looks for credential-based attacks, Jeff says. For external partners, the company is pushing toward a zero-trust model for its API calls. “We would accelerate it, but we have partners who aren’t ready yet.”

For consumers accessing the institution through its own web or mobile apps, there will be persistence. This means that the consumers won’t need to go through the authentication process multiple times. “Our zero-trust models mean that we do not allow any kind of session persistence, any kind of cookie-ing,” Jeff says. “You must re-authenticate every time. I go back to the basic philosophy that when you want secure, convenient, or fast, you can have two but not all three.”

For APIs that stay within the company’s security perimeter, there’s yet another approach. “Once it’s inside we tend to use other methods other than zero trust that are lighter weight,” Jeff said. “We’re using IP security, depending on where it’s going, service accounts for authentication, doing things that are more Active Directory-based.”

Behavioral analytics are also in place to detect suspicious behaviors both for external and internal traffic and automatic filters for the obvious bad messages. “Being able to separate the chaff from the wheat at the front door allows us to look at the expected good calls more intensively.” Behavior analytics are on the actual transactions themselves, too. “We use everything from IP reputation to behavioral analytics to user and account patterning,” Jeff says. “Say we have a user who gets a $200 deposit every other Friday and now starts depositing $800 checks every Wednesday; we start looking at that. It’s not just for protecting our assets, but to make sure we’re proactively reporting what could be money laundering or human trafficking.”

By using automation, the company’s been able to reduce the number of issues reaching its network operations center and its cybersecurity incident response team by 35%, Jeff says. “Fewer false positives are getting to them.”

To help with this, a little over a year ago the NOC and CSIRT teams deployed Salt Security, used in shared flow with the Apigee API gateway. “It sees all traffic coming to our top-level APIs and then it is learning from those, giving us probable attackers and recommendations for how to improve our code,” Jeff says.

Other teams have also adopted the platform, including the fraud detection team, the development team, and the security architecture team. “It’s allowed us to accelerate timelines on API migrations,” Jeff says.

Bot attacks on APIs

API traffic is growing, but malicious API traffic is growing faster. Salt Security customers’ monthly volume of API calls grew 51%, while the percentage of malicious traffic grew 211%

In an Akamai analysis of a month’s worth of API data from 100 enterprise customers in the financial services, retail, media, and entertainment industries, the company found 744 billion API calls, 12% of which came from known bad actors, and 25% came from end clients that were neither web browsers nor mobile devices or applications, meaning that they could have originated with malicious actors instead of legitimate users.

Traditional front-end applications—websites and mobile apps—have protections in place against attackers, says Rishi Pande, managing director for cybersecurity at Ernst & Young. That includes defenses against DDoS, credential stuffing, and other automated attacks. “Your front end might be protected, but if the API gateway isn’t protected, you can overflow it quite easily,” he says. The space is evolving rapidly with some customers assuming that their technology offers protection, but the tools themselves aren’t quite ready.

The credential stuffing problem doesn’t just go away with APIs, Pande says. “People haven’t solved that problem yet.”

In fact, attacks on the API layer are becoming popular with hackers because it’s more anonymous and the APIs aren’t usually as well protected as website and mobile apps, says Jason Kent, hacker in residence at Cequence Security. Kent once figured out how to open garage doors by taking advantage of a design problem with the garage door company’s API. “In standard website security there’s all this extra code you can run on the client side so you can know if it’s an attacker or a real person,” he says. “In an API we’ve gotten rid of all of that stuff. We’ve really facilitated an attack happening at high speed as often as you’d like.”

Kent says that API security today is about where application security was back in 2009. The way he hacked the garage door API was to look at its mobile application. “The app that you download from the app store is just a bunch of zipped up folders and files,” he says. “It contains a manifest of all the API endpoints it will talk to.” Kent teaches a class in how to do it for OWASP.

Once attackers take apart a mobile app and figure out how it communicates, they can use the same API channel to send requests. AI and machine learning can help defend against this, he says, since the API requests that come through bots look different from those that originate with real human beings using legitimate apps.

Time to shift left

According to Postman’s 2020 State of the API report, which surveyed more than 13,500 developers, only 36% of companies do security testing of their APIs—compared to 70% who do functional testing and 67% who do integration testing. According to SmartBear’s 2020 State of API report, availability was the single biggest concern developers had when it came to their APIs, followed by functionality, with security in third place.

Part of the problem is that development teams are often separate from the security teams, who are separate from the networking and infrastructure teams. “The solution to the silos is DevSecOps,” says Albert Whale, senior cybersecurity manager for Capgemini North America. “Now we can integrate testing and give that testing control to the application developers. We make everyone a member of the security team.”

Whale says that creating more secure applications from the start is more important than trying to secure things at the end with technologies like API gateways. “I see an API gateway as a single point of failure,” he says. “It’s going to slow down the application because it has to collect all the information to funnel it back out. That’s not saying that they’re terrible, they fit their need just like a web application firewall would, but there are times to use them and times to scale beyond them.”

Instead, Whale says, companies should focus on better architecture, better security, and better API calls. “It takes longer to do that, but better coded applications are what you need for better protection. When you can make an application robust enough to resist attacks, you don’t need other elements to provide additional security.”

Developers are starting to become more aware of security, agrees Mike Rothman, analyst and president at Securosis, a cybersecurity research firm. “We’re seeing DevSec to try to get people to collaborate,” he says. “Does it always happen? Not every time, but we’re trying to break down a lot of those silos and break down the walls and get teams working together.”

When it comes to API security, there are multiple areas of vulnerability, Rothman says. It starts with business logic. “This is one of those key aspects of application security that I can’t tell you we’ve ever gotten right.” With monolithic applications being broken up into small services connected by APIs, the challenge of finding and mitigating against logical issues is magnified. The application could be working exactly as it was designed, the authentication mechanism can be perfectly secure, it might be completely free from vulnerabilities, but if there’s a problem in the coding then a breach could still occur.

Then there’s the standard set of vulnerabilities to watch out for. The OWASP API Top 10, released in 2019, hasn’t changed in the last two years, says Rothman. “We continue to have the same problems over and over again,” he says. “Then we need to defend the environment at multiple levels—traditional network technology, traditional application security technology.”

Finally, organizations need to look at tools, automation, scanning technologies, and telemetry monitoring because there aren’t enough people to monitor API security manually. “We have to leverage what we have and people are not it,” Rothman says. “Have monitoring to determine how the APIs are being called and look for anomalous behavior that could indicate malicious misuse.”

Warehouse firm gains API security visibility

It’s become easier than ever for developers to spin up a web service and set up APIs. As ever with new technologies, security often lags behind.

Even if developers are all onboard with new security controls, there might still be old systems hanging around. These outdated and zombie APIs present a great risk, as do APIs that were expected to be short-lived but never got decommissioned.

“You can’t protect the things you don’t know about,” says Tyler Warren, director of security at Prologis, a warehouse company. “Looking at some API security solutions out there, you had to know what you had in order to protect it. That was already a non-starter because discovering what we had was the first priority.”

Warren, who is responsible for Prologis’ API security program, says that his company first started developing customer-facing systems just four years ago. “We own almost a billion square feet, about 5,000 warehouses in 19 countries,” he says. “When people hear that you’re a warehouse company, they say, ‘What could you possibly be doing that’s high-tech?’ But management has decided that technology is a business enabler, not a cost center.”

So, Prologis changed. Four years ago, the mindset in the warehouse sector was, “Here’s your four walls and a roof, here’s your keys, come talk to us in a few years when your lease is renewed,” says Warren.

Now, there’s the cloud-based Prologis Essentials platform, which allows customers to submit service tickets or check the status of the invoices, but more importantly, to connect with local suppliers that provide pest control, forklifts, lighting, and other products and services needed when someone moves into a new warehouse.

Since it was a brand-new service, with no legacy systems to deal with, Prologis started right out with a cloud-based, serverless architecture. “We even skipped containers,” Warren says. “We’re almost exclusively serverless. We are primarily Amazon and lambda functions.”

Prologis Essentials uses the AWS API gateway, and has about 15 APIs serving 500 endpoints, Warren says, which includes internal connections as well as integrations with outside business partners. Last month, the system processed 529,000 API requests.

What he discovered was that AWS doesn’t provide much information about what’s going on with the APIs. “AWS itself doesn’t give you that information,” says Warren. “We tried some legacy ways but a web application firewall doesn’t work, though it gives you a little bit of protection if you don’t have anything else.”

Warren looked for a technology that was easy to deploy and didn’t get in the way of the development team. “Once you’ve messed up that relationship you’re in trouble,” he says. “If you become the security guy who says ‘no’ they start to bypass you. So, the solution has to fit in their workflow and not create any additional work for them.”

Prologis chose Salt Security. They originally planned a 2021 rollout, but decided to do it in 2020. “The API attack surface is getting more attention out there,” Warren says. “The bad guys have figured out that there’s a lot of attack surface.”

It took about a month to get Salt Security in place for the Essentials system. “A lot of it was testing,” he says, “and making sure the developers were okay with it, making sure there was no impact to performance.”

The tool sits within the AWS environment and listens to the traffic at the API gateway, grabs logs and metadata, and ships reports to Salt’s SaaS dashboard for alerting and reporting. “I originally guessed we had 100 API endpoints,” Warren says. “It ended up that we had 500. Usually, I have a pretty good idea of what goes on in the network, but I missed that by a long shot. That’s a common problem in the industry—people drastically underestimate what they have.”

The system was up and running last fall. Eventually, it could connect to WAFs and automatically trigger actions. Right now, it sends reports for security staffers to manually look over. “The last thing I want to do is block legitimate traffic,” Warren says.

The system also looks for potential PII leaks, Warren says. For example, he was alerted that AWS private keys might be leaking, but that turned out to be a false positive. “We have account numbers that look like AWS keys, but that was a coincidence.”

The system also caught some cases where APIs provided more information than was strictly necessary. “Say a combination of an email address and an account number that wasn’t necessarily sensitive,” he says, “but I’m all about ‘if you don’t absolutely need it, don’t do it.’” That’s advice that a lot of companies should be following when it comes to APIs.