Fuzzlon
Enigmatos researches interesting attack-vectors that may hinder vehicles’ security and safety.
Fuzzlon – Dumb 802.15.4 Fuzzer
Enigmatos researches interesting attack-vectors that may hinder vehicles’ security and safety. Recently, as part of our ongoing research, we investigated a peculiar CAN-connected device which has an external radio interface based on IEEE 802.15.4 protocol. This lightweight RF protocol is the basis for many “smart” IOT application communication protocols such as ZigBee.
The devices which use these protocols are not known for their security, and after some thinking we have concluded that the most cost-effective approach to find bugs in this device is the all-hailed Fuzz Testing.
There are many approaches for fuzz testing, some of them more complicated than others. When it comes to embedded devices, fuzz testing is quite a challenge. Most fuzzers inject inputs via files or pipes, trace the execution using binary-instrumentation and manage execution by creating and killing processes. These things are very different in embedded devices.
Input must be given either by hardware debugger (JTAG) or via some physical interface (in our case – a radio receiver). Tracing is difficult as we don’t have a simulator and the device is sensitive to timings so tracing using the debugger is not an option. Lastly, managing execution means to reset the devices which may be a lengthy operation. Considering all these obstacles, writing an intelligent fuzzer is quite a challenge!
We almost gave up on the idea, but then a seasoned friend gave me a precious advice – “start as stupid as possible and improve as you go, these embedded things are so fragile that if you poke them just a little, they will crumble…”. And so we decided to implement the dumbest fuzzer we could think of.
This fuzzer generates completely random packets and then “fixes” them to adhere to the minimal requirements of the 802.15.4 protocol – correct CRC, correct source/destination addresses and a few other constraints – and that’s it!
We connected a debugger to our target and connected a transmitter to our dumb fuzzer and started transmitting fuzzy packets. To our horror and delight, after a few hours, the target started crashing!
Seeing the positive results, we decided to open-source this code so others can use it in their research. We also hope to inspire others to build similar tools for other protocols and dumb-fuzz their way to success!
Before finishing this post, a few words about our setup –
We use ApiMote as our radio transmitter. However, I find it hard to recommend because it is based on dated and inactive GoodFET project that contains some annoying bugs I had to fix or overcome before I could actually use it… Yet, I couldn’t find any better device which fits my budget (e.g. SDR of some sort). So if you do use the Mote, I recommend to use the GoodFET project directly and to build and flash the latest code which contains my fixes.
Additionally, not every packet sent is also received, so I use the JTAG to log the actually-received packets, but this is the only breakpoint I use for each packet. Breakpoints have an expensive overhead which may distort the behavior of the target and slow down the fuzzing. (This is also the reason why we don’t feed the device with input via JTAG – we couldn’t get it to resemble the reality well enough.) We also added a breakpoint on reset/init and other error interrupts so I know when something fishy happens.
That’s about it.
