Connect (X)

Tag Archives: IoX

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.


Microservices, Edge Networks Will Redefine the IoX

By Ernest Worthman, AWT Exec. Editor, IEEE Sr. Member

Few things are static in technology. One can be guaranteed that what is hyped today may well be discarded or redirected tomorrow. Not necessarily the technology, itself, but how it ebbs and tides.

Aside from 5G, the Internet of Everything/Everyone (IoX) is going to be the biggest redirector of technology. While 5G will change the way we communicate and function in a mobile environment, the IoX will change how we live.

Obviously, there are many components within the IoX. While we have a global view of how we envision the IoX is going to exist, many of these components are still fuzzy.

Take for example, a recent evolution of the services segment called microservices. Microservices are a new way for developers to develop software. Why this is significant is because the IoX is going to have difficulty supporting “bloatware.” This is, particularly, significant at the edge, where the mantra is light and nimble. Microservices, at the edge, could redefine the IoX, as we see it today.

Well, whoa there, podner! Microservices, at the edge, could redefine the Internet of Everything/Everyone (IoX). There are, almost daily, announcements that claim this or that technology will revolutionize this or that platform or technology. Some have legs, others are just incubated concepts that sound good but have little substance to support their claim. Turns out this was propaganda from a Silicon Valley startup.

Not that microservices are not a valid concept. The concept is well developed and implemented in the cloud. The reason it is applicable to edge networks is because there will be a plethora of diverse, smart edge devices in the IoX, most of which will be too resource-limited to run the typical applications we use today. Moreover, they can be called to function in any number of systems. All of this making monolithic apps unworkable. The microservices concept is a way to address the nimbleness of edge networks and IoX devices in general.

The idea behind microservices is to cull out the various functions of monolithic software and use a modular approach to implement them. The monolithic application is decomposed into independent components called microservices. These will function like instruments in a band, able to deliver the application’s overall functionality when necessary. However, in the microservice environment, the applications are independent services small enough to reflect independent concerns from a variety of use cases. Each microservice implements a single function, specific to the use case. That parlays into an edge network that is agile and flexible, using only the services required for the particular job from an available pool of services.

An interesting, although not new, concept. The theory is that app developers can use whatever resources they need from that pool of services without impacting other microservices. Microservices also offer a smaller code footprint and faster boot times for typical, resource-limited, edge devices. If the edge is virtualized, re-use is another benefit.

One of the most promising features is security. Because microservices are so flexible, they can be configured to be called up in real-time, defined by device demand. This means that all code is not always running. Only necessary code. That allows unused functions to be unloaded and lie dormant. This keeps the live code to a minimum and reduces the attack surface. In addition, because microservices vary from device to device, a measure of isolation is also present.

This is one of those concepts that has many possibilities. It also has many angles that have to be considered. Moreover, while microservices are being used in other areas, porting that to edge computing may be more difficult. In a centralized location, microservices can be diverse and have access to heavy resources. At the edge, this may prove to be challenging because edge networks are geographically small and interconnected by a backbone. It is possible some sort of management layer will be needed to manage the deployment of such services, across edges, if there is a diverse IoX environment.

Microservices are typical of the new landscape. Just as software defined networks and network function virtualization are evolving to meet next-generation network needs, so will microservices. However, a lot is on the drawing boards at present. How this will all look, say, five to ten years from now may not necessarily resemble what we currently envision.

Ernest Worthman
Executive Editor/Applied Wireless Technology
His 20-plus years of editorial experience includes being the Editorial Director of Wireless Design and Development and Fiber Optic Technology, the Editor of RF Design, the Technical Editor of Communications Magazine, Cellular Business, Global Communications and a Contributing Technical Editor to Mobile Radio Technology, Satellite Communications, as well as computer-related periodicals such as Windows NT. His technical writing practice client list includes RF Industries, GLOBALFOUNDRIES, Agilent Technologies, Advanced Linear Devices, Ceitec, SA, Lucent Technologies, , Qwest, City and County of Denver, Sandia National Labs, Goldman Sachs, and others. Before becoming exclusive to publishing, he was a computer consultant and regularly taught courses and seminars in applications software, hardware technology, operating systems, and electronics.  His credentials include a BS, Electronic Engineering Technology; A.A.S, Electronic Digital Technology. He has held a Colorado Post-Secondary/Adult teaching credential, member of IBM’s Software Developers Assistance Program and Independent Vendor League, a Microsoft Solutions Provider Partner. He is a senior/life member of the IEEE, the Press Liaison for the IEEE Vehicular Technology Society and a member of the  IEEE Communications Society, IEEE MTT Society, IEEE Vehicular Technology Society and the IEEE 5G Community. He was  also a first-class FCC technician in the early days of radio.

There Is No Definition of IoX Yet; Or Is There?

By Ernest Worthman

Executive Editor
AGL Small Cell Magazine



While there is little definition to the internet of anything (IoX) yet, companies are trying, more and more, to leverage it — perhaps in hopes that what they are offering will catch on. Much of this isn’t anything more than advanced M2M (now being called the “industrial IoT”) but it’s good for visibility. In that vein, a company called Berg Insight expects global IoT platform revenues to grow at a compound annual growth rate (CAGR) of 30.8 percent between 2015 and 2021 to reach $3.3 billion by 2021.

