This is the first of a multi-part series where we will share some of our methodology for supply chain verification in situations where there is very limited information. This content was previously shared by Sophia d’Antoine at Square’s r00ted1 Conference on November 14th, 2018 in NYC. We have previously shared our thoughts on the importance of supply chain validation with regard to hardware attacks, but this blog series will delve deeper into the specifics related to case alleged in Bloomberg Businessweek’s “The Big Hack” article.
In the past few months, media reporting1 2 on alleged Chinese backdoors via one or more types of hardware implants which compromised American products and companies has raised the public’s awareness of the risk of security compromise via hardware. For those of us who deal with hardware security daily, such allegations are not a big surprise. Our team has worked on designing, securing, and hacking hardware used in places ranging from startups to security-critical government applications, and one item that is in almost every assessment that we do is a circuit board tear-down and detailed parts identification.
In the hardware hacking community, one of the tried-and-true “go to” tools for serial communication, dumping SPI flash chips, and interacting with basic JTAG interfaces is the GoodFET, developed by our neighbor Travis Goodspeed. Some of the GoodFET instructions are a bit outdated and fragmented, and we recently were asked for help installing this on a modern Debian-based system, namely the Kali Linux security distribution. We have written up those procedures here in the hope that they are useful to people working with the GoodFET hardware.
While we are always excited to both learn and share the latest technical developments in cybersecurity (the recent Black Hat and DEF CON conferences were no exception), we also enjoy stepping back once in a while to look at macro trends in the embedded security industry. While security is a top priority in many enterprise and industrial settings, here are three key concepts that we think are important for us all to keep in mind:
SummerCon is a different type of conference than most, and honestly sometimes it’s tough to hear the talks over the noise of the crowd at the bar. This year, the organizers added a second venue to try to spread out the noise from the great conversations and impromptu meetings, so some of the talks could be heard. We wanted to share a few notes on our teams’ key takeaways from the weekend.
At River Loop Security, we are always looking to advance the state of cybersecurity research alongside our work tackling our clients’ toughest problems. Presenting our research at computer security conferences is one way that we hope to share our lessons learned with the community. This summer, we’re excited to present at BlackHat USA and DefCon. We’ll be showcasing some select areas of our team’s research: 1) RF Fuzzing and Hardware Tools, 2) Reversing a Windows Antivirus Emulator, 3) Understanding Attack Attribution.
This is the second of two blog posts where we will share a summary of the differences. We encourage you to read the first post for background on the purpose of this post and discussion of security levels and keying techniques. The ZigBee and ZWave protocols have both undergone numerous revisions and support many different security modes and edge cases. In this discussion, we will try to focus on core design decisions and features, and leave out discussion or investigation of edge cases for brevity.
We have performed in-depth evaluations of many products built on ZigBee and Z-Wave for clients, and we are often helping clients understand vulnerabilities in IoT products built on standard protocols such as these. We believe that it will benefit the overall community to share a brief summary of our comparisons between these two popular protocols based on the recent ZigBee 3.0 and Z-Wave S2 specifications which both aimed in-part to update the protocols to an increased level of security.
As part of our continued commitment to supporting open-source tools, we have added support to KillerBee for the Sewino Open-Sniffer 802.15.4 capture interface. This is the first supported device capable of 900 MHz sniffing. The KillerBee code is available to use it, although we are not actively maintaining and testing this integration. We welcome improvements to the integration or collaborations to expand the supported interfaces further. You can also read about the integration on their site.
We have announced the ApiMote v4beta design and released it as open-source hardware at the TROOPERS14 security conference. This hardware was designed specifically with security researchers and assessors in mind, and is supported by the KillerBee software toolkit and GoodFET. We believe it offers unique capabilities unfulfilled by other interfaces currently available. If you want to use this board, you can build it based on the open-source design files or obtain a pre-built, tested, and programmed one from us.