1. Backdoor testing accounts.
Engineers often include backdoor mechanisms and testing accounts in hardware for debugging purposes, with trivial or no security measures put in place to protect them. Unfortunately, a large number of devices make it to market without having these mechanisms and accounts disabled, allowing attackers to gain illegitimate access to the device.
2. Unsecured network management protocols.
Many devices implement SNMP or UPnP for remote management, but fail to implement even basic levels of security around them. Office equipment, networking hardware, industrial control systems, etc. often leak sensitive data (such as the routing table) via SNMP, and may provide various control functions via UPnP. Many UPnP-enabled devices implement the standard network interface management functions, which allow an attacker to disable a network interface. Further functions may allow an attacker to permanantly damage the device, or cause severe problems with functionality.
3. Buffer overflows.
Hardware implementations are notoriously bad for not checking target buffer sizes, and can allow complete corruption of the memory state. This may result in code execution, but more commonly simply results in a denial of service condition, where the device must be hard-reset before it can be used again.
4. Integer overflows / underflows.
These occur when an unsigned integer input is treated as signed, or a larger integer type is directly cast to a smaller integer type. Both of these issues may result in cases where a value is outside the expected range, which can cause array range checks and buffer length checks to pass despite the input buffer being too large. These can also result in read-what-where conditions, where a negative array index leads to memory operations accessing preceding memory regions.
5. Insufficient sanity checks.
Input values in hardware implementations are usually considered to have strong integrity, so sanity checks are often not performed. This might allow a malicious user to supply an unexpected value and change the behaviour of the device. A common example of this is when a set of bit-flags are used, and conflicting bits are set.
6. Shared, hard-coded secrets embedded in non-volatile memory.
Hardware designers are sometimes under the delusion that because something is stored in an EEPROM chip on a board, the data within it will not / cannot be read by someone who wishes to interfere with the device. It is common to find hard-coded cryptographic keys and other credentials stored in the firmware of a device. These might be used to compromise the device or its communications, and are often the same across all devices of the same model.
7. Poor quality, self-designed or missing crypto.
Often it is complicated to implement proper cryptographic algorithms in embedded systems, especially when working with less widesrpead microcontrollers and microprocessors. Reference implementations often assume x86-like or ARM-like architectures, which increase the work factor. Engineers also usually lack the knowledge and experience to properly implement cryptography. As such, cryptographic algorithms found in embedded systems tend to be poorly implemented, or are home-brew designs with serious security flaws. Many systems completely lack any form of hashing on passwords and other credentials. This type of data can usually be extracted from non-volatile memory using off-the-shelf tools.
8. Lack of strong integrity and authenticity checking on firmware upgrades.
The integrity of device firmware is often checked via a CRC32 or MD5 hash, but is rarely authenticated via any strong means. Many manufacturers rely on obscurity as a security measure. Whilst the cost of reverse engineering the firmware of a device may be considerable, it is becoming less so with the advent of common microprocessor architectures (e.g. ARM) in embedded systems. Once an attacker gains the ability to upload a firmware image, they may entirely subvert the system.
9. Various web-application flaws in control panels.
Many of the OWASP Top 10 web application flaws are disturbingly common in web control panels for embedded devices. CSRF, XSS and session theft feature highly in the list of common vulnerabilities, though SQLi is less common due to the relatively low number of systems that implement a full relational database.
10. Improperly bound network services.
Many network services on embedded devices are configured to bind to 0.0.0.0, rather than directly to a LAN IP address. This may allow an attacker to communicate with the device from outside the LAN. Appropriate segregation and firewall configuration may help to mitigate this, but it is still a concern.
