Connect (X)

Tag Archives: malicious code

Drilling Down on Malicious Code in the IoX

By Ernest Worthman, Executive Editor, AWT magazine, Senior Member, IEEE

Tech Talk


Few will deny that, presently, the Internet of Anything/Everything (IoX) is a moving target when it comes to security. This means that the various security segments are in for a real challenge, in terms of getting a handle on, and staying ahead, of malicious code.

The recent FireEye hack, as well as many more in 2020 (CAM4 – 10.88 billion records, Advanced Info Service (AIS) — 8.3 billion records, Keepnet Labs – 5 billion records, BlueKai – billions of records, and lots more with a paltry few millions of records), should have brought the seriousness of innate security to the forefront. However, I have made this statement before, pretty much after each such major occurrence, and while there is a lot of hand-wringing, still, the segment does not catch fire.

Normally I would drill down on the details. But essentially, they are, basically, all similar. An entry point of some sort is found by hackers and they proceed to upload code. The fact that this continues is rather embarrassing. I am, by no means, saying cybersecurity is easy, it is not. However, in most cases, it is the fault of the hackee (as was the case with FireEye).

Whether it is a high-stakes organization or a lowly minimally-protected IoX device, the process is the same – only the methodology and code change.

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. This discussion focuses on the type of code that has to be created and modified by programmers (again, the case with FireEye – the attackers embedded their malicious payload on a legitimate component of the SolarWinds Orion Platform. It was not a particularly sophisticated attack with complex code manipulation or morphing code).

Such nefarious code works, simply because of the sheer number of code samples available for manipulation. And the fact is 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, i.e. rational thinking and analytical recoding as opposed to mathematically-based algorithmic permutations. With such code it can be extremely difficult to “second guess” what the coder has in mind, making it difficult to use model-based predictive theories.

Much of the malicious code development looks just like standard software code development. It uses standard software tools including programming language, SDK, compiler, etc.

Ofttimes, 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 a 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 or smartphone, 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. With the expected hundreds of billions of IoX devices connected via 5G, the attach surface is huge.

Doo Doo Doo…Lookin’ Out My Back Door

One of the nastier methodologies of injecting malicious code, or tampering with the device, is through the “back door” (I did a deep dive on that in the Q3 issue of Applied Wireless Technology – https://www.aglmediagroup.com/applied-wireless-technology/. This is used to gain access to the computer, or IoX object the code is residing on. This attack vector has deep implications for the IoX because it can be placed in virtually any autonomous object of the IoX and used to compromise any system the object has access to.

Back doors are mature and well understood and are responsible for the majority of breaches. And virtually every piece of hardware that will be on the IoX will have the ability to be backdoor-ed unless the industry gets a handle on it before it gets out of hand. There is a significant concern with objects of the IoX 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 less attention being paid to securing these objects than there should be, even today.

There are two general vectors for back doors. The first is back doors that are 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 is usually created by programmers so they can have unrestricted access to an application for troubleshooting or clandestine emergency access (recall the film “War Games?). They can even 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 IoX

Even recent studies have shown that IoX device 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 IoX has revealed weak security practices that will present tremendous opportunities for hackers probing it, if it is not addressed soon.

Firmware is what manages the interactions between higher-level software and the underlying hardware. It is found on every piece of hardware that has any real functionality. But where it is the most vulnerable is in embedded systems – the majority of IoX and all smart devices.

Poorly coded firmware is the easiest to exploit. Low-end (read, cheap) devices will have a minimal set of instructions and little if any real security. Typically, these are stand-alone peripheral devices such as printers, routers, security cameras, etc., in today’s networks, but will become much more prolific and expansive in the IoX, including all the autonomous devices envisioned on the IoX. This includes the proverbial smart toothbrush and smart vehicles, as well as the Orwellian prevision of sub-dermal microchips that link us to anything and everything in the IoX.

In an attempt to learn just how breachable such embedded devices are, a while back researchers with Eurecom, a technology-focused graduate school in France, developed a web crawler that plucked more than 30,000 firmware images from the websites of manufacturers including 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, over 35 vulnerabilities were uncovered.

The study looked mostly at consumer IoX devices, where the competition is most fierce. In such instance’s companies are often under the gun to release products quickly to stay ahead of rivals. Often the company that is first and with the cheapest reaps the economic rewards. The difficult part is that secure and cheap are dichotomously opposite when it comes to most of the IoX objects since many of the embedded devices will be at the lower end of the object chain.

It Is More Prevalent Than One Thinks

In one of the cases, 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 was confirmed to work on several Linksys and Netgear DSL modems. It exploits an open port accessible over the wireless local network.

On some of the routers, this back door requires that the attacker is actually on the local network to attempt to add a bit of security. 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 are not 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 and access all other networked devices as well as a port out to the internet.

The ramifications of this are volcanic. Obviously, this is the mentality that exists today. And even though I keep my ear to the rail on this, I really have not seen much of an increase in the awareness level of dealing with this. The last few years have presented no shortage of IoX devices being hacked and it still goes on today.

Typically, this is discovered when someone notices some errant activity on a network or a device is compromised (such as a webcam). One recent example was the discovery of a flurry of messages sent from a range of IPs. Once analyzed the discoverers found that not all of the devices were PCs. Many were unidentified devices running a standard version of Linux (IoX devices). Pinging one device brought up a login screen that said: Welcome to Your Fridge. Then, typing in the often default password “password” causes the device to open its access port.

Preventing Code Armageddon

The question begs itself, 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? Interestingly proving the absence of something is always a harder problem than proving the presence of something. In other words, it is extremely difficult and time-consuming to determine that there is no extra malicious code. And there is a slew of other variables that come into play, not the least of which is simply that companies are not willing to spend resources on devices that may have razor-slim margins as is. 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 the functionality of a chip against its specification. Unfortunately, such verification will not reveal the presence of malicious code. If there is malicious code, in many instances it will simply remain dormant under such testing and go unnoticed until it is triggered. A brute force approach of trying exhaustive lists of vectors is not going to succeed either, since such a list is an exponentially large number.

Sadly, the advantage is with the attackers. Most new types of devices with network connectivity being released continue to have weak, or minimal, built-in security. As well, they generally do not offer the capability to tag on security controls of some sort, either. There is a desperate need for both more specific and generic embedded device security controls.


As the age of intelligent everything evolves, it will see more and more 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, toasters, toothbrushes you name it, will be autonomously connected to the IoX.

Such devices are trivial for even just amateur hackers to compromise, placing an electronic condom around the network is one method of securing these objects. However, if the envelope security is breached, the opportunities within are a goldmine for the hacker.

Finally, some 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.

Progress is being made, albeit a lot slower than many would like. Yes, it is getting better, yet the suppliers still seem to still be heading down a path of reactive, as opposed to proactive action. And that will likely continue, even though breaches like FireEye and others continue on nearly a weekly basis.

Is there a solution? As I had said at the beginning, most breaches are due to poor housekeeping – professional and consumer. Once the IoX is loaded with devices and catastrophic damages become commonplace, then, perhaps, the damage will force security to become the number one priority for everything.