How to use Runtime Security to protect risks to both APIs and legacy COTS

It used to be that the weakest link in the enterprise IT security chain was the user, but times have changed. 

Nowadays, the weakest link is bifurcated: One prong consists of vulnerable/misconfigured application programming interfaces (APIs). The other is vulnerable legacy commercial off-the-shelf software (COTS). Adversaries — frequently, nation-state adversaries such as groups from China, Russia or North Korea — are constantly scanning for vulnerable applications and APIs. 

First, a look at what sets APIs apart:

Why APIs rank high on the vulnerability risk scale

Most organizations are only aware of a fraction of their APIs. You can see why, given the pace of modern software development: It’s nearly impossible to tally a moving target, with APIs often added or changed on a weekly basis. 

There are at least three special problems with traditional security scans that affect API security: 

1. a lack of continuous testing,
2. a lack of visibility into the routes actual users take in the software and data structures needed to test the API, and 
3. a lack of actionable information to help prioritize the riskiest vulnerabilities for quicker remediation.

Spring4Shell is an example of how securing APIs is drastically different from securing applications. On March 29, 2022, a Chinese cybersecurity research firm leaked full details of the attack, which could have impacted most enterprise Java applications globally. VMware, the company behind Spring — the open-source application framework that provides infrastructure support for developing Java applications —  announced the remote code execution (RCE) vulnerability two days later. 

Within days, Spring4Shell had been weaponized. By April 11, security researchers had observed that malicious actors had weaponized and executed the Mirai botnet malware on vulnerable servers.

Spring4Shell is an important example of how securing APIs differs from securing applications because the vulnerability was, quite simply, nobody’s fault. There were good defenses in place both for Spring and for the developers writing the code. What ratcheted up the gravity of the problem was an interaction between components: Namely, changes to the Class object in Java 9 rendered inadequate the checks Spring performed to ensure that attackers can’t control any parts of the Class, ProtectionDomain and ClassLoader of the object graph instance being created.

While APIs are just as hackable as traditional web apps, many are surprised to find that securing APIs isn’t the same as Application Security (AppSec). You may well think that our current security tools are appropriate for APIs, but they’re far from it. Static Analysis Security Testing (SAST) and Dynamic Analysis Security Testing (DAST) — where the scanners lack visibility into just what, exactly, they’re scanning — were designed for web applications from the early 2000s, and they haven’t advanced much since then. 

And now for the other prong: unpatched COTS.

Unpatched legacy COTS: A ticking time bomb

An exploitable vulnerability that exists in production is an attack that’s just waiting to happen. … Or, as the case may be, one that hackers are already scanning for and actively exploiting. 

One example: On Dec. 5, 2023, the Cybersecurity & Infrastructure Security Agency (CISA) warned that hackers are actively exploiting a critical vulnerability — CVE-2023-26360 — in Adobe ColdFusion to gain initial access to government servers.

This flaw was exploited as a zero day before Adobe fixed it in mid-March by releasing ColdFusion 2018 Update 16 and 2021 Update 6. At the time, CISA published a notice about threat actors exploiting the flaw and urged federal organizations and state services to apply the available security updates. Now, months later, CVE-2023-26360 is still leveraged in attacks, including incidents from June that impacted two federal agency systems that were running outdated versions of software that were vulnerable to what CISA said was “various CVEs.”

Adversaries constantly scan for exploitable vulnerabilities not only to exfiltrate data and commit espionage but also to conduct island hopping — a term that describes the act of hijacking an organization’s digital transformation and using it to launch attacks against its customers and partners. 

In island hopping, an adversary infiltrates the corporate environment via application attacks and then uses that access to launch attacks against the victimized organization’s customer base. Besides the ColdFusion attacks, another recent example of the dangers of unpatched COTS is Operation Blacksmith: the name that Cisco Talos is using to track the activity of the notorious North Korea-linked threat actor known as the Lazarus Group. As the cybersecurity company reported in early December, the group is exploiting security flaws in Log4j to deploy previously undocumented remote-access trojans (RATs) on compromised hosts. 

This latest campaign from Lazarus — which for years has been North Korea's most prolific cybercrime crew — is particularly concerning, given that many organizations still harbor the Log4j vulnerability in their software stacks. At this point, two years after the Log4Shell vulnerability came to light, firms still struggle to hunt down the vulnerable Log4j library: According to Veracode, one in four applications are still vulnerable.

