Insecure firmware is running on millions (and soon-to-be billions) of devices. Connected cars, coffee pots, and cardiac devices house embedded firmware that’s often highly vulnerable and easily hackable. Why? It literally all comes down to the firmware’s code: how it’s constructed, what’s left inside and what’s included from the outside.
Think about these three points, which are tied to actual exploitations and hacks:
- Gaping holes: The Dyn attack in October 2016 exploited insecure and poorly coded firmware on security cameras to cripple significant portions of the web. If the firmware had been secured, the attack could not have been executed. If firmware has security holes, hackers will find them.
- Carelessness with keys: Have you heard people say “don’t leave your keys laying around?” Then why would developers leave their private crypto keys in firmware images? We know firsthand of a Tier One supplier for a car manufacturer that left private crypto keys on a completed firmware image they produced for the manufacturer. You can imagine what happened next.
- Insecure external libraries: If you’re integrating externally sourced libraries and lack access to the source code of the libraries, can you verify their security? Third-party libraries can contain extraordinary numbers of vulnerabilities, and even a giant like Apple learned the hard way when using insecure, external libraries.
It’s ironic that secure coding practices are decreasing at a time when overall security practices are increasing. But, in today’s frenzied development environments, the faster developers must build code and the more “cooks” involved, the greater the chances for insecure coding.
With many forces at play to foster insecure coding on devices, security might seem like a pipe dream. Yet, consider the huge number of security holes in Windows software that were corrected over time. Through automated firmware evaluations, it’s neither difficult nor time-consuming to review a compiled firmware image and fix the code.
Insecure coding is the basis for all IoT security issues; mitigating firmware risks hinges on evaluating and securing firmware before production. It’s everyone’s responsibility to secure their firmware in this global IoT village. We’re all as strong as the weakest link and risk mitigation must become a top priority for those who build code for embedded devices.