Attackers: Modern Day API Cartographers
Attackers are like modern-day cartographers. The cartographers of old weren’t necessarily sailing the coastline of New England, drawing a map as they sailed. Instead, they talked to people who did the sailing. Before they drew a map, they picked brains, plied sailors with strong drinks, gathered information and sifted through contradictory claims to build their mental models. Today’s attackers work in a similar fashion. But the map isn’t New England, it’s your API, and the reason they’re drawing that map isn’t for exploration, it’s to steal your data. In the ThreatX SOC, we’ve learned much about their tactics and techniques. Here are some of the most common ways we see attackers trying to compromise APIs.
Hunting to Exploit
Attackers will hunt for any available open source information. Old developer notes, or even one of your developer’s Stack Overflow posts, could contain paths to endpoints that shouldn’t be exposed to the public. Additionally, there are a lot of tools that can identify the kind of tech stacks you have. For example, a tool like Wappalyzer could tell an attacker what kind of database you’re using, which they’ll use to inform their tactics.
Watching APIs in Action
Attackers want to see what is being sent to an endpoint so they can understand the structure of the requests being made and the schema that is used. When that’s unavailable, they will lean heavily on documentation, or try to access the web application that’s interacting with that API endpoint.
There are tools like Burp Suite and Zap that attackers use to see the interaction between a web application and an API. These tools are a proxy between your web application and API and essentially act as a man-in-the-middle. It makes it convenient for attackers to profile your API and collect information about what normal traffic looks like. These tools also provide the ability to make changes to the traffic that is flowing through them.
Fuzzing is another important method for attackers to use when assessing how an endpoint interacts with anomalous data. Fuzzing tools allow attackers to inject a variety of inputs into a system in an automated way to reveal potential software defects and vulnerabilities. Burp and Zap have fuzzers built into them; dirb, dirbuster and ferroxbuster are other popular options. These fuzzers can aid an attacker in identifying common endpoints or methods leveraged by an API.
For APIs specifically, attackers will use Postman in conjunction with proxy tools. This tool allows attackers to craft payloads and is commonly used to repeatedly interact with an API.
Testing the Possibilities
Attackers will push the boundaries of your endpoints and try to compromise their intended behavior. Maybe you think your endpoint will only accept strings, but they’re going to try integers, they’re going to try a boolean, they’re going to try all different kinds of input types. And maybe your endpoint does accept strings, but it only accepts 20 characters, but they’ll try 200 characters. Attackers are very creative and come up with unique inputs that your engineers never thought of.
Attackers will also try to figure out what they can access. Maybe you only wrote this API thinking that a machine would interact with it, and so it’s only going to glean information. But an attacker will try to edit or delete the information or make it appear differently under certain circumstances. Ultimately, when we’re protecting endpoints, we must be right all the time, but attackers only have to be right once!
Not If, When Attackers Target
It’s not if attackers are going to target your APIs, but when. They will target anything on Layer 7. Enumeration, fuzzing, reverse engineering, injections, broken authentication, all of these tactics will come together in some form of an attack, whether it be from one IP or millions.
Preventing API Attacks
Being prepared is ultimately about security in depth as layers of security are needed to protect against modern attacks. Below are some suggestions for both engineers and security practitioners.
For engineers, give security a seat at the table when designing new software. Having a security professional in the room during design is going to make the development team more security aware and build security in the product with an attacker-centric perspective.
Additionally, ensure input sterilization. Every single input you have, every key-value pair in API needs to have sterilized input. If possible, create an allowlist of acceptable and expected input.
Keep track of your API versioning strategy. If you deprecate an endpoint, make sure those artifacts aren’t deployed on some container somewhere, even in your dev environment. Those become prime targets for attackers as “zombie” APIs. Security teams can assist with this by tracking, managing and updating an inventory of all APIs and their versions.
It is also important to be thoughtful about privileged access models. Understand which roles are intended to perform particular actions and ensure that any deviation from that intention is both blocked and logged for later audit.
Security teams should create abuse cases to validate attack mitigation techniques and regularly test applications using static, dynamic and manual techniques.
Working together, both engineers and security teams can throw attackers off the trail of your APIs. By establishing layered security and defensive perimeters, that buried treasure will be harder to come by.