You don’t have time to find these vulnerabilities

The days when you could take your time addressing vulnerabilities such as Log4Shell in code — be it open-source or COTS — are gone. Attackers are weaponizing vulnerabilities in a matter of days. Leaving a vulnerability unaddressed turns an organization into a sitting duck. 

In the eyes of adversaries, if you're an organization that does business with governmental agencies, you’re a high-value mark, and you will be targeted. In the case of a successful exploit, your business will be used to island-hop into the government agency itself.

How to secure APIs and apps if you can’t update COTS

Organizations often try to bury their software behind multiple layers by employing (hopefully automated) vulnerability management processes and capabilities. They’ll insulate their apps with micro segmentation — i.e., they’ll divide the network into segments and apply security controls to each segment based on the segment's requirements. The point is to limit the number of environments that end up compromised, by putting systems behind multiple parameters so as to slow down an attacker’s path to exploitation. 

Organizations will also invest in security tools such as an Intrusion Detection System (IDS), so as to look for behavioral anomalies on the network or endpoint that may indicate attempts to exploit the system. They'll also conduct penetration testing to discern whether those systems are actually exploitable. Then, they’ll use the relevant attack paths to harden access to the system. 

These are all worthwhile aspects of defense in depth, but they’re not enough. What organizations should be doing is employing Runtime Security. Here’s why: If a network attack has been achieved, the adversary already has a footprint on the network, because they successfully exploited an endpoint that was using unpatched COTS. At that point, it’s almost too late, because most adversaries will be using the defender’s own authentication, authorization and encryption against the defender itself.

Blinded by your own security

Encryption is like a steel tunnel. You won’t be able to unpack the encrypted traffic. If the attackers are using your own encryption against you, you won’t be able to unlock it to see what’s happening. It becomes a Pandora’s box: You have no visibility into what's going on in your steel tunnel, where the attackers will freely interact with the application to basically bypass things like IDS.

This is why AppSec needs to go further than it currently does. It’s why Runtime Protection should be mandatory.

Seeing past steel tunnel walls with Runtime Security

 The root problem is that there are thousands of functions in the typical software stack that are both dangerous in use and totally unprotected. It’s impossible for a developer to know all the dangers and risks associated with every function they use in development. An entire market of acronym processes and siloed toolsets was created to mask this problem without really solving it. 

With the power of instrumentation, Runtime Security protects these dangerous functions with trust boundaries embedded throughout the entire software stack. These trust boundaries warn developers if functions are used unsafely, determine if libraries are vulnerable and exploitable, reveal security blueprints by observing function use, detect attacks, and prevent exploit attempts. 

Runtime Security is a proven game changer. Case in point: Runtime protection (RASP) has a track record of securing against Log4Shell even before anybody knew the RCE vulnerability existed. It’s akin to endpoint detection and response (EDR) or network detection and response (NDR). Unlike traditional methods — such as SAST, DAST or WAFs — Runtime Security focuses on real-time evaluation of an application's behavior, automatically identifying and thwarting any anomalous activities. This proactive approach doesn't rely on knowledge of specific threats but instead focuses on preventing any behavior that deviates from the norm.

Toward the goal of making Runtime Security mandatory, a great first step would be for CISA to enhance its recent recommendations regarding Group Lazarus to include the need for Runtime Security. 

It’s simply the best way to harden the application stack with trust boundaries and to radically improve organizations’ security posture, protecting applications from threats on both unpatched vulnerabilities and emerging zero-day exploits. 

Watch a video by Jeff Williams, CTO and Co-founder of Contrast Security's Runtime Security Platform, to see how application vulnerabilities are observed and contextualized and how you're guided to fix them throughout the development life cycle. 

Read more:

• Attack-path mapping your applications  | Contrast blog 
• False positives + false negatives = real costs  | Contrast blog 
• Let’s talk stats: Why AppSec’s running on broken math  | Contrast blog 
• Don’t throw good AppSec money after bad | Contrast blog
• It’s time to replace our broken AppSec tools with something that actually works: Runtime Security  | Contrast blog

This article first appeared on SecurityInfoWatch.com.