Last year I became interested in working with M2M (machine to machine) systems. M2M is the simple idea of two computers communicating directly with each other without a human in the loop.
As an example of M2M, consider a so-called smart utility meter that is able both to transmit load information in real time to a server at the power company, and to receive command and control instructions in return from the server. (The actual communications could take place over a cellular network, a powerline network, or perhaps even over the Internet using a telephony or broadband connection.) An excerpt from that Wikipedia article demonstrates the types of new functionality that are enabled through real-time bidirectional communications with utility meters:
The system [an Italian smart meter deployment] provides a wide range of advanced features, including the ability to remotely turn power on or off to a customer, read usage information from a meter, detect a service outage, change the maximum amount of electricity that a customer may demand at any time, detect unauthorized use of electricity and remotely shut it off, and remotely change the meter’s billing plan from credit to prepay, as well as from flat-rate to multi-tariff.
Of course, with great power comes great opportunities for circumventing the security measures engineered into M2M components. In an environment where devices are deployed for years, where device firmware can be difficult to update, and where devices are often unattended and not physically well secured—meaning potential attackers may have complete physical access to your hardware—it can be very challenging to implement low-impact, cost-effective protections.
Responding to this challenge, several researchers have given presentations or released papers that describe fascinating attacks against the security components of M2M systems. In one well-known example, Barnaby Jack explained the technical details behind several attacks he created that reprogram Automated Teller Machines (and demonstrated live attacks against two real ATMs on stage) in a presentation at the Black Hat USA 2010 security conference. In another, Jerome Radcliffe described at Black Hat USA 2011 how he reverse engineered the communication protocols that are used to configure an insulin pump and to report glucose measurements to the pump.
In reviewing these published attacks, I’ve developed a threefold taxonomy to help M2M engineers consider and mitigate related risks to their security architectures they develop. In each category I list three examples of published attacks:
1. Attacks against M2M devices
A. Use a programming or debugging interface to read or reprogram a device.
B. Extract information from the device by examining buses or individual components.
C. Replace or bypass hardware or software pieces on the device in order to circumvent policy.
2. Attacks against M2M services
A. Inject false traffic into the M2M network in order to induce a desired action.
B. Analyze traffic from the M2M network to violate confidentiality or user protection.
C. Modify component operation to fraudulently receive legitimate M2M services.
3. Attacks against M2M infrastructure
A. Extract subscriber information from M2M infrastructure control systems.
B. Identify and map M2M network components and services.
C. Execute denial-of-service (DoS) attacks against infrastructure or routing components.
I’ve written a whitepaper that explores the technical details of three published attacks in the first category: A survey of published attacks against machine-to-machine devices, services, and infrastructure—Part 1: Devices. (TCS intends to publish parts 2 and 3 later this year, covering attacks against M2M services and infrastructure.)
My goal with the whitepapers is to illustrate the hacker methodology—the clever, creative, and patient techniques an adversary may use to attack, bypass, or circumvent your M2M security infrastructure. (As a side note, I am grateful to the M2M security researchers and hackers who have been willing to share their methodology and results publicly.)
The key takeaway is to think like an attacker! by preparing in advance for when and how security systems fail. A Maginot Line strategy for M2M may not be effective in the long term. I often recommend such planning to include (a) a good security posture before you’re attacked, (b) good logging, auditing, and detection for when you’re attacked, and (c) a good forensics and remediation capability for after you’re attacked.