I am unsure of what defines “global IoT” platforms. “The report discusses that “Most IoT platforms currently available are either connectivity management platforms (CMPs), device management platforms (DMPs), or application enablement platforms (AEPs).”

Take AEPs for example. The report states that “The market for AEPs provides functionalities such as data collection, data storage and analytics.” Is that big data? Is that cloud data? Is that sensor data? Does it come from mobile devices, autonomous appliances, autonomous vehicles? They don’t seem to elaborate.

I see a lot of such reports that throw around a plethora of acronyms and definitions under the broad, yet undefined umbrella of the Internet of whatever.

In an earlier missive I alluded to a similar situation with 5G – calling incremental improvements in technology “near 5G” (http://www.aglmediagroup.com/almost-5g-is-happening-now/) because they seem to fall within the haze of what 5G might be. It seems that a similar situation is occurring with the IoX.

A lot of what is in this report is already existing. For example, the report says, “With IoT, organizations can also mash up data from multiple sources.” Hmmm…I saw the same thing in a recent Big Data report.

Until we have a solid IoX platform, I think it is bad practice to start labeling everything and anything as IoX-able. But then, since there are no real repercussions at this stage of the game, why not throw it up against the wall and see what sticks once the IoX gets real traction?

So, What IS a Solid IoX Platform?

There are a few things that have a strong IoX leaning already. Two of those are connected cars and smart cities. Smart cities are being heavily pushed as IoX elements, but so far, very few platforms within any city have been “smarted.” Just having an infrastructure or two (water, street lighting, traffic lights, etc. being uber-sensored and collecting massive amounts of data, then feeding it to a Titan-class supercomputer to optimize the operation of these few entities isn’t really a smart city. It takes an all-element integrated platform that can interconnect and dynamically cross-control, in real time, all of the elements – not just two or three. That is what a smart city is all about.

The same can be said for autonomous vehicles. Both smart cities and autonomous vehicles conjure up visions of the Jetsons. As new ecosystems, they are more on the bleeding edge and therefore are easier seen as IoX protégés, as opposed to water or electricity which are well established.

But there is a bit more meat in the autonomous vehicle arena. For example, one wireless industry analyst noted that for the first time ever, wireless carrier net customer additions stemming from IoT services like connected cars exceeded the number of net additions they received from both smartphones and tablets combined. That is a measurable metric. And, AT&T notes that its connected car onboarding pace is twice that of its connected tablets pace. They are expected to reach 10 million connected car subscriptions in roughly half the time it took for tablets (12 quarters vs. the 25 quarters it took for the tablets).

Verizon is paying attention to this as well. It recently acquired Telogis, a player in the telematics space so it can offer Software-as-a-Service (SaaS) technology and services in the connected vehicle and mobile enterprise management sectors. Verizon is also saying it will acquire Ireland’s Fleetmatics, a company that provides a software platform for handling GPS vehicle management and similar services to companies with mobile workforces.

So, while the IoX isn’t popping out all over, yet, some platforms are more in line with the broadly defined IoX vision. But still, much of this is simply marketing hype: from a small evolution in M2M to others reaching for the definition of the IoX.

(Don’t Hold Your Breath for) the Second Coming of the Industrial Internet

By Ernest Worthman



April 28, 2016 — The IoX (Internet of Anything), is, depending upon who one talks to, really the Internet of many things. The M2M camp is still clinging to the hope that the industrial Internet of Things (IIoT) keeps some sort of anonymity and doesn’t get gobbled up by the Internet of Everything. Some even like to call it the second coming of the industrial revolution.

M2M pundits want to separate the ubiquitous connectivity of devices and pull out thing like smart metering, and LPWAN (low-power, wide area network) wireless technologies, and place them under the IIoT umbrella. And, there are many other similar wireless platforms — RFID, Near Field Communication (NFC), Low-power Bluetooth, ZigBee — that can play in both the IoX and IIoT sandboxes. It just depends upon where the application is deployed. LPWAN technologies deployed in warehouses are no different than if they are deployed in smart homes or smart cities. If one wants to add some redundancy and a few layers of extra control and the like, and call it the IIoT, well, that may have some traction for specific applications going forward, but wide-scale acceptance is unlikely.

There is an argument that the IIoT will have tighter specs, more reliable devices and more functionality. That is not like to happen in the long run. The long-held belief that industrial devices are better than consumer devices may still have legs in some ecosystems, but the IoX isn’t one of them. Even the government, which often pays ridiculous costs for standard items (like the $640 for a toilet seat) has been under pressure for years to adopt Commercial Off-The-Shelf (COTS) devices when it comes to standard devices like sensors, cameras and the like. Yes, they are the top of the line models, but still are available to anyone for an IoE deployment.

IIoT players like to say that Cisco, Ericsson, Huawei, IBM, Intel, Nokia and other major vendors are developing products specifically for the IIoT. Yet most of their products go right into consumer and commercial deployments, interchangeably.

So, the bottom line is that as the Internet of Many Things evolves, niche markets will always develop. But they will all be part of the IoE. And the lines between industrial, consumer, commercial will blur. I doubt there will be the second coming of the industrial Internet. For a more detailed discussion on M2M vs. IoE, follow this link: http://semiengineering.com/m2m-vs-ioe/