By Garrett Enochs
You have a lot to think about as a security professional – and one component that can fall by the wayside is the attacker’s mindset. Getting into the mind of the attacker is a critical ingredient in implementing security policies, tooling and personnel. There are many types of defenses, and prioritizing the right ones can have a massive impact. We’ve all experienced tunnel vision when working towards milestones and goals for compliance and can easily forget that attackers don’t follow the guidelines we have in place or stay within the bounds of the application’s expected usage.
Attackers have many ways to slice an onion. One attacker may throw the kitchen sink and see what sticks. Meanwhile, another might take a more methodical approach, taking great care not to trigger any alarms. Both scenarios need attention, and it takes an attacker’s mind to maintain a well-rounded security posture.
It is a common misconception that the more tools, funding and personnel you throw at a problem, the faster and easier it will be to resolve. This mindset can lead to costly mistakes, either by overloading the team with tools, or buying the wrong tools for your specific needs.
Today, we are going to follow the three stages of an attack, and how an attacker might treat your application once it’s in the wild. We will only be analyzing one of many possible methods — insecure deserialization. These attacks can be lucrative for attackers and difficult to deal with as a defender.
Stage One: Acceptance of User-Supplied Serialized Objects
A live insecure deserialization attack starts with the sending of untrusted data to an application that is exposed to a deserialization vulnerability. An attacker can create a specially crafted malicious serialized object to send to a vulnerable application. This object may contain code, commands, or data that, when deserialized, can have unintended and harmful consequences. When the vulnerable application deserializes the malicious object, it reconstructs the object along with any hidden malicious payload. This payload can be used to execute arbitrary code, launch attacks, or gain unauthorized access to the system. Some of these attacks include Remote Code Execution (RCE), Data Tampering, Denial of Service (DoS) attacks, and others. The most common scenarios in which this vulnerability comes up are:
- Vulnerable libraries or frameworks that perform deserialization without proper security checks
- Misconfigured or insecure deserialization settings
- Systems that accept serialized data from untrusted sources — such as user input or external network requests.
This is where Waratek comes in. The Waratek Agent tackles insecure deserialization attacks with an ARMR (Waratek’s proprietary coding language) policy which addresses deserialization, completely removing it from the risk appetite of the application.
During first stage of the attack, we are able to prevent deserialized data from making it to execution by utilizing an ARMR rule as outlined below:
Stage Two: Attack Execution by Attacker
Then we add an ARMR rule for File Read/Write detection, letting us know any files that are written or read, modified in any way. There are options to either prevent or detect the reading and writing of certain files. Meanwhile, if we know what the application is intended to do during normal operations, we can essentially build a wall around the expected scenarios. This way, we can completely eliminate unexpected scenarios. During an attack, if an attacker sends untrusted data throughout your application, or attempts to write a file, Waratek can engage and prevent the attack from moving further.
Stage Three: Compromise Upon Deserialization
Let’s explore what would happen if an attacker did make it this far — though that would be impossible with Waratek. Once the malicious payload has been deserialized, the attacker could fork a process. This involves spinning up a malicious rogue program or API to help facilitate the attack. This may take the form of data exfiltration or harvesting, or damaging the company’s reputation. Waratek’s Java Secure Agent would again engage at this juncture of the execution chain, preventing the process from forking of and connecting to a random server, or carrying out an attack on the network.
Eliminate Insecure Deserialization Risk
We have broken down 3 different stages of an attack, and defined how Waratek can detect/protect this attack. Waratek is effective regardless of the point of contact, and intervention by the attacker, whether it be an insider threat or from an external attack. Also included below are some additional tips and recommendations around securing your applications against something as critical as insecure deserialization.
To get started securing your java apps against insecure deserialization, click here.
