Malicious Code In The IoT

Fundamentally, malicious code families are initially comprised of one or more distinct malicious code samples. For clarity, malicious code is, globally used as an umbrella term for all types of malevolent program code. However, for this article, the term is being applied to static code and not morphing codes, which were discussed in a previous article. This discussion focuses on the type of malicious code that has to be created and modified by programmers.

Such code works simply because of the sheer numbers of code samples available for manipulation, and the fact that there are a lot of pernicious individuals working on them. Having expert coders, with intimate knowledge of how code works, is extremely treacherous because of the human factor’s cognizant awareness, namely rational thinking and analytical recoding as opposed to mathematically-based algorithmic permutations. Unlike morphing code, with malicious code it can be extremely difficult to “second guess” what the coder has in mind, making it difficult to use model-based predictive theories.

According to Roel Schouwenberg, one of Kaspersky Labs’ principal security researchers, “morphing code can be developed in a few different ways, which often depends on the complexity. A less sophisticated attacker may simply add random, dead code to the end of the file. More refined ways of going about it is changing the look of the file as it is being copied on the system. This could be done by, for instance, changing re-encrypting blocks of code with different encryption keys. Server-side polymorphism is often achieved by recompiling the code with different compiler settings, different packers or packer settings, or automatically moving blocks of code around before compilation.”

In fact, much malicious code development looks very much like standard software development. “It uses standard software tools including programming language, SDK, and compilers,” says Ambuj Kumar, system architect for Rambus’ Cryptography Research Division. “Often, simpler code may be written directly in machine op-code (CPU instructions, firmware directives, or hardware commands). However, more sophisticated code may be written in high-level language like C and then compiled into machine-level code.”

What, where, how
Malicious code can be found just about anywhere, and in any type of program. It can be contained in Java applets, ActiveX controls, scripting languages, browser plug-ins, even in pushed content. It can cause anything from a simple nuisance, such as a smiley face randomly popping up on your monitor, to wiping your drives, to leaking all of your confidential data and anything in between. Its ubiquity is what makes it so virulent and difficult to contain. It is just unlimited in where it is found, what it can do and ways in which it can do it.

One of the nastier methodologies of injecting malicious code, or tampering with the device, is through the “back door.” This is used to gain access to the computer, or Internet of Things/Everything/Cloud of Things (IoT/E, CoT) object the code is residing on. This attack vector has deep implications for the IoT/E, CoT because it can be placed in virtually any autonomous object of the IoT/E, CoT and used to compromise any system the object has access to.

Back doors are fairly well understood on PC platforms (the operative word here is fairly). Such is not the case with the IoT/E, CoT. There is significant concern with objects of the IoT/E, CoT because some of the variables of these objects (cost, available code memory, standards, interoperability, operating platforms, etc.) have yet to be firmly defined. As such, there is little attention being paid to securing these objects as of today.

There are two general vectors for back doors. The first involves a back door that is created, with malicious intent, to compromise the known vulnerabilities of systems it attacks. The second, and perhaps the more dangerous of the two, ironically, is the “innocent or accidental” back door. This back door usually is created by programmers to provide unrestricted access to an application for troubleshooting or clandestine emergency access (recall the film “War Games?”) They even can be created inadvertently through programming errors. These are the ones that can do a lot of damage before being reeled in, because there can be more variables and greater confusion than deliberately programmed malicious back doors.

Back Doors And The Iot/E, CoT
Studies have shown that the IoT/E, CoT firmware is plagued by poor encryption and wide open back doors. The most recent large-scale analysis of a fundamental type of firmware that will be prolific in the IoT/E, CoT (Cloud of Things), has revealed weak security practices that will present tremendous opportunities for hackers probing it.

Firmware is what manages the interactions between higher-level software and the underlying hardware. It is found on all kinds of computer hardware, but where it is the most vulnerable is in embedded systems.

Poorly coded firmware is the easiest to exploit. Low-end (read cheap) devices will have a minimal set of instructions and virtually no security. Typically these are stand-alone peripheral devices such as printers, routers, security cameras, etc., in today’s networks, but will include all the autonomous devices envisioned on the emerging IoT/E, CoT. This includes the proverbial smart toothbrush and smart vehicles, as well as the Orwellian vision of sub-dermal microchips that link us to everything and anything in the IoT/E, CoT.

