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."