Introduction
It is a well-established fact that an unprotected computer left exposed on the Internet, will be attacked in under seven minutes. The presence of unpatched vulnerabilities on an Internet facing application, very quickly makes the computer unprotected.
In 2021 alone, over 28K new vulnerabilities were disclosed into vulnerability databases. ~8K of the disclosed vulnerabilities had publicly known exploits and 5.8K of these vulnerabilities could be triggered remotely from anywhere in the world. It is safe to say that most organizations would not have patched these vulnerabilities in the first seven minutes of disclosure. Certainly not ~5.8K times during the year. This is an existential threat and those enterprises that escaped being attacked, should count their blessings.
What makes this situation even more dire is that many highly skilled attackers and clandestine organizations in nation states are not exactly rushing to the vulnerability databases to report their findings. The window of exposure for such vulnerabilities is even longer since no patch is forthcoming until the attacker chooses to make it public.
Perhaps there is a lesson to be learned here from this military strategist who very astutely observed:
If you occupy terrain, you control that piece of ground as well as everything around it. If you monitor a piece of ground, you control nothing. Technology is wonderful but does have limits. What good does it do to be able to monitor an area but not be able to respond to threats in a timely manner. Then too, control of an area forces opposing forces to respond in a predictable way and denies important facilities, infrastructure, and opportunity to him. Not being in critical areas places one’s forces on the defensive without the means to revert to the offense in a timely fashion to prevent or oppose moves by one’s opponent.
In this war on cyber security, those solutions that occupy the battleground i.e., the application’s runtime memory, will control the narrative. These solutions are not forced into “responding” to attackers long after they have come and gone.
How do attackers operate?
The kill chain shown below describes the progression of a cyber-attack from an attacker’s perspective.
The attacker starts by using a search engine, like Shodan, to find victims who may be running a specific version of an application for which the attacker has a functional exploit. On identifying a victim, the attacker composes a strategically crafted malicious payload that will confuse the application and allow the attacker to gain execution control. At that point, the attacker has gained the ability to send machine code into the victim’s CPU. Next, the attacker delivers a carefully crafted malicious payload to the victim workload which immediately buckles over and responds to the attacker’s commands. Armed with the ability to run the malicious code in the application’s runtime memory, the attacker goes on to install a piece of malware known as a reverse shell. This code provides the attacker the ability to interactively control the victim. The attacker can now install even more malware, escalate privileges, perform lateral movement, examine the victim’s file system, erase logs, slowly exfiltrate data, etc. The ability to erase logs plays a very special role since most Endpoint Detection and Response (EDR) solutions rely on logs to detect attacks. Once the attacker is fully locked and loaded, they will start unleashing attacks of their choosing. Fast-acting attacks such as ransomware attacks, coupled with previously exfiltrated data are the attacker’s ticket to cashing in on massive financial gains.
An astute reader will notice that Steps 4 through 7 will precede any future and unpredictable malicious actions that the cyber-attacker will undertake in the future. If the attack is not terminated within stages 4 to 7, it will be too little too late. At that point, the attacker has gained full control and can easily deliver arbitrary code that will blindside any security solution.
Why do conventional security solutions fail to protect vulnerable applications?
Most enterprises will deploy two broad classes of security solutions as described below. In either case, a clever attacker who has gained the ability to execute code in the victim’s runtime memory can easily take advantage of the protection offered by both categories of solutions by dispatching disguised data that they can convert, on a dime, into malicious code in the application’s runtime memory. Effectively, the attacker has an encrypted channel that neither category of security solutions described below can defend against. Just recently, we saw that until a specific threat signature was posted on December 7th, 2020, the attackers were able to dwell in the SolarWinds infrastructure since September 2019; a period lasting almost fifteen months.
The first category of security solutions is broadly described as pre-execution solutions. A few embodiments of this category include, Intrusion Prevention Systems (IPS), Next Generation Firewalls (NGFW), and Web Application Firewalls (WAF). The common theme that cuts across these tools is that they examine incoming network traffic looking for well-known attack signatures and behavior patterns that are sourced from one or more threat feeds.
To make matters worse, not only the false positive and negative ratios of these pre-execution security solutions is very high, but they also require a lot of manual nurturing and feeding as newer indicators of compromises arrive via threat feeds. The army of analysts that provide such nurturing often costs more than the security solution itself. That said, the one thing that these solutions do well is to defend against volumetric threats.
The second category of security solutions are broadly described as post-execution solutions. An embodiment of this category is the EDR product. These solutions leverage logs from user (login, as well as regular) activity, network activity, file system activity and process creation/ termination activity to determine if such activity matches the activity associated with the execution of known malware or threat actors. Since EDR solutions rely on logs and other circumstantial data, they are always behind the eight ball and the attacker is almost guaranteed to succeed. An attacker can take full advantage of a vulnerability in the application to install new malware directly in memory leaving no footprint on the disk, erase logs and launch devastating attacks such as a fast-acting ransomware attack to totally blindside EDR solutions. The goal of this category of solutions is to minimize attacker dwell time, but any dwell time is too much. This is of no comfort to end-users who would rather get true protection.
Unfortunately, neither pre-execution nor post-execution security solutions can offer deterministic protection that stops an attack before the attacker reaches stage 8 of the kill chain.
What is the ideal solution to this problem?
What application users need is a Deterministic Protection Platform (DPP) that will reliably protect even those applications that are riddled with vulnerabilities. Imagine a world where cyber security is irrelevant, and businesses grow their services without the lingering fear of being attacked!
How do we get there from here?
If the past 30 years of experience has taught us one thing, it is that today’s cyber security solutions just cannot reliably prevent vulnerable applications from being exploited.
Let us unpack the ideal characteristics of a DPP solution. A good DPP protects the application’s runtime memory by:
-
Ensuring that when the time comes, only such code that was delivered by the Application Provider will load into the application’s runtime memory footprint
-
Imposing the Application Provider’s Intent during the lifetime of the application
-
Automatically engaging protective actions so that the attacker cannot gain a foothold
-
Not being dependent on periodic threat signature updates
-
Not being dependent on availability of source code
-
Not degrading the performance of the application
How does Virsec’s implementation of DPP work at a high level?
Several first principles enunciated in Virsec’s 30 patents and counting, power Virsec’s DPP implementation.
Let’s start with an analogy to a GPS enabled vehicle. As the driver punches in a destination, the GPS instantly extracts an intended navigation path for the driver to follow. Then as the driver negotiates the roadways, the GPS actively tracks the driver’s operations, one step at a time. Even a small deviation from the intended navigation path results in the GPS detecting the deviation in real time.
What if the driver stopped for a coffee break and on returning to their vehicle, a car jacker also got into the car and then at gunpoint forced the driver to drive to a completely different destination? Now that the driver is executing attacker intent, which is different from the original intended navigation path, the GPS will complain immediately and vociferously.
Virsec’s Application Provider Intent is conceptually like the GPS’s intended navigation path. Once an application has been delivered to end-users, its Application Intent does not change. Let’s take an example of a calculator. When we add 2 + 3, the answer is 5, today, tomorrow, and even five years from now. A user can change the input data, but the underlying code invoked by hitting the + key on the calculator does not change. This is one of the first principles that powers Virsec’s DPP implementations.
Just like the GPS, Virsec’s DPP implementation also triggers protection actions immediately when the application veers off course.
How does Virsec extract and impose the Application Provider Intent?
The first thing that happens when an application is launched is that the OS launches one or more processes where the application’s code will load. As the code starts loading, Virsec’s host protection module ensures that all application code, including the main executable as well as all indicated libraries, is pristine before such code gets loaded into process memory.
An application may be written in a pre-compiled language such as C/C++ or it could be written in a just-in-time (JIT)-compiled language like Java, .NET, PHP etc. The one major difference between these two types of applications is that in case of a JIT-compiled application, the attacker can send “malicious” data that the application may, egregiously, turn into code. With pre-complied applications, there is no such opportunity, and the attacker must themselves generate the malicious code. The attacker must also be able to trick the vulnerable application into executing attacker provided pre-compiled code.
As an application whose code is of a pre-compiled nature loads into runtime memory, Virsec’s DPP implementation examines the machine code of the application and silently builds out a sequence of code branches that will execute when the application’s code is loaded. This is very similar to how a GPS creates the intended navigation path for the driver before the journey begins. This sequence of pre-ordained code branches is defined as the Application Provider’s Intent for the said process. Virsec’s DPP implementation for pre-complied code ensures that as soon as any code whose execution triggers a deviation from the Application Provider Intent, protection action is engaged immediately. This is again very similar to the GPS that starts complaining immediately when the driver veers off course.
As stated above, when attacking JIT-compiled code, an attacker can trick a vulnerable application into generating malicious code that the one or more downstream interpreter used by the application will end up executing. Virsec’s DPP implementation for JIT-compiled code performs stateful, contextual comparison of end-user input and freshly generated code before such code executes. Virsec’s DPP implementation for JIT-complied code ensures that as any code begins to execute attacker intent, protection action is engaged immediately and in real time.
A workload protected by Virsec cannot be easily exploited by attackers. This makes the enterprise breathe easier since it doesn’t need to patch in a hurry and try to beat the attackers. With Virsec’s DPP implementation, the recent log4j vulnerability was neutralized without requiring any updates.
Virsec believes that with its DPP implementation, its vision of making cyber security irrelevant can be achieved. Enterprises can then focus on growing their business instead of living in constant fear of cyber-attacks.
