Vulnerabilities / Threats // Advanced Threats
8/9/2014
03:00 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Researcher Finds Potholes In Vehicle Traffic Control Systems

Hundreds of thousands of road traffic sensors and repeater equipment are at risk of attack, researcher says.

LAS VEGAS — DEF CON 22 — Smart traffic sensor systems that help regulate and automate the flow of traffic and lights contain security weaknesses that could be manipulated by hackers and result in traffic jams or even crashes, a researcher showed here today.

Cesar Cerrudo, CTO at IOActive, here at the DEF CON 22 hacker conference, detailed how he was able to build a prototype access point device that could communicate with the network of sensors, repeaters, and access point devices stationed along roads and highways in some major cities in the US. Cerrudo said he found that the devices communicate traffic information wirelessly in clear text and don't authenticate the data they receive, leaving them open to potential sabotage.

He said there are some 200,000 wireless Sensys Networks sensors buried below roadways plus repeaters mounted on poles, mostly in the US. The sensors detect vehicles, and that data ultimately dictates the timing of traffic lights and electronic traffic event alerts on the highway.

"It's about $100 million worth of equipment that can probably be bricked and cause a traffic jam. You can send fake data that there's no traffic there, and cause a big mess."

An attacker would need to know the configuration of the road intersection, for example, where the access point, repeaters, and sensors are stationed. "You can sniff the wireless data, learn how the system was configured, how it was working, and then just launch an attack with fake data." The access point will accept the phony traffic data, he said.

Because the sensors don't authenticate the origin of the data they receive, an attacker could push them malware-laden firmware as an update, for example. Nor is the sensor's firmware digitally signed, he said, leaving the door open for malicious code installation. Cerrudo reported his findings to ICS-CERT, which handles vulnerability disclosures in critical infrastructure systems.

"The problem is the firmware is not encrypted, and the communications channel is not encrypted," Cerrudo said. "That makes the device vulnerable, so anyone can update the firmware wirelessly without encryption."

But Sensys Networks, meanwhile, says it has built-in features in its traffic control equipment that would protect against the download of unauthorized code to its sensors, as well as "attempts to insert false detection data." The company said in a statement that customers are notified if any rogue activity occurs with the devices.

Cerrudo said Sensys, in response to his research, the bulk of which was first made public in April, maintained that it had originally included encryption in the sensors, but ultimately removed the feature after its customers requested it. "That's a really crazy answer," said Cerruto.

Sensys Networks had not responded to the encryption issue as of this posting.

The devices operate over the 802.15 PHY wireless protocol, which provides a low data rate and low power consumption option for this type of network traffic. Cerrudo said the sensors include a Texas Instruments MSP430 microcontroller that runs a version of Linux.

Cerrudo was able to carry in a backpack his prototype access point to passively test access to the traffic control systems in major cities, including Washington and New York. He was able to reach them by pointing his backpack at the APs, from a maximum of 150 feet from the real access point.

But he was also able to access the traffic control equipment from about 650 feet, using a drone he rented. "I'm sure you can go higher… you just need a line of sight."

Like other researchers who are rooting out security bugs and flaws in embedded devices in critical infrastructure equipment, home automation systems, automobile automation features, and smart medical devices, Cerrudo acknowledges his work is likely well ahead of the real risk of malicious attacks. "Some of this hardware is very difficult to get -- you can't go to the store and buy it. That's good, because for the bad guys, it's not easy."

But Cerrudo says a determined attacker could do what he did -- "social-engineer" the equipment vendor to purchase the equipment, or even steal it.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Kelly Jackson Higgins
100%
0%
Kelly Jackson Higgins,
User Rank: Strategist
8/14/2014 | 10:10:37 AM
Re: IoT Encryption Takes Energy
Good point, @bpaddock. Energy is a key part of the equation here. I also wonder if there are products that have connectivity that really don't need it--that was a suggestion that came up last week in Vegas. Simplify them for security. 
bpaddock
50%
50%
bpaddock,
User Rank: Apprentice
8/14/2014 | 10:05:36 AM
Re: IoT Encryption Takes Energy
What you say is true.

However with current IoT technology the devices are run from small batteries or minute amounts of energies extracted from the environment (Solar, Thermal, Vibration, RF etc).
So it is not exactly the past "performance/convenience", now we also have the added complication of finding the needed energy to run the IoT devices.

In this case there may be not enough energy to power the device to do everything that the device should, so the device fails to function at all (some may see that as good thing).

