Stay in touch

Application security insights and invitations to exclusive events in your inbox


Your data will stay confidential Private and Confidential

Insecure Deserialization: OWASP Top 10 element of arduous exploitation but leading to system takeover

Thursday, August 2, 2018 By

Insecure Deserialization is #8 in the current OWASP Top Ten Most Critical Web Application Security Risks. It is difficult to exploit, but successful attacks can lead to remote code execution.


Insecure Deserialization: OWASP Top 10 element of arduous exploitation but leading to system takeover

During 2017, the value of cryptocurrencies skyrocketed, with Bitcoin and multiple others reaching their highest ever value. This was accompanied by a commensurate rise in bitcoin mining, both through legal and illegal methods. One of the largest illegal cryptocurrency mining attacks ever, was discovered in February 2018. The reason this attack was able to succeed was thanks to a flaw in the victim’s deserialization implementation.

Insecure deserialization has been growing in notoriety for the last few years, and made its debut in the current OWASP Top Ten Risks at #8.


Insecure Deserialization

Serialization and deserialization are important concepts in object-oriented programming frameworks, such as Java and .Net; and are consequently common to many web applications.

Serialization refers to changing an object into a format that can be transmitted or persisted on disk. Deserialization is the reverse process – converting serialized data back into an object that can be used by the web application.

If an attacker can control the serialized stream, the process of deserializing that stream can be exploited, and the web application compromised.

An insecure deserialization vulnerability exists when an application doesn’t properly secure this process. If a deserialization implementation is left to its default settings, an application can have little to no control over what data is deserialized. In the most extreme cases, this can include any incoming serialized data from any source, with no verification or precautions.

Conceptually, this is very similar to the XML External Entities (XXE) risk – especially since XML is a format used for serialization. We’ve already looked at the vulnerabilities of XML specifically, but insecure deserialization applies to a wider range of data formats. Some of the more common serialization formats include JSON, XML, BSON and YAML. Different APIs and frameworks have different processes for serialization and deserialization, and although the risk applies in any instance of deserialization, it must be handled in an application-specific way.


The scope of the Insecure Deserialization Risk

A successful deserialization attack, like XXE or XSS, allows for unauthorized code to be introduced to an application. If an attacker’s code is allowed to be deserialized unsafely, almost any malicious intent is possible. Data exposure, compromised access control and remote code execution are all possible consequences of insecure deserialization.

This was shown over 2015 and 2016, which saw a surge in awareness of an already-known Java/XML vulnerability. Fortunately, most incidents over this period were benign, but demonstrated the frightening scope of deserialization vulnerabilities in web apps. A deserialization vulnerability found in PayPal could have allowed attackers to completely hijack production systems. As a less benign example, a ransomware attack against San Francisco’s Municipal Transport Agency, was thought to use a deserialization exploit in WebLogic.

The increasing incidence of deserialization attacks during this period led to the inclusion of the risk in the 2017 issue of the OWASP Top Ten Risks. They haven’t gone away.

In January 2018, Imperva’s Incapsula reported, “Our analysis shows that, in the past three months, the number of deserialization attacks has grown by 300 percent on average, turning them into a serious security risk to web applications.

In January 2018, Imperva reported that, in the past three months, the number of deserialization attacks has grown by 300 percent on average.”

To make matters worse, the report continued, “Many of these attacks are now launched with the intent of installing crypto-mining malware on vulnerable web servers, which gridlocks their CPU usage.

Deserialization was at the heart of the Jenkins cryptominer – possibly the largest illegal cryptomining operation yet discovered. Check Point researchers wrote, “By sending 2 subsequent requests to the CLI interface the crypto-miner operator exploits the known CVE-2017-1000353 vulnerability in the Jenkins Java deserialization implementation. The vulnerability is due to lack of validation of the serialized object, which allows any serialized object to be accepted.”

And the threat is still growing, now spreading from primarily Linux/Unix systems to include Windows. In April 2018, Johannes Ullrich noted in the InfoSec Handlers blog, “Recently we talked a lot about attacks exploiting Java deserialization vulnerabilities in systems like Apache SOLR and WebLogic. Most of these attacks targeted Linux/Unix systems. But recently, I am seeing more attacks that target Windows.” He follows this comment with example code used in such an attack.

Deserialization vulnerabilities are emerging as a highly effective vector for remote code execution attacks. With a successful exploitation of poor deserialization implementation, an attacker can turn a victim’s servers to virtually any purpose. This could be a complete system takeover as part of a cryptojacking attack, or it could use system resources as part of a crypto-mining botnet.


Solutions

Some good news is that deserialization vulnerabilities are difficult for attackers to exploit, being the only security risk in the OWASP top 10 with an exploitability rating of just 1 (the most difficult). Being a highly technical vulnerability does have a downside, however, in that any web developer needs to be more proficient than any malicious user capable of mounting a competent deserialization attack.

In security terms, the ideal is for an app to either disallow all serialized data, or to only deserialize primitive data types. This is rarely viable, but the next best thing is to restrict which data classes are permitted to deserialize. If the application only permits expected classes which are necessary for functionality, it goes a long way to protect against deserialization attacks.

Close monitoring of deserialization can help. Logging all errors the app encounters related to serialized data for later review will help discover any untrustworthy data. Monitor any deserialization processes to create alerts if a user deserializes constantly. Check OWASP’s cheat sheet and further resources from Infosec Institute for more in-depth countermeasures against insecure deserialization.

It is recommended that you employ defensive deserialization in any potentially vulnerable app. This will check incoming serialized objects against black and/or whitelists to prevent untrustworthy code being deserialized. Alvaro Muñoz & Christian Schneider provided this example of defensive deserialization in Java, from the OWASP AppSecEU Conference in 2016:

  1. class DefensiveObjectInputStream extends ObjectInputStream {
  2.     @Override
  3.     protected Class<?> resolveClass(ObjectStreamClass cls) throws IOException, ClassNotFoundException {
  4.         String className = cls.getName();
  5.         if ( /* CHECK CLASS NAME AGAINST ALLOWED/DISALLOWED TYPES */) {
  6.             throw new InvalidClassException("Unexpected serialized class", className);
  7.         } return super.resolveClass(cls);
  8.     }
  9. }

Schneider also provides an extensive Java Deserialization Security FAQ, written in 2016. In it he offers the following advice: “What really protects me? Do not deserialize untrusted data - never! It’s just that simple: avoid it.

For the best detection of deserialization flaws, AI-assisted human testing offers the best results.

There are some tools to assist with detecting deserialization vulnerabilities, but according to OWASP human input is usually needed for verification. For the best detection of deserialization flaws, AI-assisted human testing offers the best results. This is why High-Tech Bridge’s ImmuniWeb app-sec testing platform’s detection rate so far outstrips both automated vulnerability scanners and regular human-augmented SaaS.


Actionable introduction and analysis of web and mobile application security, DevSecOps and Machine Learning for AST.

User Comments
Add Comment

High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email
Share