Stopping API Attacks: Columbo, Correlation, and Context

‍A master of context

Columbo was a master of context. The lieutenant was famous for his catchphrase “Just one more thing,” heard countless times by suspects as he chipped away at a case, gathering small, obscure pieces of the puzzle and putting them together to form the bigger picture and ultimately solve the case. Each piece of the puzzle in isolation looked insignificant, but the bigger picture started to emerge when Columbo correlated a series of seemingly unrelated events.

These complex cases had no single “smoking gun.” Gathering all the clues and correlating them, to understand the whole context, was the only way to solve the crime. 

So it goes with API attacks. These events involve a similarly complex series of events, uninteresting when looked at in isolation but very revealing when put together.

The “low and slow” nature of API attacks

To attack your APIs, hackers have to learn them – they use reconnaissance techniques to understand the structure and logic of your APIs. The attacker’s ultimate goal is to find a vulnerability, manipulate the API logic, and make the API do what it was not intended to do – such as return all of the data from a database instead of the info for just a single user.

Reconnaissance takes time as the attacker probes the API to map out the structure, determine the application components in use, understand the API logic, and look for vulnerabilities. Reconnaissance can take hours, if not days or weeks, as the attacker uses subtle methods to achieve their goal while avoiding detection.

Attackers don’t need special access to begin probing an API. Any public-facing application such as one from an online retailer, ride-hailing service, social platform, or cloud service will expose an API, and that API will, necessarily, expose its structure and logic. The attacker needs only an account, which can usually be set up within minutes. Even an API that is considered private or more restrictive isn’t immune to an attacker’s prying eyes. Any determined attacker will find a way to access credentials through phishing or other means.

Once attackers gain access to an API, they need only creativity, tenacity, and a few commonly available tools that aren’t limited to just the dark web. Attackers use the same tools your developers and QA teams use to debug and test your APIs.

Attackers start with activity that looks like any other user as they map the API’s structure and uncover its unique logic. They make slight tweaks to API calls to see how the API responds, and none of this activity raises a flag or triggers a security alert. In fact, attackers targeting APIs will use subtle methods to stay under the radar as much as possible, sending calls to test API logic such as:

• What if I replace my user ID with another user ID? Can I access the other account?
• What if I enumerate an object ID? Can I access information that I’m not supposed to? 
• What if I try to escalate my user privileges? Can I get admin rights?

Reconnaissance is a process of little successes and many failures. Looking at this activity in isolation, one transaction at a time, doesn’t reveal any risk, but putting the pieces together can provide meaningful context and insight that someone is probing your API and up to no good. 

Traditional security and API tools lack context

Attacker reconnaissance activity looks like normal API traffic to traditional tools such as WAFs and other proxy solutions. The architecture of these tools limits them to inspecting transactions one at a time, in isolation, and they depend on signatures to detect well-known attack patterns such as Cross Site Scripting (XSS) and SQL Injection (SQLi). If the transaction does not match a signature of a known attack, the WAF will send it through. Since each API is unique with unique vulnerabilities, signatures cannot help prevent API attacks. Tools such as WAFs not only miss the attacks that target unique API vulnerabilities, they also miss the hallmarks of an attacker’s reconnaissance activities.

Going back to the Columbo example, using a WAF to stop an API attack is like using a red light camera to solve a crime. While these tools might be good at identifying specific, predictable, malicious activity, they cannot collect large amounts of data, identify broader clues, or put the pieces together to solve, or better yet, prevent a crime.

Architecture is key

An attacker’s reconnaissance activity – when successfully detected and correlated – provides clear warning that someone is probing your API and up to no good. But to detect this activity, solutions need context that cannot be learned looking at each transaction in isolation. Solutions must analyze as much data as possible to understand normal behavior, identify the outliers, and put together the pieces to form a bigger picture. Proxy tools lack big data, artificial intelligence (AI), and machine learning (ML) – so they cannot gather and analyze large amounts of data. 

It’s not enough for solutions to identify outliers from normal behavior. Solutions must differentiate between user mistakes or behavior that changes in response to a changed API vs. malicious activity, such as an attacker probing an API and manipulating API logic. Theoretically, a WAF could be configured to alert based on each outlier event, but they’re never configured in this way because organizations would be crippled under the overwhelming number of false positives.

What’s needed is the ability to put together the previously disparate outliers to gain a picture of attackers and their activity risk. Knowing that a single entity has generated a large number of errors is one clear indicator of an attack – WAFs don’t hold that kind of information correlated over time, and they don’t understand the risk of anomalous activity either.

Salt Security – the Columbo of APIs

Just like Columbo, Salt Security correlates disparate pieces of behavior and uses the resulting context to pinpoint attackers. Unlike WAFs, Salt uses big data to collect API traffic and applies AI and ML to analyze activity. 

Through analysis, Salt creates a baseline of normal behavior and identifies anomalies. With the context it’s able to create, Salt differentiates between API changes or simple mistakes vs. malicious attacker activity. Correlating activity allows Salt to pinpoint attackers and stop them early in their reconnaissance process to prevent successful attacks.

The Salt alerts contain the context incident response teams need to understand and respond to events quickly. Salt alerts contain the full timeline of attacker activity, so teams gain insight into what the attacker did and how the application responded. Teams have no need to correlate information manually.

The context Salt provides is also essential to helping development teams eliminate vulnerabilities quickly. Remediation insights from Salt contain details on the location of a vulnerability and what normal activity looks like for that API as well as recommendations on how developers can close the gap and improve the security posture.

Want to see Columbo on the hunt in your environment? Request a personalized demo to see how Salt uses context to protect APIs, prevent attacks, and improve your API security posture.

‍

*** This is a Security Bloggers Network syndicated blog from Salt Security blog authored by Chris Westphal. Read the original post at: https://salt.security/blog/stopping-api-attacks-columbo-correlation-and-context