Open wireless and default passwords make controlling a city's intersections trivial.

Taking over a city’s intersections and making all the lights green to cause chaos is a pretty bog-standard Evil Techno Bad Guy tactic on TV and in movies, but according to a research team at the University of Michigan, doing it in real life is within the realm of anyone with a laptop and the right kind of radio. In a paper published this month, the researchers describe how they very simply and very quickly seized control of an entire system of almost 100 intersections in an unnamed Michigan city from a single ingress point.

Enlarge/ Nodes in the traffic light network are connected in a tree-topology IP network, all on the same subnet.

The exercise was conducted on actual stoplights deployed at live intersections, "with cooperation from a road agency located in Michigan." As is typical in large urban areas, the traffic lights in the subject city are networked in a tree-type topology, allowing them to pass information to and receive instruction from a central management point. The network is IP-based, with all the nodes (intersections and management computers) on a single subnet. In order to save on installation costs and increase flexibility, the traffic light system uses wireless radios rather than dedicated physical networking links for its communication infrastructure—and that’s the hole the research team exploited.

Wireless security? What's that?

The systems in question use a combination of 5.8GHz and 900MHz radios, depending on the conditions at each intersection (two intersections with a good line-of-sight to each other use 5.8GHz because of the higher data rate, for example, while two intersections separated by obstructions would use 900MHz). The 900MHz links use "a proprietary protocol with frequency hopping spread-spectrum (FHSS)," but the 5.8GHz version of the proprietary protocol isn’t terribly different from 802.11n.

In fact, using unmodified laptops and smartphones, the team was able to see each intersection’s broadcast SSID, though they were unable to join the networks due to the protocol differences. The paper notes that researchers could have reverse-engineered the protocol to connect but instead chose to simply use the same type of custom radio for the project as the intersections use. Lest you think that’s cheating, the paper explains the decision like this:

We chose to circumvent this issue and use the same model radio that was deployed in the studied network for our attack. While these radios are not usually sold to the public, previous work has shown social engineering to be effective in obtaining radio hardware [38]....

Once the network is accessed at a single point, the attacker can send commands to any intersection on the network. This means an adversary need only attack the weakest link in the system.

The 5.8GHz network has no password and uses no encryption; with a proper radio in hand, joining is trivial.

Smash box

After gaining access, the next step was to be able to communicate with the controllers that operate each intersection. This was made easy by the fact that in this system, the control boxes run VxWorks 5.5, a version which by default gets built from source with a debug port left accessible for testing. The research team quickly discovered that the debug port was open on the live controllers and could directly "read and write arbitrary memory locations, kill tasks, and even reboot the device."

Debug access to the system also let the researchers look at how the controller communicates to its attached devices—the traffic lights and intersection cameras. They quickly discovered that the control system’s communication was totally non-obfuscated and easy to understand—and easy to subvert:

By sniffing packets sent between the controller and this program, we discovered that communication to the controller is not encrypted, requires no authentication, and is replayable. Using this information, we were then able to reverse engineer parts of the communication structure. Various command packets only differ in the last byte, allowing an attacker to easily determine remaining commands once one has been discovered. We created a program that allows a user to activate any button on the controller and then displays the results to the user. We also created a library of commands which enable scriptable attacks. We tested this code in the field and were able to access the controller remotely.

Once total access to a controller and its commands was gained, that was it—at that point, the team had full control over every intersection in the entire network. They could change lights at will and even control each intersection’s cameras. The paper lays out several potential activities that an attacker could engage in, including connecting from a moving vehicle and making all lights along the attacker’s path green, or purposefully snarling traffic to aid in the attacker’s escape after a crime.

More worrying is the ability of an attacker to engage in a type of denial-of-service attack on controlled intersections by triggering each intersection’s malfunction management unit, which would put the lights into a failure mode—like all directions blinking red—until physically reset. This would, according to the paper, let "an adversary… disable traffic lights faster than technicians can be sent to repair them."

Mitigation

The paper closes by pointing out a number of ways in which the gaping security holes could be easily closed. Chief among the recommendations is some kind of wireless security; the paper points out that the 5.8GHz systems support WPA2 encryption, and enabling it is trivial. The 900MHz systems are more secure by virtue of not using a frequency band easily accessible by consumer laptops and smartphones, but they also support the older WEP and WPA wireless encryption standards.

But a layered defense is best, and as such the paper also recommends stricter controls over the traffic systems’ IP networks—firewalling devices and strictly controlling the type of network traffic allowed.

Further, though many of the components in the network support some kind of username and password authentication scheme, the report ominously points out that "all of the devices in the deployment we studied used the default credentials that came built into the device." Doing some basic housekeeping and changing the credentials on the VxWorks intersection controllers and the wireless network components would go a long way toward frustrating attacks.

Should we panic?

It’s hard to not get a little antsy when confronted with research showing that vital pieces of public infrastructure are sitting essentially unsecured. The paper’s conclusion is clearly stated: "While traffic control systems may be built to fail into a safe state, we have shown that they are not safe from attacks by a determined adversary." There is plenty of blame to be cast, from the local agencies deploying infrastructure hardware in an unsafe state to the manufacturers helping them set things up.

In fact, the most upsetting passage in the entire paper is the dismissive response issued by the traffic controller vendor when the research team presented its findings. According to the paper, the vendor responsible stated that it "has followed the accepted industry standard and it is that standard which does not include security."

Lee Hutchinson / Lee is the Senior Reviews Editor at Ars and is responsible for the product news and reviews section. He also knows stuff about enterprise storage, security, and manned space flight. Lee is based in Houston, TX.