Defcon 22-cesar-cerrudo-hacking-traffic-control-systems

IOActive, Inc. Copyright ©2014. All Rights Reserved.
Hacking Traffic Control Systems
(U.S, UK, Australia, France, etc.)
Cesar Cerrudo
@cesarcer
CTO, IOActive Labs

About Me
• Hacker, vulnerability researcher, created novel exploitation
techniques, dozens of vulnerabilities found (Microsoft® Windows®,
SQL Server®, Oracle®, etc.).
• Developed, sold exploits, and 0day vulnerabilities
(7-10 years ago)
• CEO of software company
• CTO at IOActive labs
• Live in small city in third world country, far away from everything

Thanks
• Barnaby Jack
• Ruben Santamarta
• Mike Davis
• Mike Milvich
• Susan Wheeler
• Ian Amit
• Robert Erbes

How all started
• Found news that London was going to implement wireless
devices for traffic detection
– After some research found the devices vendor name
– Vendor ended up being interesting target, widely deployed
• +250 customers in 45 US States and 10 countries
• 200,000+ Wireless sensors deployed worldwide, most of them
on the US
• Countries include US, United Kingdom, China, Canada,
Australia, France, etc.
– After reading available documentation I had strong feeling
the devices were insecure

How It All Started
• Getting the devices
– Social engineered the vendor
– Shipped them to Puerto Rico and traveled with them back
and forth to the U.S. from Argentina several times with no
problems

Devices: Wireless Sensors
• Magnetometer, installs in a small hole
• Rugged mechanical
design, 10 year battery life
• TI CC2430 RF transceiver IEEE
802.15.4 system-on-chip 2.4-GHz
• TI MSP430 MCU (microcontroller)
16-bit RISC CPU , i386 Linux
(probably TinyOS RTOS)

Devices: Wireless Sensors

Devices: Access Point
• Processes, stores, and/or relays sensor
data (uCLinux)
• 66 MHz 5272 Coldfire processor, 4 MB
flash memory, 16 MB DRAM
• Contact closure to traffic controller, IP
(fiber or cellular) to central servers, PoE
• Supports as many sensors as necessary,
Can serve as IP router for peripherals
(video cams, etc.)

Devices: Repeaters
• Battery powered unit
• Supports up to 10 wireless sensors
• Relays detection data back to access
point, extending range
– One channel for getting data and
another channel for sending data

Devices: Radio ranges

How Devices Work

Software
• Windows software to manage and configure access points,
repeaters and sensors
– Coded in Flash/ActionScript (Adobe Airl) so it’s easily to decompile
– It connects directly to AP and uses it to send commands to sensors
and repeaters
• Server software used to get all information from APs and then
send them to Traffic control systems
• …and Cloud! SaaS used to remotely access APs at any place in
the world

Vulnerabilities
• No encryption, all wireless communication in clear text
• Vendor claims:
“Security: SNP radio transmissions never carry commands; only data
is transmitted. Therefore, while RF communications may be subject to
local interference, there is no opportunity to embed malicious
instructions to a network device or upstream traffic system.”
“The option for encrypting the over the air information was
removed early in the product's life cycle based on customer
feedback. There was nothing broken on the system as we did not
intend the over the air information to be protected.”

Vulnerabilities
• No authentication
– Sensors and repeaters can be accessed and manipulated over the
air by anyone, including firmware updates
– AP does not authenticate sensors, just blindly trusts wireless data
• Firmware updates are neither encrypted nor signed
– Anyone can modify the firmware and update it on sensors and
repeaters
• Vendor claims:
“We are encrypting/signing firmware in new sensor version” (they just
forgot a little and insignificant detail…)
“Security: Proprietary protocol – hacker safe”

Protocol
• IEEE 802.15.4 PHY, used by ZigBee and other wireless
systems
– Data rate of 250 kbps, 16 frequency channels in the 2.4 GHz ISM
band
• Sensys NanoPower (SNP) protocol
– On top of 802.15.4 PHY as Media Access Protocol (MAC)
– The MAC layer is TDMA based and uses headers similar to
IEEE 802.15.4 MAC layer.

Protocol
• Sensors stay awake for a minimum amount of time and
prevent any network packet collisions.
• While sensors listen and transmit at specific time slot,
access point can get and process sensor packets at
any time
• Sensors will transmit every 30 seconds if no detection
(depends configuration)
• Access point acknowledges reception; each sensor re-
transmits data (4-5 times then sleeps) if
unacknowledged

Protocol
• Packet structure: 80 80 55 AA BB 55 55 55 55 55 55
[frame header (2 bytes)] + [sequence # (1 byte)] + [address
(2 bytes)] + [data]
• Frame header is used to specify the type of packet
• Sequence # from sensor packets is used by AP to
acknowledge them
• Address is used to identify sensors by the AP and second
byte in address is ”color code” used by sensors to identify
the AP

Protocol
• Data can be 4 to 50 bytes long, first two bytes is data
type
– Sensor data: mode, version, battery level, detection
(presence or not of traffic), etc.
– AP data: commands, synchronization, sensor and
repeater firmware updates, etc.

