The day after Thanksgiving saw the San Francisco Municipal Transportation Agency hit with a ransomware attack. The attacker demanded 100 bitcoins (about $73,000) to unlock the computer systems and ticketing machines. According to security journalist Brian Krebs, the SFMTA wasn’t targeted for political reasons – it was a target of opportunity discovered by an attacker looking for vulnerable systems using widely available tools.
Although it's not clear what vector the attacker used to compromise the SFMTA,* the attacker is known to have targeted vulnerable Oracle server software. In fact, the SFMTA attacker reportedly offered to "help" his victims protect themselves against future attacks for a few extra bitcoins, and advised another of his victims to install a patch for a vulnerability in Oracle WebLogic Server.
So what is this WebLogic vulnerability the attacker was apparently looking to exploit? The Oracle vulnerability (CVE-2015-4852) is a weakness in the way some classes provided by Apache Commons Collections handled being serialized (written to disk) and deserialized, along with the extremely common bad Java coding practice of sending serialized objects over the network. In other words, to be successful this exploit needs a confluence of several security problems:
- failure to update with security patches
- vulnerabilities enabled in open source components
- poor programming practices that led to the vulnerability
But why would an attacker choose this particular angle of attack? Simple: a server with an unpatched deserialization vulnerability is essentially like a building with an unlocked door. An attacker can leverage the vulnerability to run any code he wants on the target system.
How many applications out there have this vulnerability? Well, Veracode studied this exact question and reported our findings in this year’s State of Software Security report. And what we found was sobering. An application needs two things to be exploited by this vulnerability. It needs a vulnerable version of Apache Commons Collections (version 3.0 through 3.2.1, or version 4.0), and it needs to practice unsafe deserialization – basically, to accept a serialized Java object over the network and attempt to do something with it.
And there are a lot of Java applications that have these two things. We found that about 50 percent of all Java applications had a vulnerable version of Apache Commons Collections, and about 25 percent of Java applications we scanned had the deserialization vulnerability. And Java applications are a big target population; of all the enterprise and vendor-written applications tested during this year’s State of Software Security study, about half were written in Java.
With such a wide attack target, it’s no surprise that the SFMTA ransomware attacker would choose to use this deserialization exploit. But how did this vulnerability come to be so widespread? And what can enterprise developers do about it? We’ll talk about those in the next blog post. In the meantime, check out the State of Software Security report for some more information on the Apache Commons Collections deserialization vulnerability.
This is the first part of a blog series on vulnerabilities in third-party components and what enterprise developers can do about them. Read part two: How One Open Source Component Put 25 Percent of Java Applications at Risk. Read part three: 5 Ways to Keep Your Applications Safe From Vulnerable Components.
*Note: an earlier version of this post attributed the SFMTA ransomware attack to an exploit of the Apache Commons Collection deserialization vulnerability. New information indicates that the attacker has exploited this vulnerability in other cases, but we cannot say for certain that this was the attack vector used against the SFMTA.