New IBM® WebSphere vulnerability makes the rounds
Technology is the art of making difficult things seamless. But even the simplest digital interactions require an amazing amount of technological work on the backend.
Cyberattackers capitalize on these hidden complexities to make their money and achieve their means. In the recently published CVE-2023-23477 insecure deserialization vulnerability, found in IBM® WebSphere Application Server versions 8.5 and 9.0, the crux of the problem lies in tools that enable crosstalk between systems — polluting data that passes following a specific request and hoping that either product or use code inadvertently inserts it.
This issue belongs to a class of attacks which frequently occur in the Java environment and are known collectively as insecure deserialization. Here’s a quick explanation of these kinds of vulnerabilities and the things your business can do to stay safe.
INSECURE DESERIALIZATION ATTACKS: A PRIMER
At high level, serialization and deserialization are the acts of converting bytes into data objects or objects into bytes to make them readable by a program. Nominally, these practices form the foundation for some of technology’s most basic tasks, including file storage and communications, by allowing systems that independently carry out different tasks to share crucial data.
Web browser cookies are one example. When a user visits a website, certain data about their stay (including browse times and checked-off preferences) might be serialized and saved by the user’s web browser. When the same user later comes back to that same site, the browser will deserialize the cookie data into a format the website’s server can understand before transmitting to the server. This allows the site to store user preferences between visits and provide other personalized interactions.
An insecure deserialization attack occurs when cyberattackers somehow trick a system into deserializing unsavory data. This can enable subsequent attacks and other undesirable actions, such as distributed denial of service, authentication bypasses, or even remote code execution.
Websites are common targets of insecure deserialization attacks, but any system that deserializes untrusted data can be at risk, including web services and apps.
According to Portswigger, the commonly held belief that binary serialization negates all data deserializing attacks is ultimately false. “While it may require more effort,” the website says, “it is just as possible for an attacker to exploit binary serialized objects as it is to exploit string-based formats.”
EXPLORING CVE-2023-23477 IN MORE DETAIL
Published in March 2023, CVE-2023-23477 holds special interest for readers of this blog because it applies to certain versions of IBM® WebSphere Application Server and – in the correct circumstances – could result in attackers achieving remote code execution, the worst outcome for any business.
Specifically, IBM® WebSphere Application Server versions 8.5 and 9.0 are susceptible to this vulnerability.
The root cause of CVE-2023-23477 is embedded within Java virtual machines, and the vulnerability itself mirrors other object-based Java injection techniques. In this case, attackers must assemble a gadget chain that matches the classpath of the vulnerable program, and the data they manipulate must come in the form of binary or base64 encoded binary. In other words, applications receiving pure text data are unlikely to be at risk.
SECURITY IS MORE THAN A PATCH
Tech stacks and software estates vary wildly from business to business. Two competing businesses can offer functionally identical offerings to consumers but go about providing them in very different ways on the backend. The same thought applies to marketing, sales, product development, and every other arm of the organization.
This basic fact of business tech creates a lot of job security, but it also contributes to an environment in a patch alone, if available, might not be sufficient to provide the desired level of security. A patch is not typically designed with the customer’s individual context in mind. Version, level of support, how the technology is used and has been deployed, and how crucial it is to the business all must be evaluated to provide context.
A business doesn’t need to be impacted by CVE-2023-23477 – or use WebSphere at all – to appreciate the larger idea at play. A security approach that considers your company’s unique needs and offers numerous options to support you in delivering your business securely – even when a patch or fix is not available in a timely fashion, if at all — can be effective against vulnerabilities.
CVE-2023-23477 HARDENING ADVICE
The objective when attempting to address the CVE-2023-23477 vulnerability is to reduce the likelihood of exploitation by limiting communications to only strongly identified entities on the local network and, where possible, restricting WebSphere Application Server from accepting and passing Java serialized objects entirely.
Companies that cannot deploy a patch to resolve this issue or choose not to should ask themselves if their applications pass or accept Java serialized objects across any network interface.
Upon determining this information, companies need to consider what network protocols those interfaces are most likely to use: HTTPS or RMI.
More generally, depending on their context and the unique shape of their software estate, companies wishing to achieve CVE-2023-23477 remediation could consider each of the following for implementation:
- Lockdown the product so that it doesn’t accept or pass Java serialized objects on any network interface
- Restrict network access to local traffic only
- Reject all unencrypted or weakly encrypted communications
- Restrict communications to well-identified counterparties, such as digital certificates or other strongly identified methods
- Ensure network monitoring takes place to identify any abnormal activity
- Minimize the classes on the Java classpath to only include the required Java serialized objects when the user performs backup/restore; attackers can only execute classes that are on the class path, which can be challenging to execute
Additionally, companies should consider implementing a servlet filter to inspect the class description section of the serialized file and rejecting any relevant object that fails the syntax test.
IMPORTANT NOTE: If future needs require the company to accept Java serialized objects via any network interface, this ability would need to be reviewed and re-enabled.
THERE’S ALWAYS ANOTHER ATTACK
As the CVE-2023-23477 vulnerability illustrates in worrying detail, there is always another potential cyberattack waiting to occur. Whether the next problems arrive under the banner of object injection or something else entirely, a proactive cybersecurity approach isn’t just a luxury – it’s essential.
Because organizations do vary so sharply in terms of their tech, what that looks like will be significantly different from company to company. It’s clear, however, your best defense is proactive, contextual software support, backed by quick access to niche expertise.