Critical Java bug found in PayPal servers


Up until last month, PayPal’s servers had been vulnerable to a critical type of bug that security researchers have known about for years but have assumed – incorrectly – was theoretical and too hard to exploit.

It’s called a Java deserialization vulnerability, and to understand what it means, it helps to understand how apps securely talk to each other.

Programs that need to share data may be operating in a virtual Tower of Babel, for example because they are written in different programming languages to run on completely different computer systems that represent data differently in memory.

To understand each other, they use serialization, where program A explicitly collects and writes out all the actual data it wants to transfer in a standardized format, rather than just providing references to it that could be misinterpreted, such as memory addresses or file handles.

In August 2015, we explained, in greater (but still simplified) detail, how this works, when the Android hole “One (Java) Class to Rule Them All” (OctoRuTA) cropped up.


Speaking of Java and serialization: two researchers, within days of each other, recently discovered the same, critical hole that happens when the data packets are deserialized – in other words, “unflattened” so as to use the data within.

One of those bugs – and it was a nasty one – was discovered in a spot where it’s acutely unnerving to find holes: in the cash-wrangling app PayPal.

Michael “Artsploit” Stepankin, whom Softpedia says is an independent security researcher, last month discovered a critical security flaw on one of PayPal’s business websites, in the interface for PayPal Manager.

As he described on his Artsploit blog, Stepankin found he could execute arbitrary commands on web servers and that he could install a connection to his own server.

That vulnerability would have enabled an attacker to plant malicious code: for example, uploading and executing a backdoor.

He also found that he could get access to production databases used by the application.

Next, he read the app’s /etc/passwd file by sending it to his server, to be used as a proof of the vulnerability.

After he had poked around a bit, Stepankin realized that the fault lay in a vulnerability that, as we mentioned, had been recognized in the security community for years and which was described by FoxGlove Security in November.

This isn’t just a PayPal problem. FoxGlove said that the bug can be found in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and custom apps.

A year ago, researchers Chris Frohoff and Gabriel Lawrence found suitable classes in the Apache Commons Collections Java library that could lead to remote code execution, and they went ahead and released a proof-of-concept tool, called ysoserial, to exploit the bug.

Using the tool, Stepankin sent a few malicious Java payloads to PayPal’s servers.

The first attack instructed the PayPal server to make simple DNS and HTTP requests to Stepankin’s own server.

After that one worked – PayPal’s servers were indeed connecting back to him – Stepankin performed a second, more intrusive attack: one with shell commands that retrieved the server’s /etc/passwd file and sent it to his server.

Stepankin notified PayPal in mid-December.

The company thanked him and gave him a $5000 bug bounty payout in spite of the fact that a similar vulnerability had been reported two days earlier by security researcher Mark Litchfield.

Litchfield contributed to an article posted last week by PayPal Engineering about the Java deserialization bug that says a lack of media attention contributed in part to it having been overlooked for so long.

From that article:

The security community has known about deserialization vulnerabilities for a few years but they were considered to be theoretical and hard to exploit. Chris Frohoff (@frohoff) and Gabriel Lawrence (@gebl) shattered that notion back in January of 2015 with their talk at AppSecCali – they also released their payload generator (ysoserial) at the same time.

Unfortunately, their talk did not get enough attention among mainstream technical media. Many called it “the most underrated, under-hyped vulnerability of 2015”. It didn’t stay that way after November 2015, when security researchers at FoxGlove Security published their exploits for many products including WebSphere, JBOSS, WebLogic, etc.

The PayPal bug is now fixed, but Stepankin doesn’t think we’ve seen the end of this type of vulnerability.

Softpedia quotes him:

I’ve seen a couple of other PayPal applications which use Java serialization, but It was hard to exploit them or company has already implemented some fixes to mitigate that issues. At the same time, I’m pretty sure we will see a lot of serialization vulnerabilities in different Java applications (not only in PayPal) and frameworks in the following years.

Image of PayPal courtesy of /