In an attempt to learn just how breach-able such embedded devices are, researchers with Eurecom, a technology-focused graduate school in France, developed a Web crawler that plucked more than 30,000 firmware images from the Web sites of manufacturers such as Siemens, Xerox, Bosch, Philips, D-Link, Samsung, LG and Belkin.

The number of potential security flaws found in these firmware images was astounding. In addition to poorly protected encryption mechanisms, virtually all devices had some sort of back door that could be exploited to allow access to devices. In virtually all of the devices this firmware is designed to run, more than 35 vulnerabilities were uncovered.

The study looked mostly at consumer devices, where the competition is fierce. “Companies are often under the gun to release products quickly to stay ahead of rivals,” noted Aurélien Francillon, a coauthor of the study and an Assistant Professor in the Networking and Security Department at Eurecom. “You have to be first and cheap,” Francillon said. The difficult part is that secure and cheap are dichotomously opposite when it comes to most of the IoT/E, CoT objects, since most of the embedded devices will be at the lower end of the object chain.

More prevalent than you would think
In one recent case a back door was discovered on certain combination router/DSL modems. It allowed an attacker to reset the router’s configuration and gain access to the administrative control panel. The attack, confirmed to work on several Linksys and Netgear DSL modems, exploits an open port accessible over the wireless local network.

On some of the routers, this back door requires that the attacker be on the local network. However, it turns out that some of these routers also have the back door open to the Internet side. That means that some of the devices are vulnerable to remote attack, as well. On the devices that aren’t open to the Internet, it is a simple process for any astute hacker to patch into a local network. Once in, the hacker can commandeer devices that are open to the Internet an access all other networked devices, as well as out to the Internet—with ramifications that might best be described as volcanic.

The future
Recently a company called Proofpoint discovered what just might be a hint of things to come. According to the company, the first large-scale Internet of Things hack has been discovered. Proofpoint found that the compromised gadgets—which included everything from routers and smart televisions to at least one smart refrigerator—sent more than 750,000 malicious emails to targets between Dec. 26, 2013, and Jan. 6, 2014. And it was done though a back door.

It was discovered as a security researcher at Proofpoint noticed a spike in thousands of malicious messages sent from a range of IPs. Pinging one device brought up a login screen that said: Welcome to Your Fridge. Typing in the often default password “password” opened access to the device.

So what can be done to thwart such code? Are there hardware tricks and traps that can be implemented to identify and nullify such code on devices?

“Proving the absence of something is always a harder problem than proving presence of something,” said Kumar. “In other words, it’s extremely difficult to prove that there is no extra malicious code.” And there are a slew of other variables that come into play, not the least of which is simply that companies aren’t willing to spend resources on object that may have razor-slim margins as is. So to expect them, at least today, to look for ways to prevent what may or may not exist is a daunting objective.

Where there is support for security, traditional verification has focused on verifying functionality of a chip against its specification. Such type of verification cannot reveal presence of a malicious functionality. In many instances, such functionality will simply remain dormant under such testing and go unnoticed. A brute force approach of trying exhaustive lists of vectors is not going to succeed either, because such a list is an exponentially large number.

“Currently, the advantage is with the attackers,” Schouwenberg adds. “Most new types of devices with network connectivity being released, also known as the Internet of Things, don’t come with any built-in security. They generally also don’t offer the capability to tag on security controls of some sort. At the same time there’s an increased focus on embedded security research. We desperately need more, and more generic, embedded device security controls.”

Conclusion
As the age of intelligent everything dawns, it will witness a slew of devices that fall under that umbrella of competitive consumer products. Many, if not most, will be low-margin. Soon, millions of objects, such as TVs, Internet appliances, refrigerators, ovens, even toasters and toothbrushes will be autonomously connected to the IoT/E, CoT.

Such devices are trivial for even just amateur hackers to compromise, opening new opportunities for malicious actions of various kinds. Proofpoint warns that what was discussed in this article may be among the mildest occurrences, and just the tip of the iceberg.

Most of today’s embedded operating systems deployed in firmware tend to be old, not patched very frequently, and there are known vulnerabilities to virtually all of them. Yet the suppliers seem to be heading down a path of reactive, as opposed to proactive action—at least until something happens that will cost them a boatload of money.