Protocol
• Sample packets
80 41 69 CA B6 65 00 FF 7F -> sensor to AP, no detection
event, count mode
80 41 67 CA B6 65 00 CE E7 -> sensor to AP, detection event,
count mode
80 41 C0 CA B6 02 00 4C 00 03 00 03 BA 00 00 00 00 65 00
00 00 00 02 CA B6 FF 00 -> sensor to AP, sensor info
80 80 89 F0 FF 01 00 07 1E 40 07 C0 01 1A 00 00 00 00 00 00
40 40 20 01 00 ->AP to sensor

Protocol
• Firmware file, ldrect proprietary format
l0012AF10DADAAAE1E60C5A00006A0200301330136C19021B3013A461D0303013301342
l0088AF10DADAAA6FC60D5A00006A0200308930896C8F02913089A4D7D0A63089308937
l2012301330133013301330131C1700130012030003004C00FFFFFFFFFFFFFFFFFFFFDF
l2088308930893089308930891C8D00890088030003004C00FFFFFFFFFFFFFFFFFFFFB9…
• Firmware update packet
80 00 45 F0 F4 D2 00 00 12 AF 10 DA DA AA E1 E6 0C 5A 00 00 6A 02
00 30 13 30 13 6C 19 02 1B 30 13 A4 61 D0 30 30 13 30 13
– AP firmware broadcast, data part except first two bytes is a
exact line from firmware file without the checksum byte

Tools
• Hardware
– TI CC2531 USB dongle for IEEE 802.15.4 sniffing
– TI SmartRF05 evaluation board
• Software
– TI SmartRF Packet Sniffer IEEE 802.15.4
– TI SmartRF Studio 7
– IAR Embedded Workbench IDE

Attack Impact
• +200,000 sensors and ? repeaters worldwide that could be
compromised and maybe bricked
• Traffic jams at intersections, at ramps and freeways
– Rest in green (exceeds max. green time), Red rest (all red until
detection), flashing, wrong speed limit display, etc.
• Accidents, even deadly ones by cars crash or by traffic blocking
ambulances, fire fighters, police cars, etc.
• US DOT Federal Highway Administration (Traffic Detector Handbook):
“…sensor malfunctions and associated signal failures increase
motorists’ time and delay, maintenance costs, accidents, and
liability.”

Onsite Passive Testing
• Made AP portable
– USB powered instead of PoE with USB battery charger
– WiFi portable router battery powered, connect notebook
to AP by WiFi
• Put AP in my backpack and went to Seattle, NY, and
Washington DC
– Took out notebook and start sniffing around in the
sidewalk while pointing my backpack in the right
directions
– Saw some spooks at DC but got no problems
– Video

Attacks
• DoS
– Disabling sensors/repeaters by changing configuration or
firmware
– Making sensors/repeaters temporarily (maybe permanently)
unusable by changing firmware
– Flooding AP with fake packets
• Fake traffic detection data
– Send lots of car detections when there is no traffic
– Send no detection on stop bar at exit ramps
– Disable sensors/repeaters and send no detection data when
there is a lot of traffic

Attacks
• Deployments easy to locate
– Vendor and partners PR, presentations, etc.
– Cities traffic department documents, news, etc.
– Cities approved vendors, RFP, documents, etc.
– Google Street View
• Need to be a maximum 1000 feet away from devices
– Attacker onsite - Demo
– Attaching attack device with GPS to buses, taxis, cars, etc.
– Attacking from the sky: drones (drones on demand?) - Demo

Attacks
• Sensor malicious firmware update worm
– Compromise one sensor with malicious firmware and it can
replicate later on other sensors
– Impossible to know if there are already compromised sensors
since firmware version is returned by firmware itself
• NSA/Gov/Special Forces/terrorist/etc. style attacks
– Locate persons in real time, hack smartphone, launch attack
– Use sensor car identification data to trigger bomb when car
target is near, no need to track car, just sniff sensor wireless
packet (Cadillac One fingerprint?)

Conclusions
• Any third world guy can easily get devices used by U.S. critical
infrastructure, hack them, and then attack the U.S.
• Anyone can build a $100 device to cause traffic problems in
most important cities in U.S. and other large cities around the
world.
• Critical infrastructure related technologies should be properly
audited to make certain that they are secure before use
• Smart cities are not so smart when the data that feeds them is
blindly trusted and easily manipulated
• Cyberwar is cheap

Headline + Image

Fin
• “Battles can be won being smart not just with a great attack
power. We need to focus more on ideas, on innovation, trying
to do things in different ways as hackers usually do”
• Questions?
• Gracias.
• E-mail: ccerrudo@ioactive.com
• twitter: @cesarcer

Disclaimer
• All images are copyright to their respective owners.
• Images 1,2,3,4,7,8,9,10,11,12,13,14,15,16,17 source:
Sensys Networks®
• Image 18 source: Texas Instruments®
• Image 20, 21 source: Street View- Googe® Maps

Defcon 22-cesar-cerrudo-hacking-traffic-control-systems

More Related Content

Defcon 22-cesar-cerrudo-hacking-traffic-control-systems