There has been a recent wave of ransomware attacks against hospitals, highly publicized and for good reason. Who the hell attacks hospitals with malicious code that locks up access to critical care systems, and puts our most vulnerable at further risk? Well, there’s more to this story than I can reveal here but I’ve been following the trend for months, and here’s what you need to know.
FIRST: This was never about the hospitals. They weren’t the specific target. Law enforcement also relies on constant access to critical systems and they are being hit. But this goes so much wider, and we’re missing the bigger picture here. Therein lies the danger. Samsa/Samsam has been a cash grab for the attackers, with no costs, no penalties. Don’t expect them to stop looking for more revenue streams to hit.
SECOND: This ransomware is not the same old ransomware. We can’t rely on our standard approaches to detect and defend against future attacks. This one goes after servers, so it can bring down entire networks, and doesn’t rely on the social engineering tactics to gain access. It’s so bad US-CERT has issued this recent advisory.
I’ve laid out what’s been made available on just how this new strain of ransomware works. And I’ve done it in terms to help anybody take a closer look at the middleware running in their systems currently. Because a little knowledge could be dangerous thing used to our advantage this time.
WHAT: Extremely dangerous and wholly underated class of vulns
Attackers can gain complete remote control of an app server. Steal or corrupt data accessible from the server. Steal app code. Change the app. Use the server as launching oint for further attacks.
- No working public exploits against apps til now
- Remotely executable exploits against major middleware products
- Powerful functionality that should not be exposed to untrusted users in the ability to hijack deserialization process.
IMPACT: Millions of app servers open to compromise
- Not easily mitigated
- Potential for millions of apps to be susceptible
- Many enterprise apps vulnerable
AFFECTS: All apps that accept serialized Java objects
Remotely executable exploits against major middleware products:
HOW: Vulnerability is found in how many JAVA apps handle process of object deserialization.
Serialization is how programming languages transfer complex data structures over the network and between computers. Disassembly is the process of breaking an object down into a sequence of bits.
Deserialization is reassembly of those bits. (unserialization)
A Java object is broken down into series of bytes for easier transport.
Then is reassembled back at other end. Think the fly or tranporter
PROBLEM: many applications that accept serialized objects do NOT validate or check UNTRUSTED input before deserialization or putting things back together. So yes, this is the perfect point to sneak the bad stuff in.
Attackers can INSERT malicious object into data stream and it can execute on the app server
Attack method: special objects are serialized to cause the standard Java deserialization engine to instead run code the Attacker chooses.
Each of the 5 middleware applications listed above has a Java library called “commons-collections.” This has a method that can lead to remote code execution when data is deserialized. Because no code should execute during this process.
NEEDS TO HAPPEN:
Enterprises must find all the places they use deserialized or untrusted data. Searching code alone will not be enough. Frameworks and libraries can also be exposed.
Need to harden it against the threat.
Removing commons collections from app servers will not be enough. Other libraries can be affected.
Contrast Sec has a free tool for addressing issue. Runtime Applicaton Self-Protection RASP. Adds code to deserialization engine to prevent exploitation.
Why the Java Deserialization Bug is a Big Deal Dark Reading by Jai Vijayan
What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability
Paypal is the latest victim of Java Deserialization Bugs in WebApps