The warnings by the cybersecurity segment in the consumer segment still tend go relatively unheeded by consumer wireless vendors. Because of that we can expect nefarious activities in that sector to continue to ramp up. But we all know that. So why are they not doing more to thwart it?
So far, hacking consumer devices tends to be a low-yield activity compared to hacking government or enterprises. However, with the implementation of 5G and the expansion of the Internet of Anything/Everything (IoX), that is going to change.
While the non-consumer IoX segment is further down the line with security, the consumer vector seems stalled. So far, and luckily, this segment has not seen a pandemic-scale attack on its IoX devices. But it is just a matter of time until such an event occurs, simply because of the proliferation of smart consumer IoX devices.
One of the major talking points around 5G is security. Most agree that 5G will be the great enabler for the IoX. It makes sense, especially when one considers that many IoX devices will be capable of using mmWave frequencies. As this evolves, the attack surface increases logarithmically.
The consumer supply side is, and always will be (except for the well-off) a very competitive segment. Consumers are price conscious-so what else is new? That puts the pressure on the vendor to be price competitive; meaning (obviously there are exceptions), putting in just enough to make sell and be profitable.
And, Like it or not, security is not a big selling point for the consumer. However, the time has come (again) to rethink that, especially in light of 5G. And there are hints that this should happen sooner than later.
What caught my eye and spurned this discussion is I recently saw a story about a cybersecurity company, GeoEdge, which has uncovered a global-scale malvertising attack. This is noteworthy because it is the first ad-based cybercrime aimed specifically at home-network-based IoX devices. It is believed to have originated in Slovenia and the Ukraine.
It first became visible a couple of months ago. This particular malware silently install code on home-WiFi-connected smart IoX devices.
If we look at some of the predictions for how many IoX devices will be out there in the next few years, a reasonable figure is 30 – 40 billion, globally, by 2025. By any stretch of the imagination that is a huge attack surface. And most low-tier, consumer devices are not equipped to spot this kind of malware.
In case you are not familiar with malvertising, or malicious advertising here is a birds-eye view. This is the kind of code that is embedded in ads – yes, the kind we are inundated with constantly. These are the type of ads that load when the site is opened. No user action is required. One would wonder how an IoX device would open malware. The fact is they do not directly but hang on a moment.
Malvertising injects malicious code into online display ads via online advertising networks. Such networks are generally unaware they are serving up malicious content. And with a more recent version of this malware, users are not even required to click on the infected ad or navigate to a malicious page to initiate the attack on home network devices. That is why this is no nefarious.
This works so well because of the fragmented nature of online ads. Typically, the device, whether it is a computer, tablet, phone, whatever, is receiving and sending data all over the place via a variety of ad-related servers when it loads a website. One server delivers the online ads, another might play a video ad, and a third server might trigger a pop-up. This happens again when you click an ad as well.
The hacker hijacks the IoX device and inserts their code. Then the hacker can intercept or redirect traffic or insert malware into the channel. In simple terms, the IoX device is simply the medium running compromised code to allow infiltration of the users network. Now attackers simply intercept these traffic requests passing between the device and your browser and forcibly inject their malware or divert your traffic somewhere else.
It is the IoX device that will open the gate to this malware. Once it gets to the device, It is able to manipulate it by download apps without users’ consent, and risks theft of personal information and monetary data, as well as tampering with home systems such as smart locks and surveillance cameras.
Most antivirus measures, even firewalls of IoX devices are not able to spot or stop the code. To do so requires security capable of advanced, real-time ad blocking which is not a priority for such consumer devices.
This is only the tip of the ever-expanding malware iceberg. It is unlikely consumer IoX device manufacturers will move on this, at least not now.
In reality, these manufactures have no liability (unless gross negligence and verifiable damage can be proven) so there is no real motivation to up the security game. So again, it falls to the consumer to bear the costs.
The best defense, for now, is a good offence. Use the best available security options and software on your computers and smartphones. But, above all, be vigilant. Better to suspect a legitimate ad to be malware than to assume it is not.
Ernest Worthman is an executive editor with AGL Media Group.
With the IoT now enabling practically any asset to be connected to the internet, the need for wide-area, low-power, low-cost connectivity for IoT applications has grown. With this type of connectivity, utilities, Original Equipment Manufacturers (OEMs), transportation and logistics firms, construction firms and other organizations can deploy smart energy and resource monitoring, smart city infrastructure monitoring, predictive maintenance, mobile asset tracking, and similar IoT applications that allow them to collect, analyze and use asset data to lower costs, offer new services, increase customer engagement, and otherwise transform the way they operate.
At first, proprietary Low Power Wide Area (LPWA) technologies like LoRa and Sigfox emerged to meet some of these organizations need for wide area, low power IoT connectivity. Then, over the past decade, the 3rd Generation Partnership Project (3GPP) introduced standards for two cellular LPWA technologies – Narrowband IoT (NB-IoT) and LTE-Machine Type Communication (LTE-M). Meanwhile, Mobile Network Operators (MNOs) have built out NB-IoT and LTE-M networks, with at least 156 such networks now in operation around the world today.
While shipments of proprietary and cellular LPWA IoT devices are roughly equal today, over the next decade industry experts expect growth of cellular LPWA devices to outpace propriety LPWA devices. BERG Insight forecasts that annual shipments of 3GPP LPWA (NB-IoT and LTE-M) IoT devices will exceed 300 million units by 2025, while annual shipments of non-3GPP LPWA IoT devices will grow more slowly over this period, to less than 250 million units.
Why will Cellular LPWA Grow Faster than Proprietary LPWA?
The reason why shipments of cellular LPWA device shipments are expected to be higher than propriety LPWA over the coming years is that cellular LPWA offers several advantages over proprietary LPWA. These advantages are leading organizations to increasingly choose cellular LPWA for their monitoring, tracking and other IoT applications.
Cellular LPWA, unlike propriety LPWA, offers organizations:
Separating Cellular LPWA Fact from Fiction
Despite these and other advantages associated with cellular LPWA, some business leaders still think cellular LPWA’s power consumption, data throughput, and coverage or signal penetration capabilities are significantly weaker than proprietary LPWA’s.
However, upon further examination, the facts show that many of these cellular LPWA drawback drawbacks are fiction. For example:
Cellular LPWA Power Consumption is Comparable to Proprietary LPWA: While broadband LTE and 5G NR cellular chipsets do consume more battery power than proprietary LPWA chipsets, cellular LPWA chipsets deliver power performance on par with proprietary LPWA chipsets. Designed for IoT applications, these NB-IoT and LTE-M chipsets have been designed to use very little power when they are in sleep or standby mode. And because cellular LPWA data rates are higher than propriety LPWA data rates, they can connect and then disconnect from the network faster than proprietary LPWA chipsets, allowing them to save additional power by spending more time in sleep or standup mode
LoRa’s Coverage and Signal Penetration Are Not Significantly Better Than Cellular LPWA: LoRa, a proprietary LPWA technology, is perceived as having better coverage and signal penetration than NB-IoT and LTE-M. Yet, the difference in maximum coupling loss (the amount of the wireless channel that can be lost before device is no longer able to connect to network infrastructure’s antenna) between Lora (165db) and cellular LPWA (164db) is only one decibel. In addition, public cellular LPWA networks are denser than LoRa networks – which means, for a given area, cellular LPWA is likely to provide better coverage and signal penetration than LoRa.
Data Throughput Rates for Cellular LPWA Are Higher Than Proprietary LPWA: The latest version of NB-IoT, NB2, offers downlink (DL) speeds of 127 Kilobits Per Second (kbps) and uplink (UL) speeds of 158 kbps, while the latest version of LTE-M, M1, provides DL speeds of 588 kbps and UL speeds of 1119 kbps. These rates and real-world field tests of cellular LPWA and proprietary LPWA devices show cellular LPWA data speeds are higher than proprietary LPWA technologies. Thanks to these higher data rates, in the field FOTA updates that are not possible with proprietary LPWA devices can be completed with cellular LPWA devices. Moreover, because cellular LPWA uses licensed spectrum, quality of service and non-interference is guaranteed both today and tomorrow, further improving performance.
Cellular LPWA Delivers the IoT Connectivity Organizations Need in a Connected Economy
As organizations of all types seek to digitally transform their operations, being able to extract, orchestrate and act on data from widely distributed, battery powered, low-cost IoT sensors and other devices is becoming more important than ever.
Cellular LPWA’s ubiquitous global coverage, robust security, support for FOTA upgrades and guaranteed service meet this need, providing organizations with wide area, inexpensive, low-power connectivity for a wide range of IoT applications. In addition, with power consumption, data throughput rates and coverage that is comparable to or better than proprietary LPWA, and a technology standard supported by MNOs and other wireless industry leaders, these organizations can be confident that cellular LPWA will offer them the connectivity their IoT applications need not just today, but tomorrow as well.
Olivier Amiot is marketing director at Sierra Wireless, where he is responsible for business development and market strategy for IoT solutions in the smart energy and industrial markets.
An internet-of-things (IoT) laboratory for testing infrastructure equipment designed for urban environments will help enterprises and municipalities with smart city applications. Radio Frequency Systems (RFS) said that the first such laboratory that it has opened by in Hannover, Germany, will be followed by a second facility in the United States later this year.
“The decision to open the lab facility comes after feedback that many customers are facing confusion when it comes to designing the best infrastructure to support specific applications,” a statement from RFS reads. “The lab will enable them to evaluate the various options and make an informed decision on the best solution for their locations, without incurring significant trial and error costs. Mainly working with enterprises and municipalities, a key focus area will be to help with the design of street level architecture to support smart city applications.”
According to RFS, the lab will test communications radios, IoT devices and management control software, using monitoring, IoT sensors and 4G/5G communications. Customers will be able to control and monitor a variety of IoT devices to determine the best solution for their environment, the company disclosed. Additionally, mobile network operators will be able to test their radio network designs for street-level densification, the statement reads.
“We hope the launch of the IoT Lab in Hanover will be a very exciting step for both our customers and the industry,” said Dietmar Brunsch, team technical lead at RFS. “The commercial success of IoT and 5G hinges on the ability to deliver efficient systems that truly perform when it comes to ROI. This facility will give customers the chance to test solutions in a ‘real-world’ environment, allowing them to make informed decisions in a cost-effective way to ensure that smart cities live up to their potential.”
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.