A Java serialization vulnerability disclosed more than a year ago figured to have a long shelf life. It lived in popular Java application development frameworks such as Apache Commons Collections—where it’s been patched—and not to mention widely deployed application servers such as Oracle WebLogic, IBM WebSphere, Red Hat’s JBoss and others.
PayPal this week put the bug back in the spotlight when it patched one of its business websites, manager.paypal.com, after researcher Michael Stepankin privately reported in December that he’d found a vulnerability that allowed him to execute shell commands and open a backdoor on PayPal’s servers.
Stepankin said he was inspired by Gabriel Lawrence’s and Chris Frohoff’s research presented at the 2015 AppSecCali security conference, and was paid under PayPal’s bug bounty program. But Stepankin wasn’t the only one looking for the vulnerability on PayPal’s infrastructure; bug-hunter Mark Litchfield beat him to it two days earlier, and despite the duplication, both researchers were paid bounties.
Stepankin said he was able to execute arbitrary shell commands on PayPal servers by taking advantage of insecure Java object deserialization. He wrote in a blog post that he was able to access PayPal’s production servers.
“I realized that I could execute arbitrary OS commands on manager.paypal.com web servers and moreover, I could establish a back connection to my own internet server and, for example, upload and execute a backdoor,” he wrote. “[As a] result, I could get access to production databases used by manager.paypal.com application.”
Stepankin said he used a tool called Ysoserial developed and published by Frohoff and Lawrence to generate payloads to pull off his PoC exploits. Stepankin’s first payload allowed him to tread carefully and send DNS and HTTP requests to his own server from PayPal. He then executed another attack.
“I just read “/etc/passwd” file by sending it to my server as a proof of the vulnerability,” he wrote.
Serialization is a process used to convert user input to a static binary form that can be stored or sent over a network. Deserialization is the opposite and is the process by which the static data is converted to something the user can do. The vulnerability arises because the library does not properly sanitize user-provided input, and an attacker can append malicious code to input that is accepted and executed.
Stepankin said he found a post form parameter called oldFormData that was a Java serialized object that was unsigned and handled by the application.
“It means that you can send to server serialized object of any existing class and “readObject” (or “readResolve”) method of that class will be called. To exploit this issue, you need to find a suitable class in application “classpath” which can be serialized and has something interesting (from exploitation point of view) inside method “readObject,” he wrote.
Java serialization bugs were thought to be impossible to exploit until Frohoff and Lawrence’s work came along. Researchers Stephen Breen and Justin Kennedy in November published proof-of-concept exploits for the vulnerability in the commercial web application servers.
PayPal said that organizations need to look for this vulnerability across their Java deployments.
“This specific deserialization vulnerability is much larger than any of us initially anticipated – spanning across open source components, third-party commercial tools and our own custom code,” PayPal said in a blog post. “Other organizations should treat this seriously as it can result in remote code execution and implement security controls for long-term remediation, and not stop just at patching the commons-collections library.”
