PayPal has addressed a serious remote code execution vulnerability caused by a Java deserialization bug disclosed last year, and shared some recommendations for security practitioners based on the lessons learned in the process of dealing with the issue.
Deserialization of Untrusted Data
In January 2015, researchers Chris Frohoff and Gabriel Lawrence explained how poor coding practices can lead to Java deserialization flaws and allow arbitrary code execution. The experts also released a tool for generating payloads that exploit unsafe Java object deserialization.
Their presentation at the AppSecCali conference went largely unnoticed until November, when FoxGlove Security demonstrated how easy it is for an attacker to exploit the vulnerabilities against Oracle WebLogic, IBM WebSphere, Red Hat’s JBoss, Jenkins, OpenNMS and other applications that rely on the Apache Commons Collections Java library.
Serialization is a process in which an object is converted to a stream of bytes in order to store or transmit that object to memory or a file. The process where serialized data is extracted is called deserialization. Vulnerabilities can appear when the developers of applications that use serialization fail to ensure that untrusted serialized data is not accepted for deserialization.
Apache Commons Collections developers patched the flaw, but the issue is not specific to this Java library. SourceClear researchers reported in early December that they had identified tens of other libraries that could introduce similar vulnerabilities. Furthermore, as PayPal has pointed out, deserialization of untrusted data is not specific to Java either. Mitre’s description of the issue notes that it can affect applications built on platforms such as Python, PHP and Ruby.
Java Deserialization Vulnerability in PayPal Application
After FoxGlove Security published its exploits for applications using Apache Commons Collections, PayPal started analyzing its own apps in an effort to determine which of them are affected. The company’s initial assessment, which focused on its core Java frameworks, showed that they hadn’t used any of the vulnerable classes in the Apache library.
However, a remote code execution bug report submitted to PayPal on December 11 by Mark Litchfield, founder of the Bug Bounty HQ service and one of the top researchers in the payment processor’s bug bounty program, showed that the issue did affect one of the company’s apps. Litchfield used the exploit generator published by Frohoff and Lawrence to demonstrate the existence of the flaw.
PayPal missed the flaw in its initial assessment because the application was not in its core Java frameworks.
While PayPal did not disclose the name of the vulnerable application in its blog post, security researcher Michael Stepankin said he reported the same flaw two days after Litchfield. In a blog post published on Monday, Stepankin released technical details and a video demonstrating the existence of the vulnerability in PayPal’s Manager portal hosted at manager.paypal.com.
The researcher said the vulnerability allowed him to execute arbitrary shell commands on PayPal’s servers and gain access to production databases.
“I realized that I could execute arbitrary OS commands on manager.paypal.com web servers and moreover, I could establish a back connection to my own internet server and, for example, upload and execute a backdoor. In result, I could get access to production databases used by manager.paypal.com application,” Stepankin said.
The researcher told SecurityWeek that PayPal awarded him $5,000 despite classifying his submission as a duplicate.
“While we acknowledge it is not our typical practice, we can confirm that two researchers were awarded payments in connection with the same bug,” PayPal told SecurityWeek.
Advice From PayPal
PayPal has provided a series of recommendations for handling such complex Java deserialization vulnerabilities on a large scale.
The company advises security practitioners to invest in tools and technologies that help inventory applications, libraries and their dependencies, and implement monitoring until a proper patch is applied. On short term, organizations should focus on patching high-risk systems that are exposed to the Internet. On long term, organizations should keep in mind that deserialization problems are not specific to Apache Commons Collections or Java and either completely turn off object serialization everywhere or learn how to address the risks.
“We understand that today’s application infrastructure is complex and you don’t own/control all the code that runs in your environment. This specific deserialization vulnerability is much larger than any of us initially anticipated – spanning across open source components, third-party commercial tools and our own custom code,” PayPal said. “Other organizations should treat this seriously as it can result in remote code execution and implement security controls for long-term remediation, and not stop just at patching the commons-collections library.”