Your Firmware Code Just Might Land You in Jail
Firmware Code from Hell
Imagine this scenario:
A teenager modifies the firmware code on a remote device to change signals on several trams for pubic transportation. A train crashes causing a derailment in which 12 people were injured.
Not possible you say?
Or how about this:
Cyber attackers consider hacking firmware code or threatening to hack pacemakers to deplete their batteries, modify the pacing or cause shocks.
Something like those scenarios could never happen, right?
Well, how about this scenario:
Hackers break into your Internet-connected security cameras or baby monitors then post private videos online of you or your children.
Although these scenarios may sound like crazy stories out of a good novel or movie, they aren’t as far fetched as you may think. These are actual stories of actual attacks, and in some cases, with actual victims.(1)(2)(3)
All of these attacks could have been prevented if you actually cared about security. But you don’t.
How I Know You Don’t Care About Secure Code in Your Firmware
Because you continue to use poorly written code and insecure coding practices when making these connected devices whether they be baby monitors, security cameras, pacemakers, or railway control systems.
I’ve see numerous examples of insecure coding practices and poorly written code when analyzing firmware with the Centrifuge Platform.
Most attacks against these devices start with the easiest attack vector: default user names and passwords. As a user of any Internet connected device, a consumer’s first interaction with the device should be to change the default user name and password. That action alone would thwart a significant number of IoT based attacks.
The second attack vector is the firmware, which is the heart and soul of an IoT device. It’s the code that you write which is embedded in the device and brings it to life.
This is where your poor coding comes into play.
Hackable firmware is exploitable firmware – in most cases – via a command injection attack or a buffer overflow attack.
Command Injection Attacks
In a command injection attack, a hacker can send your device specific instructions to perform an administrator level type of action such as dumping passwords or listing the contents of directories.
Command injections attacks could be prevented by you eliminating, or at the very least limiting, calls to system(), exec(), and popen().
Buffer Overflow Attacks
In a buffer overflow attack, a hacker can send data to your device causing the contents to spill over – overflow – into areas of memory where the attacker’s code could be executed instead of your legitimate code.
Done correctly, the hacker could execute commands to deplete a battery, adjust temperature, download stored videos, swipe passwords, derail trains, etc.
Buffer overflow attacks, thought to have been fairly eradicated by now in most desktop and mobile applications, have seen a resurgence in the IoT space because of you. Prevention of these attacks is as simple as the command injection attacks.
Too Many Insecure Fuctions
Too frequently you use functions like strcpy(), scanf(), gets(), sprint() and others when their more secure counter parts could be implemented. This is negligence on your part. Or just plain stupidity.
These are not new, trendy preventive measures or some new coding implementation. In fact, these have been around the programming world for decades. Why you are not using them when developing your firmware for IoT and other connected devices is another topic for debate.
You Need to Use Secure Coding in Your Firmware
Unfortunately few professors make mention of secure coding in their classes. If they do teach secure coding practices, then they belong to a very special group of professors doing the right thing. They may be akin to the handful of doctors in medical schools who teach their students good bedside manner.
Additionally, there is no governing bodies or other enforcing entities who police secure coding practices. The CERT Secure Coding Standards is a community-based development project that began in the Spring 2006. These are suggested standards, much like the NIST framework, which you are merely “encouraged” to use.
I understand the difficulty in enforcing secure coding practices, as there’s probably no money in anyone’s budget for these efforts. But, there’s deep frustration and concern among companies, consumers, and all who are impacted by the often-unfortunate results of hacks that disrupt – and sometimes threatens – our lives.
As of today, you can continue to ignore the poor coding practices utilized within your firmware. And you can continue to skate by and hope your device doesn’t become the next news headline like St. Jude Medical(5).
Or you could be proactive and begin to implement source code reviews and firmware evaluations prior to production or manufacturing.
Failure to Secure Firmware Code Might Land You (or Your Company) in Court
Your failure to be proactive, in my view, will result in either class action lawsuits being filed against you and your company by the FTC on behalf of customers, as in the case of TRENDnet(6), or the filing of product liability claims against you for cyber negligence.
I know life as a coder is rough. So here are some simple steps can you take now to make a real difference:
- Google is your friend. Perform a web search on the phrase “secure coding.” The results will likely include several tried and true lists of methods, including the CERT Secure Coding Standards. Use them. This is not rocket science.
- Watch videos about secure coding practices. They’re out there… if you care.
- Read books on secure coding. Remember those… books?
- Take a secure coding class. They’re usually not free, but are well worth the investment.
- Implement firmware evaluations as part of your QA process.
- Make a full commitment to consistently apply these practices in your work. Take the extra time to ensure you and your team are accountable to your system of secure coding.
So stop writing shitty code. You’re smart. Otherwise, you wouldn’t be where you are now writing code in the first place. Step up, take action, and start coding securely before you and your company find yourselves on the wrong end of lawsuit.
Backdoored firmware found in the supply chain of video surveillance chips from HiSilicon (a subsidiary of Huawei) allows remote access via Telnet.
A few days ago I decided to reverse engineer my router’s firmware image with binwalk. I’ve bought the TP-Link Archer C7 home router. Not one of the best, but good enough for my needs.
On February 4th, 2020 we deployed a new analyzer to the Centrifuge Platform, our automated firmware analysis platform which detects the presence of the Cable Haunt vulnerability in eCos-based firmware images.