Myself I keep wondering who is really pushing for the world of IoT, just because we can, doesn't mean we need it...
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
8/14/2014 | 8:46:04 AM
Re: IoT Encryption Takes Energy
This is the age-old security dilemma of performance/convenience versus security -- but on steroids in the case of IoT. Some things never change.
bpaddock
50%
50%
bpaddock,
User Rank: Apprentice
8/14/2014 | 8:24:52 AM
IoT Encryption Takes Energy
"originally included encryption in the sensors, but ultimately removed the feature after its customers requested it. 'That's a really crazy answer,' said Cerruto."

From the IoT design perspective it, unfortunately, makes sense. 

MSP430 parts achieve their low power by not being speed daemons.  Encryption algorithms require energy (speed) that these parts simply don't have.  If all of the computer cycles are spent on the encryption, there are not enough cycles to get the actually task at hand done.

Unfortunately we see the same energy/security trade-offs in medical devices as well.

With the current technology ubiquitous IoT is always going to be a trade-off between the energy available to run the device, and what we really want the device to run.

 
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
8/13/2014 | 10:19:03 AM
Re: Crossing the Cyber-Physical Barrier
 The "current lassez faire approach to its security" we are taking, @Some Guy, definitely puts us on the road (to hell) that is paved with good intetentions!
Some Guy
50%
50%
Some Guy,
User Rank: Strategist
8/12/2014 | 7:16:42 PM
Crossing the Cyber-Physical Barrier
I think the most important distinction to make with the Internet of Things (IoT) is that we have crossed over from the Cyber world to impacting the Physical world. IoT starts out as sensors everywhere, but they are really (or eventually may be) the inputs and outputs of real-world control systems. And it's the transition from the *Data* domain to the *Control* domain that marks the critical distinction and crux of their potential for good ... and for harm if we continue to take the current lassez faire approach to its security.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
8/12/2014 | 2:57:31 PM
Re: Jeepers
Based on the consumer safety record of the auto industry to date, I don't have a lot of confidence in its ability to effectively manage the onslaught of security issues from the Internet of Everything (automotive). I hope I am proven wrong...
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
8/12/2014 | 11:55:56 AM
Re: Jeepers
ICYMI, this is a good start--public awareness and specifics on what carmakers can/should do: http://www.darkreading.com/application-security/automakers-openly-challenged-to-bake-in-security/d/d-id/1297902?
Sara Peters
50%
50%
Sara Peters,
User Rank: Author
8/12/2014 | 11:34:25 AM
Re: Unsurprising, But Scary
@AlisonDiana  That's a really interesting point, Alison. One would think that since many of these newly networked devices (the IoT stuff) don't need to be accessible to the general public, that they'd be easier to lock down. 

On the other hand... if they're only locked down with passwords, and people use the same password for everything, then the whole authentication thing is pointless. Maybe key fobs and fingerprints are the best way to go with this stuff.
Sara Peters
50%
50%
Sara Peters,
User Rank: Author
8/12/2014 | 11:29:49 AM
Jeepers
With some guys hacking the cars and other guys hacking the road signs, the roads seem even less safe than usual.  ;) Makes me feel better about taking the subway.
Page 1 / 2   >   >>
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-5395
Published: 2014-11-21
Multiple cross-site request forgery (CSRF) vulnerabilities in Huawei HiLink E3276 and E3236 TCPU before V200R002B470D13SP00C00 and WebUI before V100R007B100D03SP01C03, E5180s-22 before 21.270.21.00.00, and E586Bs-2 before 21.322.10.00.889 allow remote attackers to hijack the authentication of users ...

CVE-2014-7137
Published: 2014-11-21
Multiple SQL injection vulnerabilities in Dolibarr ERP/CRM before 3.6.1 allow remote authenticated users to execute arbitrary SQL commands via the (1) contactid parameter in an addcontact action, (2) ligne parameter in a swapstatut action, or (3) project_ref parameter to projet/tasks/contact.php; (4...

CVE-2014-7871
Published: 2014-11-21
SQL injection vulnerability in Open-Xchange (OX) AppSuite before 7.4.2-rev36 and 7.6.x before 7.6.0-rev23 allows remote authenticated users to execute arbitrary SQL commands via a crafted jslob API call.

CVE-2014-8090
Published: 2014-11-21
The REXML parser in Ruby 1.9.x before 1.9.3 patchlevel 551, 2.0.x before 2.0.0 patchlevel 598, and 2.1.x before 2.1.5 allows remote attackers to cause a denial of service (CPU and memory consumption) a crafted XML document containing an empty string in an entity that is used in a large number of nes...

CVE-2014-8469
Published: 2014-11-21
Cross-site scripting (XSS) vulnerability in Guests/Boots in AdminCP in Moxi9 PHPFox before 4 Beta allows remote attackers to inject arbitrary web script or HTML via the User-Agent header.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?