InfoSec Insider

APIs Are the Next Frontier in Cybercrime

APIs make your systems easier to run — and make it easier for hackers, too.

Application Programming Interface (API) usage has exploded, and cybercriminals are increasingly taking advantage of API security flaws to commit fraud and steal data.

APIs, which are used to create connections between software programs and perform integrations, make everything a bit easier — from data sharing to system connectivity to delivery of critical features and functionality — but they also make it much easier for the bad actors (and the bad bots they deploy) to carry out attacks.

Let’s explore some of the API vulnerabilities that get exploited and abused by hackers, and I’ll share some easy tips for you to consider to close those gaps.

Too Easy to Discover

When I’m in hacker mode, the first thing I do is identify as many APIs as possible. I start by using the target application as expected. Web applications get opened in a browser; mobile apps are download and installed. All the while, I monitor the communications with an intercept proxy.

The intercept proxy catches all the requests my browser or mobile app makes to the backend webservers, allowing me to catalog all the API endpoints available. For instance, most APIs have /API/V1/login as an authentication endpoint.

If the target is also a mobile app, I take the application package apart and look at the API calls available inside the application. With all the possible activity in view, I can search for common misconfigurations or APIs that don’t protect user data correctly.

Finally, I look for API documentation. Some organizations publish API documents for third parties, but use the same API endpoints for all users.

With a decent inventory of the endpoints, I can test both standard user behavior and abnormal behavior testing. You can find interesting vulnerabilities through both methods.

The Fix: To make the discovery of your APIs more difficult, ensure your API documentation is gated and controlled with entitlements that only allow access to valid users. While pinning the certificate on a mobile application doesn’t completely hide the API endpoints and isn’t perfect, it does add an extra step. API requests to the web server should be as obfuscated and controlled as possible.

Too Verbose

Lately, we’ve been watching account takeover attempts increase at our customers. These types of attacks are made easier by error messages that are too wordy for their own good. Having a verbose error message guides the attacker to learn what they need to change to make the request work. APIs, designed for high-speed transactions with low load, enable attackers to use high-performance systems to figure out valid accounts and then attempt to login and change the passwords for their benefit.

The Fix: Don’t tell me what I did wrong; Even if it seems like good user experience, it’s bad for security. I shouldn’t be able to send in a bad username or bad password and have that system tell me which information is wrong (i.e., Account not found or Password incorrect). The same goes for error messages for queries of the data; if the query/search isn’t formed correctly or cannot be performed for whatever reason, “OOPS, Something Went Wrong” should be the only information provided.

Too Many Parameters

As attackers iterate through API calls to attack systems, they have to figure out what they can send in to get data out. Attackers are counting on the fact that complex systems have more places for failure. Once an attacker identifies an API, they’ll catalog the parameters and then attempt to access the data of an administrator (vertical privilege escalation) or another user (horizontal privilege escalation) to gather additional data. Often, too many unnecessary parameters get exposed to users.

In a recent research project, an API call to a target service sent me back a massive amount of data. Many of the data elements weren’t needed, like the processor key for a payment gateway and the discounts available, and shouldn’t bleed through. These bonus elements provide a better understanding of the context and the syntax for those API calls. You don’t need much imagination to figure out what to do next; these extra parameters give the attacker rich data sets to attack.

The Fix: If you limit what the user can see to only what’s necessary, limit transmission of critical data and keep the data query structure unknown, you’ll make it far harder for an attacker to brute-force requests to parameters they know exist.

Too Much Data

Along the same lines as too many parameters available, the concept of gathering data becomes an obvious next step. Many organizations make their systems available for anonymous connections and tend to leak data the average user doesn’t need. In addition, many organizations tend to store data that can be accessed directly.

Security professionals struggle with the challenge that API requests often reveal data-store locations.  For instance, when I look at videos from my security camera, I can see the information comes from an Amazon S3 bucket. Often those S3 buckets are not secured correctly, and anyone’s data can be retrieved.

Another common data challenge is that organizations tend to be pack rats, storing much more data than is needed. While data about clients who are no longer clients, or old case notes with sensitive information, may no longer provide business value to your organization, they could be very embarrassing and harmful if breached.

The Fix: Thorough data reviews are a must for any organization that stores any data, not just PII or PHI. After reviewing the data that’s stored, data-access requirements should be put in place and tested. Make sure that the data that is accessed anonymously is data that should be accessed by everyone.

Too Little Design for Security

Application design almost always considers functionality and usability but, all too rarely, security. We’ve heard from CISOs that API security, in particular, gets left out of the design process entirely. Instead, they let developers build and deploy and then look for issues once the API is in production and vulnerable. Security, including API security, needs to be part of the design and should be implemented as one of the first considerations, not bolted on later.

The Fix: If you haven’t reviewed the security architecture of your application, it’s a significant first step to moving toward a secure system. Remember, APIs make attackers more efficient as well as make the use of your system more efficient. The goal of designing for security is to change the bias to just building efficiency for your users, not your attackers.

I know I’ve only provided a small view of the common API vulnerabilities. The important thing is to have security come up in discussions early in the development process. Small changes can yield significant benefits, or at the very least, shield you from financial losses and humiliation resulting from API breaches.

Jason Kent is Hacker in Residence at Cequence Security.

Please check out all of the latest posts in our Infosec Insider Community.

Suggested articles

Discussion

  • Jesse on

    Well written description providing some insightful and thought provoking details. Thanks for sharing!
  • Anonymous on

    Any interest in telling the audience what an API is?
  • Ducktales on

    Nice read, supprised me when I stopped believing in short forms available in internet.
  • diwakarma on

    Well written description for an API and its security, however, I don't see any harm on exposing API documentation as long API is handling security using handle, token, etc and well-sanitized inputs. Your thoughts?
  • Jason on

    Thx for the comment and the feedback. API documentation is a critical part of the secure development process and I think you need to strike the right balance between too much or not enough. For example, your team needs to understand if the data returned is useful or could be part of an attack chain. In almost every case of API abuse that I have seen, API documentation access has would accelerate the attack development and execution. If an API has been mis-classified and left unprotected, access to the documentation would allow bad actors to quickly execute API abuse that is highly accurate due to advanced knowledge. I recommend utilizing API documentation to see what is possible and start developing tests for security flaws. Unprotected APIs and Available Documentation can mean a perfect storm of 2+2=5 where having those items can equate to an attack greater than the sum of its parts.
  • Husain Khan on

    A ton of common sense in the article. Great read. And alas, the same issue and fix: security not considered until the very end and then bolted on afterwards. The fix is to include cyber security from concept and requirements all the way to production and maintenance.

Leave A Comment

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.