Coming in at #8 on the OWASP Top 10 List – 2017, Most Critical Web Application Security Risks is Insecure Deserialization. This vulnerability occurs when untrusted data is used to abuse the logic of an application or application program interface (API).
For example, an attacker may go after an object or data structure, intending to manipulate it for malicious intent. OWASP (2017) listed the primary attack types as denial-of-service (DoS) attacks, authentication bypasses and remote code/command execution attacks, where attackers manipulate arbitrary code upon it being deserialized.
To fully understand insecure deserialization is we must understand both what serialization and deserialization are first. This blog will illustrate what both are in detail, as well as what insecure deserialization means, the impact of it on applications, and best practices to prevent it. We’ll then cover some solutions for preventing insecure deserialization.
Please note that some of this will vary since no web applications are built exactly alike and have many different configurations and security controls in place.
Description & Terminology
Serialization –
According to Oracle, Serialization refers to a process of, “converting an object to a byte stream so that the byte stream can be reverted back into a copy of the object” (2018). Serialization can be used to back up objects to a database, transfer data between client/server, or create an equivalence between objects in different environments.
The format in which an object is serialized into can either be binary or structured text (for example XML, JSON YAML…). JSON and XML are commonly used serialization formats within web applications. OWASP creators and experts stated, “today, the most popular data format for serializing data is JSON” (pg. 1, 2107).
Deserialization –
Deserialization, in contrast, is the reverse of that process, taking data structured from some format, and rebuilding it into an object. Many web applications use serialization/ deserialization with limits but in most cases are required when using certain programming languages. This is where the problems begin for most developers. Some features of native deserialization mechanisms can be repurposed for malicious intent when operating on untrusted or falsely trusted data, typically user data, that has been tampered with.
Insecure Deserialization was ranked at number eight on the list for good reason. Many developers do not believe their apps are at risk because the exploit level is low, but this vulnerability is best when not be underestimated. There are three critical elements needed to achieve a serialization exploit including that the attacker can modify a stream that will be serialized, that type information is parsed from the stream, and that it is not too tightly restricted.
If a deserialization implementation in any environment is configured with default settings, an application can have little to no control over what data is deserialized. This can include incoming data that is serialized from any source, with no verification needed.
OWASP stated that “Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code (2017).” This does not mean impossible, even if developers specify to only allow objects to serialize primitive data types and block untrusted sources they are other methods of gaining access, potentially from an internal resource.
Manual work is required for an attack of this nature, so its frequency is low-moderate, and automation is not possible, which means these are targeted attacks. Such as the Equifax attack was in 2017. This attack was due to two vulnerabilities. (CVE-2017-5638) An Apache Struts exploit, which is in the JAVA framework type used in many web applications.
Also, (CVE-2017-9805) an Apache Struts Content-Type arbitrary command execution vulnerability, which was in the Apache REST plugin of the struts framework, this deserialization exploit allows attackers to write arbitrary binary code to the web server and execute it remotely via remote code execution.
Impact of Deserialization of Untrusted Data
Defined by OWASP as, “Data which is untrusted cannot be trusted to be well-formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code when deserialized.” The impacts can vary but, in all cases, the severity is high without proper security in place.
Prevention
The best way to prevent this type of exploit from happening is to check your code for the following:
JAVA –
- Serialization of untrusted data should be avoided when possible.
- do not serialize sensitive data in a serializable class.
- Approaches for handling sensitive fields in serializable classes are:
- Declare sensitive fields transient
- Define theserialPersistentFields array field appropriately
- Implement writeObjectand use putField selectively
- Implement writeReplace to replace the instance with a serial proxy
- Implement the Externalizable interface
- Perform the same input validation checks in a readObject method implementation as those performed in a constructor (CMU, 2018).
- Likewise, assign default values that are consistent with those assigned in a constructor to all fields, including transient fields, which are not explicitly set during deserialization.
- In addition, create copies of deserialized mutable objects before assigning them to internal fields in a readObject
- Security-sensitive serializable classes should ensure that object field types are final classes or do special validation to ensure exact types when deserializing.
- Ensure SecurityManager checks enforced in a class. Specifically, if a serializable class enforces a SecurityManager check in its constructors, then enforce that same check in a readObject or readObjectNoData method implementation.
- Prevent native code from being exposed to untrusted and unvalidated data, Java code should sanitize data before passing it to JNI methods. This is also important for application scenarios that process untrusted persistent data, such as deserialization of code (CMU, 2018).
- Validate user inputs that are being serialized.
- Construct a suitable whitelist.
- Use non-standard data formats to deter attacks.
- Approaches for handling sensitive fields in serializable classes are:
There are many more ways to prevent this such as a secure code development through testing, well-configured firewalls and proper use of access controls. Contact us for more info on how we can help or call us at +1 (855) 519-7328.
.NET C# –
Search the source code for the following terms:
- TypeNameHandling
- JavaScriptTypeResolver
- Look for any serializers where the type is set by a user-controlled variable and check that type has custom permissions (restrict access when possible).
- JSON.NET type handling should always be set to “none (MS BlueHat, 2018).
- Always validate user inputs
Solutions for Insecure Deserialization
Remediation cost for a breach due to an exploit of this nature are typically high based on Oracle’s SEI CERT Coding Standards for JAVA (2018). Praetorian Secure offers services to prevent applications (web, software, or mobile) from being exploited by known vulnerabilities including:
Praetorian Secure has been providing cyber security solutions and services for over 10 years, gaining experience that hardened our experts to accomplish even the most robust security challenges you may encounter. For a more in-depth explanation of our services visit the provided site links or contact our team directly.
Conclusion
Deserialization and serialization both vary immensely from the programming language, serialization formats and software libraries used. There is not a standard approach to solving every insecure deserialization vulnerability attack because there are so many different customization variables when it comes to configuration and authentication.
While this makes it more difficult to find these vulnerabilities, it does not mean you should not look twice as hard to find them using a variety of application security testing methods. To learn more about our team or the services we offer feel free to contact us here or by phone at +1 (855) 519-7328.
BlueHat Security Conference Follow. “ Securing .Net Deserialization.” LinkedIn SlideShare, 9 Dec. 2017, www.slideshare.net/MSbluehat/dangerous-contents-securing-net-deserialization.
Mellon University, Carnegie. “SEI CERT Oracle Coding Standard for Java.” SER12-J. Prevent Deserialization of Untrusted Data – SEI CERT Oracle Coding Standard for Java – Confluence, 2018, wiki.sei.cmu.edu/confluence/display/java/SER12-J.+Prevent+deserialization+of+untrusted+data.
OWASP. “Deserialization Cheat Sheet.” Deserialization Cheat Sheet – OWASP, Oct. 2017, www.owasp.org/index.php/Deserialization_Cheat_Sheet.
OWASP. “OWAASP Top[ 10 – 2017.” 2017, www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf.
“Serializable Objects.” Serializable Objects (The Java™ Tutorials), 2018, docs.oracle.com/javase/tutorial/jndi/objects/serial.html.