Are you at risk?
Our November blog looked at the Apache Commons Collections Component vulnerability. Although it had been known for over a year, it wasn’t until the 6th November that Foxglove security raised awareness of this vulnerability.
Catalin Cimpanu from Softpedia has now identified that Michael ‘Artsploit” Stepankin, an independent security researcher, discovered this critical security flaw in PayPal’s servers, an issue which would have enabled him to take full control of PayPal’s infrastructure.
Softpedia contacted Mr. Stepankin via email, to find out how easy it was to find the vulnerability in PayPal’s service.
“It was comparatively easy to find and exploit this particular vulnerability. In spite of that, only in the last year, security researches have found a way to exploit Java deserialization issues and a lot of Java developers are still not aware about that,” Mr. Stepankin told Softpedia. “But I have to admit that overall protection of PayPal applications is quite high and, in general, it’s not really easy to find even low impact vulnerabilities within PayPal’s bug bounty scope.”
Regarding the presence of other Java deserialization issues in PayPal’s applications, the researcher told Softpedia the following:
“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.”
What lessons did PayPal learn from the Java Deserialization Bug
Laksh Raghavan from PayPal Engineering has written a great review of the lessons they learned, which is well worth a thorough read.
He identified that the problems they faced are widespread amongst a lot of organizations:
- How to identify the applications that could potentially be affected?
- How to patch so many different libraries and applications?
- How to make these changes without taking applications down, particularly during ‘no shutdown periods’ such as holidays?
- How long this is going to take?
A key point that he raises is the issue of long-term remediation. As he points out
‘this vulnerability is not limited to commons-collections or Java per-se. This is an entire class of vulnerability like XSS. Your approach should be holistic accordingly.’
He also advises to turn off object serialization everywhere. But how can you do this?
Indeed, the real issue is the “Deserialisation of Untrusted Data” which has so far led to many similar vulnerabilities exploited in several applications by combining improper handling of deserialisation along with libraries that allow remote code execution. Such libraries are exploitable even when your application does not directly use them, just as long as they are on the classpath.
The core questions are:
- How to know whether you are vulnerable to this?
- If you are, how could you fix your bugs?
My colleague Myriam takes a more indepth look at these questions in this blog.
Waratek can help you in a couple of easy steps
Step 1 – With no code changes, you can run your application in a secure Waratek container. It doesn’t matter if this is a new or legacy Java application that runs in your data center or on the public or hybrid cloud
Step 2 – Set up a simple rule that will turn off object serialization
What does this mean for the future?
Because Waratek is located in the runtime environment, it is able to accurately identify requests and act according to your instructions.
With Waratek you can:
- Profile your application and ‘lock down’ unwanted actions, such as object serialization
- Set rules to stop known CVE’s without taking the application down
- Gather forensic information from application level actions
Waratek provides a straightforward evaluation process, which, within a couple of hours, will allow you to get a firm appreciation of the value Waratek can provide.
If you are interested in evaluating Waratek, then please get in touch with us and take a look at this issue in greater detail.