Enterprise organizations have built much of their foundations on Oracle’s WebLogic servers. As ubiquitous as they are, it’s no wonder that they are often the target of sophisticated attacks aimed at harvesting sensitive data.
It’s no surprise that large companies were panicked when news of a zero-day vulnerability (CVE 2019-2725) was announced in WebLogic application servers. The remote execution vulnerability didn’t require authentication and could result in a complete system compromise. But while word spread about the new threat, hackers were already working on an exploit. The day after Oracle released a critical patch for its premium customers, WebLogic servers were already seeing their first ransomware attacks.
So, what exactly is this zero-day vulnerability and why has it been so attractive for attackers? For that, we need to take a look at serialization—or it’s darker side—deserialization.
Serialization: Feature or Flaw?
Serialization, or marshaling, is the process of converting a memory object into a stream of bytes to store it into the filesystem or transfer it to another remote system. Deserialization, also known as unmarshaling, is the reverse process that converts the serialized stream of bytes back to an object in the memory of the machine. All main programming languages provide facilities to perform native serialization and deserialization and most of them are inherently unsafe. Originally intended as a feature to ease communications, even Oracle has admitted that it was a horrible mistake.
Also, deserialization issues are not limited to Java—.NET, Ruby, PHP, Python and others are also affected by deserialization vulnerabilities. And for Legacy servers and apps that have reached the end of support, deserialization will remain a challenge. Of course, serialization also has great use cases, so long as it’s only able to be deserialized by a trusted source. Unfortunately, it’s also so pervasive that it has been the cause of major vulnerabilities that have led to breaches such as the one that occurred at Equifax. It’s the flavor that has been holding WebLogic servers ransom of late.
Safeguarding Enterprise Critical Applications
It’s unlikely that we won’t see more vulnerabilities resulting from the use of serialization, so it’s important for companies to put in place measures to prevent insecure deserialization:
- Patch: By far, the best way to keep your applications safe is to keep a complete inventory of all components (including open source) and patch regularly.
- Consult the OWASP cheat sheet on insecure deserialization to learn how to harden input parameters to at least make it more difficult for attackers to inject malicious code.
- Leverage application security products such as web application firewalls (WAF) or runtime application self-protection (RASP) that detect and prevent unsafe deserialization.
WebLogic has seen its fair share of preference from the bad guys, likely because it can be fairly easy to execute remotely and often contains sensitive enterprise data.
The wave of vulnerabilities underscores the fact that network security is simply not enough. A single vulnerable application is enough to allow a hacker to access a company’s network and security teams simply can’t keep up with the overwhelming and growing numbers of vulnerabilities they face daily. As a result, It is imperative that enterprises implement security measures to protect their company’s critical applications.