The case for security in Linux-based IoT devices
June 01, 2015
Are you among the OEM and system integrators adding Internet connectivity and services into devices that were not originally intended to do so? If you...
Are you among the OEM and system integrators adding Internet connectivity and services into devices that were not originally intended to do so? If you are, then you know that by connecting these products to the Internet, customers are discovering new forms of revenue and, in some cases, entirely new business models. What's more, they are able to make their current products both more valuable and cost-effective.
As we continue to see more Internet-connected devices, we must acknowledge that they will be vulnerable to attack, remotely disabled, or compromised in some other undesirable way – each scenario seriously threatening the entire underpinning of these new business models.
Consider the following example in the world of home automation. It is one of the biggest consumer applications for the Internet of Things (IoT), and potentially one of the most lucrative for attackers. What could a criminal do with information stored in what might be considered a rather harmless home-automation device like an IP-connected smart thermostat? Well, these devices are built to learn your habits. They are designed to recognize or "learn" when you are home and when you are away, so that they can optimize the energy used to heat and cool your house. You can guess where I'm going with this. They'll know your habits and track your routines – sensational fodder for someone thinking about stopping by uninvited.
Remember the case of the Samsung Smart TV? In order to be able to respond to voice commands, it constantly "listened" to your chatter, interpreted it, and then might even send it to "authorized" third parties. Yes, I am serious. The Smart TV was demonstrated to be hackable (what isn't without lock down security) back in 2013. This is a perfect example demonstrating the need for multiple accessibility levels. In the Smart TV case, there was only one user account possible, and that user (i.e., an attacker) could access anything on the device[1][2].
Security through obscurity
In many past instances, product developers would rely on the fact that their devices were too few and too uninteresting to hackers to attempt to exploit them. In other words, these devices were obscure – ostensibly unknown nodes on a network. Unfortunately, this strategy will no longer work. With what is expected to be billions of devices connected to the Internet in next five years (with tremendous variety of functionality), these once "no interest" devices will become quite tempting as targets for exploit.
To address how security by obscurity will no longer work, let me offer an example of how a website is being used to search for Internet connected devices: www.shodan.io
|
|
This particular website is dedicated to exposing the existence, and, if possible, the type of device connected to the Internet. Such devices might be a web camera, a thermostat, or any other piece of Internet-connected home automation equipment. With this website, a subscriber can scan and search for a bevy of connected devices.
Now, if you were relying on obscurity to protect you in this case, you might not be concerned with changing the default root password. This password is set by the supplier to always be the same name, because it is very simple to write documentation if the default password is always the same. Bad idea for the consumer...
Unchanged default root passwords are an open invite to hackers to login and commandeer the camera. They effectually gain complete control to view and record video via remote control, while the owner is completely unaware.
You may have read a story concerning an infant and a web camera used by the parents as a baby monitor. The father walked into his child's room and heard a man speaking over the camera's audio speaker urging the child to, "wake up." When the father walked into the room, the camera panned, and the person on the other end started shouting vulgarities at him until he unplugged the camera[3][4].
This is just one of many examples why Internet security is going to be tremendously important in the years to come. And it needs to be top of mind for connected equipment manufacturers.
Most of these devices are running Linux, the world's most popular operating system for running embedded devices. In this article we will explore a couple of technologies that you need to consider when securing your Linux-connected device.
Before we go into specifics, it is important that you gain a keen understanding of the security risks, identify the potential costs associated with such a business attack, and ultimately, learn how to design your software and appropriately establish an intelligent security strategy. It should be said that additional security does come at a price, often in terms of performance penalties, restricted functionality, and additional development costs.
To illustrate such considerations, I'd like you to think about the experience of running enhanced security software on your laptop or workstation. I'm talking about antivirus software, drive or filesystem encryption, and access control software. Most of us appreciate the additional security provided by these programs. However, and I might be off base, I'm guessing that most readers actually disable some or all of this at times, particularly if you are developers and are trying to run some CPU-intensive tasks, install software tools or utilities that might not be "approved" by IT, or even run programs that perform a lot of filesystem accesses such as building a Linux distribution from source.
Securing connected Linux devices
Here I'll share a few simple ways that you can make your embedded Linux product more secure against certain types of threats, all without installing much additional software or proprietary (commercial) software.
Disable and remove (or don't install) unnecessary services
One of the nice aspects of Linux is how easy it is to take advantage of network services to debug and deploy applications during development. These services (TFTP, SFTP, SSH, NTP, gdbserver, and so on) are also some of the most target-rich points of entry for attackers. You should only implement specific required services in your Linux platform during production and use a port scanner such as nmap to check for open ports (e.g., listening services).
Use a firewall
The basic reason for a firewall is to provide a barrier between internal and external networks. This is a critical function of a gateway or a router, since the internal network is assumed to be open and trusted. There are many available firewall solutions for Linux. Among them are iptables/netfilter, Shorewall, and UFW (uncomplicated firewall). There are varying levels of functionality, ease-of-use, and configurability[5][6][7].
Grsecurity
Grsecurity is a set of patches to the Linux kernel source code that provide enhanced security. It provides a Role-Based Access Control (RBAC) system to the kernel so that the processes (and users) only have access to the least number of files and nothing more. Further, it provides a bundled patch with a different name called PaX. PaX provides other security features that can eliminate certain other types of attacks such as buffer overflows by creating execution space protections. It also can address space layout randomization for a process to defeat exploits that rely on knowing a task's default virtual memory organization (buffer overflows and other attacks)[8].
RBAC
The goal of RBAC is to minimize the privilege of a user or a process has into the rest of the system. For example, many Internet-connected Linux-based systems may implement a number of Internet services, including a web server, as well as a secure shell (SSH) server. These provide various levels of access into the device, allowing a user to make simple configuration changes using a nice user interface (via the web server) or more granular changes using SSH. RBAC can limit the sandbox that a user as access to read, write, and execute based on that user's specific role. This is similar to limiting access to files based on Linux/Unix groups, where roles in RBAC are analogous to groups.
How does RBAC actually help to protect your device? For starters, you can set up a policy to limit access to specific files and system services to ALL users, including even the root user. If a different exploit is used to attain root, the attacker may not be granted the full access to the system that one normally expects when they become the root user.
PaX features
PaX (a part of grsecurity) helps to defeat buffer overflow attacks. A buffer overflow is when an attacker injects data into a process' stack, allowing them to then change the program flow and execute malicious code.
Many modern processor architectures implement a bit (NX) that flags sections of memory as executable or not. PaX works to turn off execution permission to all data sections and can disable write permission to all executable sections of memory. This way, even if the attacker were able to implement a buffer overflow, they would be prevented from loading code into designated executable memory.
In addition, PaX randomizes the address space of processes when they load. Most processes will load into a specific area of virtual memory, load libraries, and place the stack in a known memory location (map). This makes it easy for attackers to run buffer overflows because the stack is in the same place. By randomizing the stack location, in addition to the other sections of memory, it really makes it difficult to run buffer overflows either because (A) the attacker has to guess where the stack is or (B) the attacker will likely overwrite a section of executable code and crash the process upon itself.
Grsecurity implementation and configuration
Most of the features of grsecurity require no additional configuration, something that cannot be said for other Linux security enhancements (e.g., SELinux).
You implement grsecurity by downloading a patch for your kernel version, and then using the patch utility to apply the patch changes to the kernel source tree. Before compiling the kernel, you will need to configure the build options for grsecurity. There are quite a few options, but one that you might want to start with is setting GRKERNSEC_CONFIG_AUTO to Y. This will provide the simplest way to configure grsecurity for your kernel and may be a good baseline for development.
|
|
Wrapping it up (safely, while connected)
For IoT products, it will be an absolute necessity to build security into the product at the inception of the design. If you don't do this, you will be leaving a critical portion of your business open to attack. It is really that simple. The level of security you build in needs to match the risk associated with a given compromised device. Though, keep in mind that there are some fairly simple things that you can do to greatly increase the level of protection.
References
[1] http://www.cnet.com/news/samsungs-warning-our-smart-tvs-record-your-living-room-chatter/
[2] http://mashable.com/2013/08/02/samsung-smart-tv-hack/
[3] http://krebsonsecurity.com/2014/01/bug-exposes-ip-cameras-baby-monitors/
[5] http://www.netfilter.org/projects/iptables/
