Hi folks, Allen Householder here. I want to introduce some recent work we're undertaking to look at vulnerability discovery for emerging networked systems (including cyberphysical systems like home automation, networked cars, industrial control systems and the like). In this post I cover the background and motivation for this work, our approach, and some preliminary findings. In future posts I will cover additional results from this effort.

The project started as "Vulnerability Discovery for Low Power and Low Bandwidth Networks," which quickly became a misnomer as we realized we were really talking about "non-traditional computing" made up of small-scale components and encompassing cyberphysical systems like medical devices, home automation, industrial control systems, smartgrid, and the internet of things (IoT). More recently we've used the phrase "Emerging Networked Systems (ENS)" as the shorthand for what's essentially an "everything else" category of things that probably have an exposed network interface yet are neither full-scale computers nor phones.

Our objective is to look at vulnerability discovery techniques for ENS and determine if and how those techniques differ from vulnerability discovery in traditional computing. We also wanted to identify useful processes, tools, and techniques to improve the security of ENS from the perspective of their developers as well as those who acquire, deploy, and operate them.

This work was motivated by observations made in the course of recent work done by the CERT Vulnerability Analysis team, including

We identified issues such as the inclusion of networked appliances in a larger system where the appliances provided networked services based on sensor data. Enterprise security policy treated the device as a black box rather than a general purpose computer with regard to patch levels, included software, etc. The attack vector posed by the sensor data interface had not been considered either.

In a number of projects, we observed that while many systems were composed of highly specified off-the-shelf and custom components, the vendors providing those systems often could not identify the third-party subcomponents present in the delivered codebase. The problem can be as simple as not identifying statically linked libraries or as complicated as dealing with complex supply chains for code components.

We observed various devices with wireless data capabilities embedded within a larger system yet little or no ability to patch the fielded systems except within very sparse service windows. Instances where physical contact with the device is required in order to update it can be especially problematic once vulnerabilities are discovered. (See Dan Geer's talk at the Security of Things Forum for more on the "long-lived and not reachable" problem.)

We also encountered smart grid devices built out of a traditional electrical component coupled to an embedded Linux system to provide networked services. In a deployment context, the device was treated as an appliance. However the impact of potential vulnerabilities in the general purpose operating system embedded in the device had not been fully addressed.

In discussing this work with other security researchers, we found that some were dismissive of the risks posed by the IoT. A typical comment was that IoT is uninteresting because its elements are "just refrigerators, toasters and crockpots, so who cares if they get owned?" We disagree:

• "Smart things" are expected to outnumber traditional computers in the near future and will likely surpass mobile phones not long thereafter.
• The scope of systems and devices covered by our definition of ENS is much broader than IoT, but even IoT is more than just kitchen appliances. ENS will have implications to the protection of privacy, opportunities for fraud and abuse, and ensuring safety.
• Every vulnerable thing becomes a potential point of leverage for an attacker to persist or maneuver laterally through a network.
• Immature security on ENS can leak information that could allow an attacker to gain a foothold (e.g., the recent report of the LIFX WiFi Lightbulb leaking wifi credentials via unsecured inter-bulb communications).

Because many such systems and devices are expected to remain operationally useful for years or even decades with minimal intervention, it is especially important that their security be thoroughly understood prior to deployment.

Our approach involves three phases:

1. Survey recent research for methods and tools used to discover new vulnerabilities in this space.
2. Develop a repeatable analysis process for identifying common threats and exposures in these systems.
3. Apply and refine the process on a few different systems.

In this post, I focus on phase 1, our survey of recent related work.

We collected more than 70 papers and presentations from the following venues: ACSAC 2010, ACSW-AISC 2013, Australian Information Warfare and Security Conference 2011, BlackHat 2009, 2010, 2011, 2012, 2013, CanSecWest 2007, 2008, 2009, 2010, ACM CCS 2012, Chinacom 2012, Critical Infrastructure Protection (Springer) 2012, DefCon 20 and 21, DerbyCon 2013, Financial Cryptography and Data Security 2011, GreHack 2013, HealthSec 2011, HealthTech 2013, ICACCI 2013, IEEE Conference on Technologies for Homeland Security HST 2012, IEEE Transactions on Smart Grid, Infiltrate 2013, International Journal of Scientific & Engineering Research (April 2012), ITU Telecom World Technical Symposium 2011, NDSS Symposium 2013, PETS 2013, Cyber Security and Information Intelligence Research Workshop 2013, Recent Advances in Space Technologies (RAST) 2013, Shmoocon 2011, 2012, 2013, and Usenix Security 2010

The papers covered topics including

• Home and home automation: home security sensors, zigbee devices, WeMo, NEST Thermostat, Smart TVs
• Physical security and asset management: RFID systems, z-wave door locks, surveillance cameras
• Transportation: Automobile tire pressure monitoring, aerospace embedded devices, nextgen air traffic control, autonomous vehicles
• Utility monitoring and controls: Smart meters, smart grid, SCADA, metering systems, industrial control systems
• Health and personal fitness devices: Fitbit, automated external defibrilators, insulin pumps
• Financial: Counterfeit money detectors

As we reviewed the research in our survey, we found a number of techniques in common use. Ranked in approximately descending order of popularity in the research we surveyed, the vulnerability discovery techniques used were

1. Reading documentation: This includes product data sheets, protocol specifications, Internet Drafts and RFCs, manufacturer documentation and specs, patents, hardware documentation, support sites, bug trackers, discussion forums, FCC filings, developer documentation, and related information.
2. Reverse engineering: In most cases, this consists of reverse engineering (RE) binary firmware or other software to understand its function. However, there are instances in which merely understanding a proprietary file format is sufficient to direct further analyses. Hardware RE appears in some research, but has not been as prevalent as RE of software or file formats. As security researchers develop more hardware knowledge and skills (or as individuals with those skills become security researchers) we expect the prevalence of hardware RE to increase in the security literature.
3. Protocol analysis: Understanding the communication protocols used by a system is vital to identifying remotely exploitable vulnerabilities. This technique can take the form of simply sniffing traffic to find mistrusted input or channels, or reverse engineering a proprietary protocol enough to build a fuzzer for it. Decoding both the syntax and semantics can be important. In wireless systems this technique can also take the form of using a software defined radio (SDR) to perform signal analysis, which for this purpose is essentially protocol analysis at a lower level of the stack.
4. Modeling and simulation: Threat modeling from the attacker perspective was mentioned in a handful of papers, as was modeling and simulation of either the system or its protocols for further analysis using mathematical techniques such as game or graph theory.
5. Fuzzing: Generating randomized input is a common way to test how a system deals with arbitrary input. Fuzzing of network protocols is a common method cited in a number of reports.
6. Input or traffic generation and spoofing: Unlike fuzzing, spoofing usually consists of constructing otherwise valid input to a system to cause it to exhibit unexpected behavior. Constructing bogus input from a valid or trusted source also falls into this category.
7. Scanning: Because most ENS are composed of multiple components, each of which may have its own architecture and code base, it is often the case that a researcher can find known vulnerabilities in systems simply by using available vulnerability scanning tools such as Nessus or Metasploit.
8. Hardware hacking: This technique involves interfacing directly with the electronics at the circuit level. It is a form of physical-level reverse engineering and can include mapping circuits and connecting with JTAG to dump memory state or firmware.
9. Debugging: This technique uses software-based or hardware-based debuggers. JTAG is a common hardware debugging interface mentioned in many reports.
10. Writing code: This technique involves developing custom tools to assist with extracting, characterizing, and analyzing data to identify vulnerabilities.
11. Application of specialized knowledge and skills: In some cases, just knowing how a system works and approaching it with a security mindset is sufficient to find vulnerabilities. Examples include RFID, ModBus, etc.

Many of the techniques listed in this post are common to vulnerability discovery in the traditional computing and mobile world. However, the low hanging fruit (or as some have put it, the windfall) appear to hang much lower in ENS than in traditional computing. From a security perspective, even mobile systems have a head start although they are not as far along as traditional computing platforms. The fact is that many of the vulnerabilities found thus far in ENS would be considered trivial (and rightly so) in the more mature market of servers and desktop computing. Yet the relative scale of the ENS market makes even trivial vulnerabilities potentially risky in aggregate.

Wrapping up, I hope this post has given you a better understanding of how researchers are finding vulnerabilities in ENS and provides some background on why our vulnerability research and analysis at the CERT/CC is branching out in this direction.

In my next post I'll discuss some of the ways ENS are different from traditional computing and mobile systems.