15

Fuzzing has become a very common place technique used for software testing and is heavily used to find security problems. There are many frameworks (sully, Peach Fuzzer etc.) that are geared up for fuzzing large, complex software systems. I have not found much information about fuzzing of smaller, simpler embedded systems (generally those that are small and simple enough to not run an OS).

These small systems are found everywhere - RFID card readers, burglar alarm systems, keyless entry systems, engine control units, HVAC controls, and so on. They frequently have very limited inputs and outputs (buttons, keypads, small character displays, LEDs, buzzers, RF communications). Complex networking (Ethernet, TCP/IP), serial ports etc. are rare.

I have had good success employing fuzzing like techniques to find security problems and see how the system behaves. Currently, this has largely comprised of fuzzing the formatting of packets sent into the system, based on observations of genuine packets. Some examples:

  • Using fuzzing to determine the structure of packets - sometimes you know the approximate packet format, but things like ID bits, checksums etc. are not always certain if you only have a small number of genuine devices or sampled transmissions.
  • Finding problems in packet decoding when packets are longer than expected - simple things like setting variable packet lengths to higher than expected values.
  • Finding limits of acceptable transmissions - things like retransmission are common in one-way RF systems. What is the smallest number of packets that will register as a correct transmission? How much can we vary the baud rate (i.e. is there good clock recovery in the receiver).
  • Finding the limits of jamming detection. How far can we push the system before jamming is detected? Finding undocumented features - for example, if 00 is arm, 01 is disarm, 10 is part-arm, what does 11 do?

One of the biggest challenges I have found is methods to detect the state of the system. This has generally ended up with a hodge-podge of outputs taken from LEDs, LCD buses and so on. I have been using Arduino and Arduino-like boards for the inputs and outputs (generally a Teensy 2.0). I also often need to include a method to power cycle the system in the event of a crash.

What I have been surprised by is that I cannot find many others performing work or research in this area. I'm largely making this up as I go along.

So, the questions are:

  • Are there any resources out there along these lines?
  • Can any of the complex fuzzing frameworks be used for this application?

(as an aside, I don't think this is a failure to google. Similar concepts include "glitching" and "fault injection", but I believe this to be distinct)

I have seen this training available: https://www.blackhat.com/us-13/training/peach-fuzzer-embedded-edition.html

Improve this question

2 Answers 2

Reset to default
7

Peach is excellent at fuzzing smaller embedded systems. The configuration and detection is the big difference for embedded systems. This tends to change device to device, but one of my most used tools is the Cana Kit Relay Controller (http://www.canakit.com/4-port-usb-relay-controller.html). Peach has a monitor module that is able to trigger the relays. I use this to turn devices on/off, or simulate a USB cable being plugged in/out, etc.

From there you need to handle detection. This will differ widely between device. Sometimes you can use JTAG, other times I have hooked up photo sensors to read LED's with the help of a small board such as the Teensy. With networked devices, usually a ping is a good starting point.

One advantage with Peach is adding a module to detect faults or perform device resets is easy if you have some basic coding experience.

When setup correctly you should be able to perform long term device fuzzing. This means the fuzzer is able to restart the device when a fault is identified or the device is unresponsive, and able to detect failure states that could be interesting to further research.

Improve this answer
2
  • Do you have more detail on controlling the output from Peach, say, working with the Teensy?
    – Cybergibbons
    Commented Apr 6, 2013 at 0:20
  • 1
    The Teensy is easy to interface with over USB Serial. Peach 3 has a serial port Publisher (I/O interface) for sending fuzzed data and receiving a response back. This is an easy way to interface.
    – Michael Eddington
    Commented Apr 8, 2013 at 20:48
2

You seem to be on the right track. As @Michael Eddington pointed out Peach is excellent at fuzzing embedded systems (not just to smaller simple ones in my experience). I have similar experience using it with a variety of methods to check if the device is still alive such as a simple ICMP message if it's networked, JTAG responses, or just a change in serial output when doing for example secure boot glitching. More advanced would be looking at for example a change in the power profile to detect a successful attack.

Regarding fault injection you can extract some ideas regarding setups by reading papers from conferences like FDTC, Cosade and the like.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.