Monday, January 25, 2016

[] Remote Code Execution Vulnerability

In December 2015, I found a critical vulnerability in one of PayPal business websites ( 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 application, I noticed an unusual post form parameter “oldFormData” 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 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.


I downloaded this tool and generated a simple payload that sends DNS and HTTP requests to my own server by executing the “curl” 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, 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 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 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.