Until fairly recently, Linux developers have been spared many of the security threats that have bedeviled the Windows world. Yet, when moving from desktops and servers to the embedded Internet of Things, a much higher threat level awaits.  

“The basic rules for Linux security are the same whether it’s desktop, server, or embedded, but because IoT devices are typically on all the time, they pose some unique challenges,” said Mike Anderson, CTO and Chief Scientist for The PTR Group, Inc. during an Embedded Linux Conference talk called “Securing Embedded Linux.”

Anderson has been giving similar overviews at ELC since 2007, when attack and defense technologies were less sophisticated and embedded Linux was less of a target. With the increase in attacks on IoT devices, however, the topic is drawing more interest.

“With IoT, Linux is almost invariably involved, typically in the cloud or on border gateways,” said Anderson. Gateways aggregate data from sensor endpoints over low-power wireless radios — typically 802.15.4 protocols like ZigBee — and convert them for upstream routing to the cloud.

Gateways deployed in a “fog” model can limit the vulnerability of IoT endpoints. “The cloud model provides an incredibly large attack surface,” Anderson told the ELC audience. “If they can crack one endpoint, they may have cracked 20,000. In the fog model, the devices behind the gateway router aren’t routable, and you can’t get to them directly from the Internet.”

Even with basic security, a fog model can usually deter “script kiddies,” which Anderson defines as mischievous amateur hackers who are not necessarily malicious. A much higher security threat comes from professional hackers – black hats who are “in it for the money,” and engage in ransomware, credit card theft, or the new business of “malware to order,” said Anderson. White hats, meanwhile, try to stop black hats by detecting vulnerabilities at companies using tools such as penetration testing via the toolkits found in some distributions like Kali Linux. The most dangerous security threats come from well-funded, state-sponsored hackers, “typically black hats paid by a government, or maybe industrial spies, trying to launch a coordinated cyberattack.

By far the most common threat is an insider attack from employees. “It happens all the time — employees go into debt and decide to sell company information,” said Anderson. “Peer review is one of the best ways to stop this. Open source has a major advantage in detecting insider attacks since thousands of people are looking at the code. Ideally, you will also bring in an independent security professional.”

Getting Physical

The first line of defense is physical security, which can involve technologies like fingerprint readers and access cards. Typically, an IoT gateway is not protected in a secure data center with locked doors, guards, and security systems, however, so the device itself needs to be hardened.

At the very least, you should “remove any debugging interfaces and blow the e-fuses,” said Anderson. You can add anti-tamper sensors, specialty screws, and instrumented cases which, if triggered, “set something in permanently-stored memory that lets you know the device has opened up.” Physical access can be further slowed by “potting the device in epoxy so you won’t be able to get access to the motherboard.” However, “dedicated hackers can apply chemicals to melt the epoxy,” he added.

Even if a hacker can’t get inside a device, they can use techniques such as differential power analysis, which analyzes the current drawn by the CPU to differentiate between decoding a zero and a one. “You can extract 2,040 eight-bit keys in about 10 seconds, but you need a radio and power management device sitting right on the target,” said Anderson.

Attackers often use rootkits to look for vulnerabilities in the power-on jump cycle in order to penetrate the boot cycle. This type of intrusion can be countered with one-time programmable memory, smart cards, Intel’s AMT, or trusted platform module (TPM) solutions, said Anderson.

Linux Confidential

Most security solutions revolve around the concept of confidentiality — making sure unauthorized individuals can’t read the data you want protected. Confidentiality solutions differ depending on whether you’re protecting “data in flight” (crossing the network), “data at rest,” or “data in use.”

For data in flight, the main concern is with a man-in-the-middle (MitM) attack, which typically exploits a vulnerability in one of the protocols such as the Address Resolution Protocol (ARP). Linux has tools such as arpwatch that are targeted at catching this kind of ARP spoofing attack.

You may be able to detect a MitM using trace routes, but sophisticated middlemen can combat this, said Anderson. A more common solution is to encrypt the networking link using VPNs and the like. Yet even if the MitM attacker can’t acquire the encrypted key, they can use operational security (OPSEC) techniques to analyze network traffic patterns and speculate about the content, he added.

With data at rest, sensitive data is encrypted in storage using tools such as eCryptfs or PGP. “But encryption and decryption take time, so it’s best to encrypt particular directories or files,” said Anderson. “Protect the data you have to protect and leave the rest alone.”

Data-in-use attacks that look for encrypted keys appearing in memory represent a “much more difficult problem,” said Anderson. “Many people leave keys in memory because they figure they’ll need them again soon. But a sophisticated hacker can use liquid nitrogen to slow down the decay of RAM, then unplug the SIM, plug it into another machine, and read the data. Keep the amount of time you use visible keys short — load it, use a key to decrypt it, and then overwrite it, preferably three times (to remove any residual vestiges of the key).”

Anderson went on to discuss symmetric and asymmetric encryption, such as Diffie-Hellman, in which you encrypt with both a private key and the recipient’s public key. One problem that is “wigging people out” is that in five to 10 years, “quantum computers will be able to crack public key and Diffie-Hellman in real time and break 1024-bit RSA algorithms,” said Anderson.

For higher security requirements, you can implement mandatory access control using SELinux, Smack, or other techniques that use LSM (Linux Security Modules), limiting applications to read-only access. Yet, these approaches take time and money to develop and test.

In addition to the above recommendations, Anderson offered some basic tips for securing embedded Linux devices. These include:

• Implement risk assessment to determine the required level of security.

• Eliminate all non-essential services and software.

• Periodically audit the installed software.

• Have regular, monitored software security updates.

• Implement two-factor authentication.

• Use Linux containers to separate secure and unsecure functions.

• Implement file control policies or code signing, if your platform supports it.

• Know every device on your network and periodically scan for new, unauthorized devices.

• Implement both IPv4 and IPv6 firewalls and use software such as snort for intrusion protection/detection.

• Use VPNs for extended security, and use DTLS, TLS, or AES for temporary link security.

• Scan your network ports periodically with nmap, satan, saint, etc.

• Use penetration testers periodically, but make sure they’re legit organizations and not hackers posing as pentesters.

“Securing IoT and embedded Linux is a daunting task, and it costs money,” concluded Anderson. “There’s a spectrum between usability and security, and there’s always a compromise. At the very least, make sure you did everything you are legally bound to do.”

Watch the complete presentation below: