Wednesday, January 6, 2016

Deserialization Vulnerability : Automating the hunt


At the end of 2015, many Java applications were found vulnerable to a common deserialization bug. It all starts with a presentation at AppSecCali that demonstrate the danger of deserializing user input and having Apache Commons Collections in the classpath [1]. Stephen Breen from Foxglove later publish vulnerabilities with working exploits for WebLogic, WebSphere, JBoss and Jenkins.

This is obviously not the end of the story. While some big names where fixed, other applications open source and proprietary are likely to be vulnerable to the same bug pattern. In fact quickly after Foxglove publication, an advisory was release for ActiveMQ.

Stephen has already described in great detail the detection and exploitation in the context of penetration test. I wanted to provide a small method for scanning proprietary applications looking only at the jar files.

Object deserialisation (*)

Scanning a specific library


For the demonstration of this article, I will use the command line interface of FindBugs with the plugin Find Security Bugs version 1.4.5 (download link).
In its simplest form, we can pass the path of the JAR file to scan. Here -high is added to hide medium vulnerability.
> ./findsecbugs.sh -high libs/esapi-2.1.0.jar

H S SECOBDES: Object deserialization is used in org.owasp.esapi.codecs.Base64.decodeToObject(String)  At Base64.java:[line 1106]
H S SECPTI: File(...) reads a file whose location might be specified by user input  At DefaultEncryptedProperties.java:[line 174]
H S SECPTO: FileOutputStream(...) writes to a file whose location might be specified by user input  At Base64.java:[line 1359]
H S SECPTO: FileOutputStream(...) writes to a file whose location might be specified by user input  At Base64.java:[line 1322]
H S SECPTI: File(...) reads a file whose location might be specified by user input  At EncryptedPropertiesUtils.java:[line 188]
H S SECPTI: FileInputStream(...) reads a file whose location might be specified by user input  At Base64.java:[line 1318]
H S SECPTI: File(...) reads a file whose location might be specified by user input  At EncryptedPropertiesUtils.java:[line 140]
H S SECPTI: FileInputStream(...) reads a file whose location might be specified by user input  At Base64.java:[line 1355]

To analyze a specific bug, you can open the jar directly in JD.
Jumping to the potential bug (Base64 line 1106)

Search feature in JD to find class by name or regex pattern

Scanning a complete application


The command line interface of FindBugs has plenty of options. If we want to scan a complete application, we will need to give the complete list of jars to FindBugs.

On Linux:
> find /some/application/ -name *.jar

On Windows:
dir "C:/Some/Application/" /s /b  | findstr \.jar$ > libs.txt

Once the jars list is place in a text file, we can start a global scan. In the following example,


  • -xargs : is used to pipe the list of jars
  • -progress : is added to have some feedback since analyzing large code base can take a couple of minutes.
  • -html : I recommend using the HTML report to have a more detailed and readable report

  • > cat libs.txt | findsecbugs.sh -xargs -progress -html -output report.htm
    
    Scanning archives (156 / 156)
    2 analysis passes to perform
    Pass 1: Analyzing classes (16922 / 48118) - 35% complete
    

    The same operation can be done in Windows with the following command.
    > type libs.txt | findsecbugs.bat -xargs -progress -html -output report.htm
    

    Conclusion


    That's it! You should be able to find deserialisation vulnerability along with other bug patterns supported by Find Security Bugs plugin.

    To determine if an application is vulnerable or not will obviously require a specific analysis. The only general guideline is to identify ObjectInputStream instance where the content is read from user input.

    References


  • What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability: Detailed explantation for many application can be exploited by Apache Commons Collections "serialization gadget" written by Stephen Breen
  • AppSecCali 2015 - Marshalling Pickles: Presentation that cover the Apache Commons Collections "serialization gadget" by Christopher Frohoff and Gabriel Lawrence
  • SRCLR: Commons Collections Deserialization Vulnerability Research Findings : Research maded by SRCLR that focus on finding additional vulnerables libraries
  • SRCLR: Let’s Calm Down About Apache Commons Collections: Follow up to the article from Foxglove Security
  • ActiveMQ CVE-2015-5254: Official advisory from ActiveMQ
  • Find Security Bugs : Official web for the Find Security Bugs plugin
  • Find Security Bugs release 1.4.5 : Version use in the previous demonstrations
  • 2 comments:

    1. In Windows 10, the findsecbugs.bat file didn't work for me. I changed it to:
      java -jar findbugs\findbugs.jar -textui -pluginList plugins/findsecbugs-plugin-1.4.5.jar;plugins/noUpdateChecks.jar -include include.xml %*

      Also, I generated the list of file using this simpler command:
      dir /a-d /b /s *.jar

      ReplyDelete
      Replies
      1. The latest version now includes the noUpdateChecks .. I suspect that FindBugs was not able to reach the update URL (firewall network?)

        If there is still an issue : https://github.com/find-sec-bugs/find-sec-bugs/issues

        Delete