The Cyber Independent Testing Lab is a security measurement company founded by Mudge Zadko (previously), late of the Cult of the Dead Cow and l0pht Heavy Industries and the NSA's Tailored Access Operations Group; it has a unique method for assessing the security of devices derived from methods developed by Mudge at the NSA.
Rather than parsing through sourcecode (static analysis) or attempting to disrupt the operations of running code (dynamic analysis), CIT uses "binary analysis," combing through the compiled firmware of target devices and looking for signs that the programmers who created that firmware made use of techniques that improved security. In other words, they're not looking at whether the code is secure: they're looking at whether the programmers took steps to ensure that any errors in their code was protected by hardening techniques.
In August, CIT released an important report on IoT devices, extracting the firmware for these devices from the updates on the manufacturers' websites and conducting longitudinal analyses of these firmwares to see how secure they were and whether they trended towards better or worse security. They analyzed 22 manufacturers' products — 1,294 in all — spanning 4,956 firmware versions spread across 3,333,411 binaries.
You can probably guess where this is heading: over a 15-year dataset, every vendor's security practices worsened over time; updates were more likely to introduce insecure techniques, rather than hardening devices. Rival manufacturers had converged on the same insecurities, suggesting that they used a common toolchain to develop their firmware.
CIT's report uses the vendor Ubiquiti as a representative case study of insecure practices that worsened over time, documenting practices also present in other vendors' development processes, including Asus, Belkin, Dlink, Linksys, etc.
Our research paints a grim picture of binary hardening in the IoT ecosystem.Vendors are failing to implement basic hardening features, including decades-old best practices.
Even more concerning is the obvious lack of testing for these features. If a vendor is able to remove most of the exploit mitigation from their product line, it undermines the value of asking customers to apply software updates.
Luckily, we think one of the most important takeaways is that there are low-effort paths that can be taken to improve the situation.
Many of these devices are low cost/high volume. They are given the minimal amount of development time to get a new product out the door. This means that security likely finds itself low on the list of priorities.
In the case of home routers and IoT devices, these devices sit in a location of privilege within the users’ home networks. Regardless of whether or not the device’s owner is an intended target, as “set it and forget it” appliances, these devices are an ideal hiding spot for botnets and other attacker-infrastructure. In short, it is a Good Idea for these devices to be reasonably secure.
Unfortunately, if the trend of minimal hardening does not change, these devices will continue to be a soft target for these types of activity.
That said, we conclude with two points which make us optimistic about the future.
More data and insight on these devices will hopefully drive behavior changes within the vendors.
The prevalence of duplicate binaries indicates that it might be possible to fix some issues at a single point. In the case of Buildroot, this can even be done by the community through pull requests.
Binary Hardening in IoT products [Cyber ITL]
(via Schneier)
