Mr. Robot Disassembled: eps3.3_m3tadata.par2
Hello friend. I’m Ryan Kazanciyan, Technical Consultant for Mr. Robot. I’ve been working with Kor Adana — Writer, Producer, and mastermind behind the ARG — and the rest of the Mr. Robot team since the second half of Season 2. Throughout Season 3, I’ll be writing about the hacks depicted in the show, how they came together, and their basis in reality.
Spoiler Alert! This post discusses events from the fourth episode of Season 3.
Each season of Mr. Robot has featured at least one hack that, by sheer coincidence, ends up airing in close proximity to a similar real-world event. It shouldn’t come as a surprise that Season 3 would continue that trend. This week’s episode features exploits in the same software that led to one of the most widely-publicized breaches of 2017.
Towards the end of episode 301, Mr. Robot reunites with Tyrell and starts working to regain access to the E Corp network. He begins with passive reconnaissance, issuing queries on Shodan.io to find E Corp servers running Apache Tomcat — a popular open-source server platform for Java-based web sites (and one that’s often left unpatched or misconfigured).
This week, we learn that they’ve made progress towards their goal. Elliot tells Darlene that he’s discovered a compromised web server on E Corp’s network, and suspects that the Dark Army remains committed to Stage Two. During the scene, we get an on-screen glimpse of his research.
The left side of the screen includes two browser windows. The background window contains a write-up for Apache Struts security advisory S2–016, released in July 2013. Struts is a development framework for building Java-based web applications; it’s often used in tandem with Apache Tomcat to deploy and host them. S2–016 is a high-criticality vulnerability that provides any remote attacker with the ability to execute malicious code. That’s as bad as it gets.
If “Apache Struts” sounds familiar, you might have read about its role in the Equifax hack that went public in September. Newer vulnerability, same software. Struts unfortunately has a long history of serious security bugs. Back in 2014, I performed forensic investigations for companies that had been hit with a variety of Struts-based attacks — even long after patches were available. I drew inspiration from those experiences when Kor and I started working on the scene in March. We had no idea that Struts would make the news again later in the year!
The terminal window on the right side of the screen contains an excerpt of the Tomcat access logs. The displayed web requests show attempts to test for the vulnerability in one of the Struts demo applications, “struts2-blank”, which sometimes gets left behind on production systems.
I created these log entries by mimicking the checks that the Metasploit Framework conducts as part of its Struts Default Action Mapper exploit. In a complete attack, the requests would be followed by additional attempts to leverage the vulnerability, tailored for the victim host’s operating system and configuration.
The browser window in the foreground hints at yet another potential issue on one of E Corp’s web servers: an exposed Apache Tomcat Web Application Manager.
This page supports many server administration functions, including the ability to deploy new applications. By default, Tomcat hosts it at URL “/manager” on port 8080, although both settings can be reconfigured. Best practices dictate that the management page should be protected with a secure password — and limited to internal access only.
Unfortunately, many organizations fail to change the default Tomcat administrator username and password (admin / admin), and inadvertently allow remote access to the management interface. Others may initially lock it down, but regress to insecure settings during an upgrade or reinstallation. Even without the Struts vulnerability, an attacker with access to the Tomcat Web Application Manager on an E Corp server could deploy a malicious application, such as a Java-based “webshell” backdoor.
Between the Struts vulnerability and the exposed Tomcat manager page, the Dark Army clearly has the means to establish a foothold on at least one of E Corp’s internet-facing web servers. Where does that get them? Many real-world attacks start with the opportunistic compromise of an unimportant system. This server could simply be a stepping-stone as Mr. Robot attempts to regain access to E Corp’s internal network.
Fortunately, Elliott can now follow the trail of forensic evidence and try to keep up with the Dark Army’s next steps…
