4 Things to Know About the Muni Hack
- What kind of attack was it?
- How was the attack carried out?
- Has the hacker done it before?
- Can it happen again?
Two decades ago, the concept of hackers launching large-scale attacks against critical public infrastructure was little more than a movie plot line. For years, it seemed more like a potential joke than a possible reality. As more of our lives became digitized, though, and more and more of our infrastructure joins the giant web of the Internet, the threat has grown.
One of the first major threats was, of course, the Stuxnet worm which worked to damage Iran’s centrifuge program. That was malicious software developed by agents of a government — but what about threats from your average hacker? Those are here too, and here to stay, and that’s what brings us to the topic for this show: the recent ransoming attempt of San Francisco’s public transit system after a high-profile hack.
It serves as a shocking wake-up call as to the potential vulnerabilities in systems which millions of people rely upon every day. With impacts that spanned days, an attack from the Internet turned into the cause of some real-world chaos. While SF’s transit system, also known as Muni, is now recovering and largely back to normal, the aftershocks will likely continue to be felt for some time. Whether you’ve heard about the Muni hack already or you’re just hearing about it for the first time here, there’s a lot to know.
What exactly happened, and how could it have been allowed to take place? We’ll discuss the answers while we dive into four of the things you should know about the Muni hack. From its execution to its implications, we’ll cover everything you need to know and leave you with some food for thought. So, what exactly is important to know about the event that led to many of San Francisco’s Muni riders enjoying free transit for several days?
What kind of attack was it? This time around it was a ransomware attack. Ransomware is becoming a hot topic these days as more and more hackers turn to tactics that include denying you access to your system and demanding payment in return. The corresponding rise of cryptocurrencies like Bitcoin means that these attackers often have easy access of a way to anonymously demand payment from hapless victims. However, the Muni hack is an order of magnitude more severe than a personal laptop infected with ransomware that has encrypted your files.
By the time the hacker finished, nearly a thousand employee computer workstations had been locked down by malware. Also, the attacker also cut off access to Muni’s internal email system and crippled the transit authority’s ability to track hours worked for employees in their payroll system. After compromising the system, the hacker displayed messages featuring poor grammar and demanding payment of about 100 bitcoins (over $70,000 at prevailing market rates).
Sounds pretty bad, right? The good news is that the metro management team had plans in place for dealing with this kind of threat. They just ignored the hacker’s demands and began to work to remove the problematic infection from their system. Muni also chose to simply disable their pay terminals, granting everyone free rides for several days. The free ride tactic was actually a precaution to avoid disruption in case the ransomware tried to lock down these systems as well.
Thanks to diligent backups, Muni could restore the affected systems back to a functioning state while closing the vulnerability that let the hacker into the server. At this point you might be asking yourself: how on earth was someone able to compromise the system so thoroughly?
How was the attack carried out? The attack exploited a known Java vulnerability. Believe it or not, the vulnerability that the attacker exploited has been known for over a year — and patched for about the same amount of time. The gritty details of the exploit have to do with how computers move files around as data. This is a process called serialization and deserialization. The attacker exploited a vulnerability that allowed him to insert his own arbitrary data into a portion of this process, effectively gaining trusted access to digital spaces where he didn’t belong.
When a computer serializes data, it’s transforming the file — taking it from being an entity residing on a disk and turning it into a stream of bits and bytes moving from one place to another. Deserialization is naturally the opposite of that — taking a stream of data and writing it back to disk. The flaw, found in the Apache Commons library, was disclosed as CVE-2015-4852 in early November 2015. Any server running a particular Java environment, known as JBoss, was vulnerable to this attack — and the Muni Metro fit the bill. It was this same vulnerability that put hospitals in Maryland at the mercy of ransomware earlier this year.
So how did the attacker settle on the Muni system? It was almost like a drive-by attack. The hacker ran his own server filled with tools that searched for vulnerabilities present in other servers. Once he discovered a target with the right weaknesses, he deployed malicious data to trigger the exploit and gain access. That’s what let him get straight to the core parts of Muni’s system.
Once there, the attacker didn’t need to be creative. He simply sent out two standard pieces of ransomware, called HDDCryptor and Mamba. This malware not only infects and encrypts the machine it lands on, but also any connected network drives or other machines. Without a key supplied by the hacker, it can be very difficult to unlock the contents of the hard disk again. It then alters the computer’s boot record to display the attacker’s message of choice. In this case, that was the uninspired phrase “you hacked.”
Of course, all of this raises the question — if the hacker was looking for targets all the time, was Muni the only victim?
Has the hacker done it before? The wasn’t the first time this hacker has attacked a system. While the San Francisco metro system might be one of the highest profile attacks the attacker engineered, it was far from the first. As a matter of fact, it seems that he could exploit the same vulnerability and extract ransom payments from many of the organizations against which he launched these attacks. Some even turned to him for advice on closing the loophole — this is how we know exactly the method used to exploit the Muni system.
Speaking of, how do we know so much about the hacker, his other victims, and his methods? The answer may make you laugh: the hacker was hacked back! An independent security researcher took what was known, such as the email address used to make demands and communicate, and guessed the hacker’s own security question. This gave the researchers access to a trove of information on the way the ransomer ran his operation.
For example, one unnamed US manufacturer fell victim to the scam. Unlike Muni, which refused to cooperate or communicate with the attacker, this firm chose to pay the ransom — a total of more than 60 bitcoins. That’s tens of thousands of dollars lost because of simply not applying regular updates to critical software. This wasn’t an anomaly, either; even companies in China fell victim to the same scam and forked over the dough.
Further research reveals that manufacturers and builders made up most of the hacker’s targets. So, what led them to choose to launch an attack against Muni? The motive seems unclear. Maybe he simply thought he could score a larger payday by affecting an important service. Given the sloppy nature of the execution, it seems unlikely it was an attempt to send a message or cause real damage. Whatever the reason behind the attack, though, it put a big spotlight on the issues we face regarding guarding our infrastructure.
Can it happen again? Obviously, this isn’t the first time something like this has happened — nor is it the first major ransomware attack. The Medstar hospital attack we mentioned is just one such example. We can see another startling example that cropped up during the unrest that has plagued Ukraine for some time now. There, hackers launched a huge attack against an electricity station. They quickly used their access to not just shut off power, but to cause lasting damage to the area’s electrical grid.
While nothing quite so dramatic has happened on US soil so far, it’s not hard to see how that could become the case. We aren’t trying to sound alarmist, of course! However, it’s something which every organization should take very seriously. The Muni hack demonstrates the potential ramifications of even a seemingly mundane carelessness like not updating your server software on a timely basis. While riders weren’t affected, the hack did result in the loss of several days of revenue for the system. Such costly mistakes are just the tip of the iceberg when it comes to consequences.
Where and how we’ll see the next major hack or ransomware attempt against infrastructure is impossible to say. We think it’s a safe bet to say Muni certainly won’t be the last victim. In fact, it’s even likely that the Muni hacker will continue to exploit other companies with the same tactics! Just one more reason to make sure you’re always on top of your security updates.
In the midst of an endless number of hectic news cycles throughout 2016, it seems like the Muni hack is flying a bit under the radar. Despite the lack of long term attention paid to the story, it represents a chilling moment in the evolution of cyber attacks against real targets. Stories about password hacks might get more traction, and there’s no doubt that’s a crucial security issue as well, but the potential vulnerabilities in infrastructure must receive closer scrutiny.
It seems obvious that the hacker who attempted to ransom an entire city’s transit network was amateurish in his efforts at best. We should hope efforts will be made to harden security further in the future to prevent someone more skilled and more motivated from making a bigger splash!
That wraps things up for this episode! If you’d like more information on the topic we covered today, or if there’s a specific topic you’d like to see featured on a future episode, send us an e-mail at email@example.com!