Best Practices to Ensure Your Device Is Secure by Design – Firmware

Secure firmware is well designed firmware. Most firmware breaches exploit faults in the code, and so the best way to protect against attacks is to ensure we follow security guidelines during development.

Let’s look at some of the most common exploits hackers use to compromise a system and how to address them.

1.        Buffer and Stack Overflow Protection
The biggest problem with buffer overflows is that they change the content in memory the buffer should not have access to (causing memory corruption). This kind of vulnerability can be exploited by an attacker to change the instruction pointer register and have the device execute arbitrary malicious code. To protect against buffer overflows, one must avoid using APIs that are considered unsafe (e.g. the C functions - strcat, strcpy, sprintf and scanf). Memory corruption can be caused by both Stack Overflows and Heap Overflows.

2.        Injection Prevention
A potential risk comes from accepting user input or outside data to be processed by the system. An attacker can use this to inject malicious code which the device is forced to execute. Thus, it is crucial that all input data and all user input be validated, sanitized, and/or outputs encoded to prevent unintended system execution.

3.        Firmware Updates and Cryptographic Signatures
Updates are a vital component of a product life cycle. They help add features, fix problems, and keep up with evolving security standards. However, hackers have devised many ways of exploiting update mechanisms to install their own applications on devices. This is why it’s so important to employ robust update mechanisms that use cryptographically signed images, which allow the bootloader to verify that the image has not been modified or tampered with.

4.        Securing Sensitive Information
Sensitive information such as passwords, usernames, private keys, etc., should never be hardcoded into firmware. Saving them in plain text is likewise very dangerous because they can be compromised. It is recommended that such information be stored in memory with hardware security elements. If such a feature is not available, they must be encrypted using a strong cryptographic algorithm before being stored in memory.

5.        Usage of Debug Code and Interfaces
Developers must often add debug code in order to debug issues, but this may introduce backdoors into systems. This is why it is important to ensure all unnecessary pre-production build code, as well as dead and unused code, has been removed prior to firmware release. Any test users with elevated permissions should also be removed.

6.        Transport Layer Security
Ensure all methods of communication utilize industry standard encryption configurations for Transport Layer Security (TLS). The use of TLS ensures that all data remains confidential and untampered with while in transit. This can protect personal information, but also prevent attacks (i.e. Man-in-the-middle).

7.        Data Collection Usage and Storage - Privacy
It is important to limit the collection, storage, and sharing of personal identifiable information and sensitive information. Even with strong security features, storing such information can pose a risk to the user, as their identity can be stolen. It is vital that if personal information is collected, concepts of Privacy-by-Design are followed (i.e.: embedding privacy protections into the design specifications of information technologies).

8.        Third-Party Code, Components and Credentials

Third-party code is useful in reducing cost and development time, but it’s very important that it be kept up to date. Developers continuously fix issues they find in their libraries and not applying these patches can be a security risk for the end application.

A good tip is to maintain a “Bill of Materials” with all the third-party software that is being used in the application. This way it’s easy to keep track of the version of a third-party component and identify any vulnerabilities in it.

Likewise, third-party credentials present a possible weak link in firmware security. It’s important to verify credentials from third-party sources, since any security issues to which third-party code is vulnerable (e.g.: a Trojan backdoor) will be inherited by your firmware.

As shortening development time has become an important goal, both developers and companies have commonly overlooked firmware security. The dangers of doing so should be apparent, and hopefully this article has illustrated some of the pitfalls for you. With such a dramatic exploitation of firmware vulnerability since 2016, the need for firmware security is more pressing than ever.

The good news is that many of the security issues affecting firmware can be fixed by employing good coding practices. Some of the most dangerous attacks can be prevented by sanitizing data and user input before processing it.

Keep an eye out for the third piece in this series that will cover designing secure devices from the perspectives of software. Together with this article and the earlier piece on hardware, these three articles will give you a comprehensive view of what you need to consider to ensure your next device is secure.