Imagine this: A teenager modifies the firmware on a remote device to change signals on several trams, which derail at least four cars and injure 12 people.
Not possible you say?
Or how about this: Cyber attackers consider hacking or threatening to hack pacemakers to deplete their batteries, modify the pacing, or cause shocks.
To far fetched, right?
Or this one: Hackers break into your Internet-connected security camera or baby monitors then post private videos online of you or your children.
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 do I know you don’t care?
Because you continue to use poorly written and insecure coding practices when making these connected devices whether they be baby monitors, security cameras, pacemakers, or railway control systems.
Most attacks against these types of 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 if 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 exploited – in most cases – via a command injection attack or a buffer overflow attack. 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.
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.
Command injections attacks could be prevented by you eliminating, or at the very least limiting, calls to system(), exec(), and popen().
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 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.
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.
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: 1. 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. 2. Watch videos about secure coding practices. They’re out there… if you care. 3. Read books on secure coding. Remember those… books? 4. Take a secure coding class. They’re usually not free, but are well worth the investment. 5. Implement firmware evaluations as part of your QA process. 6. 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 a lawsuit.