Automatically identify deserialisation issues in Java and .NET applications by using active and passive scans
A Burp Suite extension to aid in detecting and exploiting serialisation libraries/APIs.
This useful extension was originally developed by Nick Bloor (@nickstadb) for NCC Group and is mainly based on the work of Alvaro Muñoz and Oleksandr Mirosh, Friday the 13th: JSON Attacks, which they presented at Black Hat USA 2017 and DEF CON 25. In their work they reviewed a range of JSON and XML serialisation libraries for Java and .NET and found that many of them support serialisation of arbitrary runtime objects and as a result are vulnerable in the same way as many serialisation technologies are - snippets of code (POP gadgets) that execute during or soon after deserialisation can be controlled using the properties of the serialized objects, often opening up the potential for arbitrary code or command execution.
Further modules supporting more formats including YAML and AMF are also included, based on the paper Java Unmarshaller Security - Turning your data into code execution and tool marshalsec by Moritz Bechler.
This Burp Suite extension implements both passive and active scanning to identify and exploit vulnerable libraries.
Freddy can passively detect the use of potentially dangerous serialisation libraries and APIs by watching for type specifiers or other signatures in HTTP requests and by monitoring HTTP responses for exceptions issued by the target libraries. For example the library
FastJsonuses a JSON field
$typesto specify the type of the serialized object.
Freddy includes active scanning functionality which attempts to both detect and, where possible, exploit affected libraries.
Active scanning attempts to detect the use of vulnerable libraries using three methods: exception-based, time-based, and Collaborator-based.
In exception-based active scanning, Freddy inserts data into the HTTP request that should trigger a known target-specific exception or error message. If this error message is observed in the application's response then an issue is raised.
In some cases time-based payloads can be used for detection because operating system command execution is triggered during deserialisation and this action blocks execution until the OS command has finished executing. Freddy uses payloads containing
ping [-n|-c] 21 127.0.0.1in order to induce a time delay in these cases.
Collaborator-based payloads work either by issuing a
nslookupcommand to resolve the Burp Suite Collaborator-generated domain name, or by attempting to load remote classes from the domain name into a Java application. Freddy checks for new Collaborator issues every 60 seconds and marks them in the issues list with
The following targets are currently supported (italics are new in v2.0):
Released under agpl-3.0, see LICENSE for more information