Cybernetic Entomology: Devices with insecure firmware

Here is a paper that describes the results of a broad study of embedded devices containing firmware.

http://s3.eurecom.fr/docs/usenixsec14_costin.pdf

Same paper, different address:

http://firmware.re/usenixsec14/

Examination of the devices’ firmware revealed all of the following:

• RSA private keys and self-signed certificates from 35,000 online cameras. Many of which are mounted inside people’s private homes.
• Many hardcoded password hashes, enabling someone with knowledge from the device manufacturer to log onto the device directly bypassing the owners’ security. Most of these were described as “weak” and allowed easy recovery of the passwords.
• Hardcoded telenetd credentials allowing remote logons to about 2,000 devices.
• Hardcoded web login credentials allowing admin capabilities (including password setting and other security reconfiguration) for over 101,000 devices that have web interfaces for configuration.
• Numerous daemons and web interfaces which had been modified with deliberate backdoors allowing security to be subverted.
• Firmware in a set of home automation devices used by more than 500,000 customers, allowing root logons with no authentication by anyone in the local network.
• Widely used routers and wireless network hubs that have backdoors permitting root logins and security reconfigurations with no authentication. Many of these backdoors are usable remotely.
• SD memory cards that contain a web server allowing web-based administration of their firmware, including an XSS (Cross Site Scripting) vulnerability. In the case of systems booting from an SD card, this vulnerability could be used to gain root access.
• Ways to gain send arbitrary commands via Postscript to many printers via commonly printed documents such as webpages. Such printers can be commanded to send their memory (including other recently printed documents) to arbitrary IP addresses.

The implications of all of this are pretty dire if you’re trying to secure a network, and pretty damning if your customers trusted your devices for security and you are the people who actually did any of this horrible stuff.

But for now, let’s assume you’re in a position where you can prevent one of these bugs from happening.

Checklist items:

• Any procedure which sets a device to accept a default password or credential for configuration (or any other purpose) must not be one that can happen accidentally or remotely. It is not acceptable for a device to permit normal operation at the same time as open to login or configuration via a default password or credential.
• Is your company about to release something that has firmware which responds in any security-sensitive way to remote commands? Is there any circumstance, ever, where those remote commands can be issued other than with security credentials specifically chosen and set by the device’s owner? STOP. THIS IS A BUG.
• If the device allows a remote admin login, remote password reset, or remote security reconfiguration, and EVER has a default password for any such thing, and you answered ‘no’ to the question above, quit your job immediately and let someone who understands both English and security continue from here. Yes, I know it makes system administration more convenient. It also makes it more convenient for people who aren’t the ones you or your customers want as system administrators.
• Is your company about to release something that can respond to remote commands other than those set by the device’s owner, in ways that invade the owners’ privacy? STOP.
• If the device is a camera or a microphone whose security parameters can be changed remotely or whose recent images/sounds can be accessed remotely, or where those functions can EVER be accessed with a default password, and you’re still here, what the hell is wrong with you?! Seriously, get the hell out.
• Is your company about to release something that has firmware which executes ‘scripts’ from outside the device, such as PostScript, CSS, Word, TeX, HTML, Flash, Javascript, machine-code executable files, XSS, etc? If so have security-sensitive functions otherwise accessible to the scripting language been disabled? If not, STOP.
• Is your company about to release something that has firmware which executes any language at all, and exposes that interpreter (or that compiler, or that CPU/MCU/DSP/GPU) to any source of outside input not intended to be a source of things to execute? If so, filter that source of outside input to ensure that it cannot be used to present anything executable.
• Is your company about to release a device which contains any authentication tokens such as cryptographic keys, password hashes, passwords, login credentials, etc, that somebody will inevitably read out of firmware? STOP.
• Is your company about to release a device which you can imagine anyone having a motive to break into? If so have you checked the firmware for unauthorized backdoors inserted by people you need to fire?
• Are you manufacturing a device made out of components which have firmware? If so have these components been acquired from subcontractors? If so, have you checked the components for unauthorized backdoors inserted by subcontractors you need to sue?
• Are you rebranding and selling a device manufactured by someone else? If so are you bearing financial and/or legal liability for their security bugs? If not, do your customers know it?