freddy v2.2.0 releases: Automatically identify deserialisation issues in Java and .NET applications
Freddy the Serial(isation) Killer – Deserialization Bug Finder
A Burp Suite extension to aid in detecting and exploiting serialization libraries/APIs.
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 serialization 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 FastJson uses a JSON field $types to 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.1 in order to induce a time delay in these cases.
Collaborator-based payloads work either by issuing a
nslookup command 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 RCE (Collaborator).
Resolved issue “Payloads not taking private collaborator server settings”. This version will, before using the collaborator, check retrieve the latest collaborator settings (thus detecting if you changed from a public to a private collaborator).
Copyright (C) 2018 irsdl