Thought leadership. threat analysis, news and alerts.
Bugs in Treck TCP/IP Stack Put Hundreds of Millions of IoT and Embedded Devices At Risk
Nineteen vulnerabilities in a piece of software called “Treck TCP/IP Stack” have recently been discovered. This piece of software is present in hundreds of millions of IoT and embedded devices, putting these devices and connected devices at risk.
The 19 vulnerabilities in Treck TCP/IP stack is collective called “Ripple20”, giving emphasis on the word “ripple”, as the ripple effect of these vulnerabilities has grown exponentially due to the supply chain factor. Out of the 19 vulnerabilities discovered, 2 were disclosed anonymously and 17 were disclosed by Israel-based cybersecurity firm JSOF.
“A single vulnerable component, though it may be relatively small in and of itself, can ripple outward to impact a wide range of industries, applications, companies, and people,” JSOF said in the report "19 Zero-Day Vulnerabilities Amplified by the Supply Chain". “Ripple20 reached critical IoT devices from a wide range of fields, involving a diverse group of vendors.”
Tracing the Supply Chain
TCP/IP stack was developed 20 years ago by the firm called “Treck”. This piece of software serves as a basic networking element or a building block, useful in any context for any IoT or embedded device that works over a network.
According to JSOF, over the past two decades, Treck TCP/IP has been spreading around the world, through both direct and indirect use. JSOF reported that in the 1990s, Treck collaborated with a Japanese company named Elmic Systems. The two later went their separate ways, resulting in two separate branches of the TCP/IP stack devices, one managed by Treck and the other one managed by Elmic Systems. Other than ELMIC, the Treck TCP/IP stack is also known by other names such as Net+ OS, Quadnet, GHNET v2, and Kwiknet.
Printers, routers, infusion pumps in the medical sector, and industrial controls are some of the devices affected by these vulnerabilities. Affected device vendors as a result of the 19 vulnerabilities discovered in Treck TCP/IP include HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, and Baxter. JSOF estimates that the discovered 19 vulnerabilities affect hundreds of millions or more devices.
Security Vulnerabilities in Treck TCP/IP
Out of the 19 security vulnerabilities discovered on Treck TCP/IP, 4 are rated critical remote code execution vulnerabilities with CVSS ≥ 9; 4 are major with a CVSS ≥ 7; and 11 more have various lower severity. CVSS, short for Common Vulnerability Scoring System, is the industry standard for assessing the severity of computer system security vulnerabilities, most critical of which is rated 10.
Security vulnerabilities designated as CVE-2020-11896, CVE-2020-11898, and CVE-2020-11901 are some of the notable out of the 19 vulnerabilities.
CVE-2020-11896 is a critical vulnerability in Treck TCP/IP stack. This vulnerability allows for remote code execution by any attacker that can send UDP packets to an open port on the target device. Remote code execution allows attackers from any geographical location to run programs on the target device.
CVE-2020-11898 is a security vulnerability in Treck TCP/IP stack that improperly handles an IPv4/ICMPv4 Length Parameter Inconsistency, which allows remote attackers to trigger an information leak. JSOF researchers tested the CVE-2020-11896 and CVE-2020-11898 vulnerabilities on Digi Connect ME 9210 – a device that’s embeddable and is used in medical devices. Digi Connect can be purchased from any of the large electronic-parts resellers, amplifying these vulnerabilities as any device embedded also becomes vulnerable.
Among the 19 security vulnerabilities in Treck TCP/IP stack, the most severe is CVE-2020-11901, receiving a CVSS score of 9.1. This vulnerability is a collection of vulnerabilities for several critical client-side vulnerabilities in the DNS resolver of the Treck TCP/IP stack.
If successfully exploited, this vulnerability allows pre-authentication arbitrary remote code execution. This vulnerability is of particular interest because a sophisticated attacker, such as a nation state “can potentially reply to a DNS request from outside of the corporate network, thus breaking network segmentation,” researchers at JSOF said.
JSOF researchers tested the CVE-2020-11901 vulnerability on a Schneider Electric UPS device model APC Smart-UPS 750 (SMT750I/ID18/230V). UPS, short for Uninterruptible Power Supply, is a device designed for use in enterprise networks, data centers, and mission-critical systems. It’s used as an embedded battery to ensure that devices connected to it won’t suffer from power outages or fluctuations. Remotely exploiting UPS device can, therefore, have disastrous consequences.
Preventive and Mitigating Measures
Here some cybersecurity measures in preventing or mitigating the effects of the 19 vulnerabilities discovered in Treck TCP/IP stack:
Keep all Firmware and Software Up to Date
Some vendors of the products affected by the 19 vulnerabilities discovered in Treck TCP/IP stack, such as Aruba Networks, Digi International, HP, Intel, Teradici, Xerox have issued a corresponding patch or security update fixing the said vulnerabilities.
Retire Devices that No Longer Receive Security Updates
“The Treck stack has been around for more than 20 years,” JSOF researchers said. “Possibly the vulnerabilities too.”
Due to the length of time, some of the IoT and embedded devices affected by the vulnerabilities discovered in Treck TCP/IP stack may no longer receive security updates. Continuous use of vulnerable devices puts your organization’s network at risk of cyberattacks.
Devices which no longer receive security updates, and which have served their purpose for years should no longer be used. Luckily, some of these devices are inexpensive, as such, it’s much cheaper to replace them with the latest versions as opposed to using outdated devices which only put your organization’s network at risk.
Decade-Old Vulnerability Found in Avaya VoIP Phones
Researchers at McAfee Advanced Threat Research have discovered a decade-old security vulnerability lurking in the Voice over Internet Protocol (VoIP) phones of Avaya, the world’s second largest VOIP phone provider.
The decade-old vulnerability present in Avaya VOIP phones, specifically 9600 Series, J100 Series and B189 Series using the H.323 firmware, according to researchers at McAfee Advanced Threat Researchallows remote code execution (RCE) – enabling an attacker to access someone else's device and make changes to it, regardless of where this device is geographically located.
The RCE vulnerability in a piece of open-source software that Avaya used, the researchers said, was likely copied and modified 10 years ago and the company failed to apply subsequent security patches. The researchers added that a malicious actor exploiting the said vulnerability could take over the normal operation of the phone, copy audio from speakerphone and “bug” the phone.
The piece of open-source software that Avaya copied bore the 2004-2007 copyright, which according to the researchers is a “big red flag” as this piece of software has an exploit that has been publicly available since 2009. The 2009 exploit demonstrated that devices using DHCP client version 4.1 and below allows remote DHCP servers to execute arbitrary code. A DHCP client, also known as dhclient, is a device that needs an IP address; while DHCP server hands out an IP address to the dhclient.
Researchers at McAfee Advanced Threat Research found that Avaya VOIP phone’s version of dhclient is vulnerable to the exploit reported in 2009. The researchers said that malicious actors could build a “weaponized version” of the exploit and threaten private networks.
The researchers reported their discovery to Avaya. In June this year, Avayaissued a patch for the affected VOIP phones.
VOIP Phones as Path to Intrusion
Early this month, researchers at Microsoft Threat Intelligence Center reported that VoIP phone is one of the devices being used by a known cyber adversary to gain initial access to corporate networks. Aside from VoIP phone, the researchers said, popular office IoT devices printer and video decoder, are also being used by this known cyber adversary in gaining an initial foothold into corporate networks.
Researchers at Microsoft Threat Intelligence Center, however, didn’t specify the brands of VOIP phone, office printer and video decoder. These office devices, according to the researchers, were compromised either as these devices were deployed without changing the default manufacturer’s login details or the latest security update hadn’t been applied.
According to Microsoft Threat Intelligence Center researchers, the known cyber adversary used these 3 popular office IoT devices as points of ingress in gaining initial foothold to a corporate network. Once inside a corporate network via these compromised IoT devices, the attacker was seen conducting a simple network scan to look for other vulnerable devices.
As the attacker moved from one vulnerable device to another, a simple shell script was dropped to establish persistence on the network. This simple shell script allowed the attacker to search for higher-privileged accounts that would grant access to higher-value data, the researchers at Microsoft Threat Intelligence Center found.
Aside from using popular office IoT devices as points of ingress in accessing high-value data, these compromised devices are also used to build a botnet – referring to a group of devices infected with a malicious software (malware) and controlled by an attacker or attackers for malicious activities, including distributed denial-of-service (DDoS) attacks. In a DDoS attack, a botnet or group of infected devices is controlled to direct their traffic to a target, overwhelming this target with too much traffic that the target can’t handle, ultimately bringing the target offline and rendering the target inaccessible to its legitimate customers.
VPNFilter is an example of a botnet. At its peak, VPNFilter infected at least 500,000 networking devices in at least 54 countries. The following are devices affected by VPNFilter: Linksys, MikroTik, NETGEAR and TP-Link networking equipment in the small and home office (SOHO) space, as well at QNAP network-attached storage (NAS) devices.
According to researchers at Cisco, VPNFilter has a self-destruct capability that can be triggered en masse via the botnet structure and has the potential of cutting off internet access for hundreds of thousands of users worldwide. The researchers are unsure why so many devices were infected with VPNFilter. Most of the infected devices, however, have known public exploits or default manufacturer’s login details hadn’t been changed.
In May 2018, the potential negative effect of VPNFilter was mitigated when the U.S. Federal Bureau of Investigation (FBI)seized a domain used as command and control (C2) by the threat group in their botnet campaign. In a botnet operation, C2 (could be a website or a public cloud account) is used to communicate or control the infected devices.
The devastating effect of a botnet was shown to the world when the Mirai botnet attacked in 2016 Dyn, a major dynamic DNS provider, resulting in the widespread internet outages across the U.S. and Europe. The earlier versions of the Mirai, including the one that attacked Dyn, infected hundreds of thousands of wireless cameras and routers and turned them as botnets. Since the publication of the source code of the Mirai in 2016, a number of Mirai versions has been observed in the wild.
Researchers at Palo Alto Networks discovered a different version of the Mirai which targeted WePresent WiPG-1000 Wireless Presentation systems and LG Supersign TVs – IoT devices that are often used by businesses. Many of the Mirai variants infect IoT devices by exploiting the practice of users of not changing the default manufacturer’s login details.
Today’s IoT devices outnumber the combined number of personal computers and mobile phones. Hundreds of thousands, if not, millions of these IoT devices are, however, left without basic management.
Changing the default manufacturer’s login details and applying the latest security update are two cyber security best practices in preventing malicious actors from accessing your organization’s network. These practices also stop your organization’s IoT devices from being used as part a botnet for malicious activities such as DDoS attacks.
Mirai Botnet Operator Responsible for Cutting Off Internet Access of an Entire Country Jailed
A UK court recently sentenced to 2 years and 8 months 30-year-old Daniel Kaye for operating the Mirai botnet, which resulted in cutting off the internet access of the entire country of Liberia.
Kaye pleaded guilty in carrying out intermittent Distributed Denial of Service (DDoS) attacks on the Liberian telecommunications provider Lonestar MTN. According to Kaye, he was hired by a rival Liberian network provider and paid a monthly retainer to conduct intermittent DDoS attacks on Lonestar.
According to theUK National Crime Agency (NCA), from September 2016, Kaye started operating his own Mirai botnet, composed of a network of infected Dahua security cameras, to carry out intermittent DDoS attacks on Lonestar. In November 2016, the NCA said that the traffic from Kaye’s Mirai botnet was so high in volume that it disabled internet access all over Liberia.
The intermittent DDoS attacks on Lonestar, the NCA added, resulted in revenue loss of tens of millions in US dollars as customers left the network, and cost the company approximately 600,000 USD for remedial cost to prevent the attacks from happening again.
What Is a Mirai Botnet?
Mirai is a malicious software (malware) that infects Internet of Things (IoT) devices, such as video cameras, and turns these infected IoT devices into a botnet – referring to a group of infected computers that’s operated under the control of a cybercriminal to conduct malicious activities such as DDoS attacks.
Mirai first came to public attention on September 20, 2016, when it attacked Brian Krebs’ security blog. The DDoS attack on Krebs’ security blog was considered one of the largest on record at the time. By the end of September 2016, just days after the DDoS attack on Krebs’ security blog, the author of Mirai, using the name “Anna Senpai”, released the source code of Mirai on an online hacking forum. Anna Senpai claimed that 380,000 IoT devices had been infected by the Mirai malware and formed part of the botnet that took down Krebs’ website.
The Mirai source code reveals that this malware continuously scans the internet for IoT devices that use any of the 61-factory default username and password combinations. While 62 username and password combinations are listed on the Mirai source code, there’s one duplication, leaving only 61 unique username and password combinations.
Given that many owners of IoT devices didn’t bother to change factory default usernames and passwords combinations, the Mirai malware easily infected hundreds of thousands of IoT devices and turned them as a botnet for DDoS attacks.
The publication of the Mirai source code on an online forum encouraged other cybercriminals to copy the code and operate their respective Mirai botnets. Following the publication of the Mirai source code, a series of high-profile DDoS attacks were attributed to Mirai botnets.
On October 21, 2016, Mirai brought down a big chunk of the internet on the U.S. east coast. Dyn, an internet infrastructure company, was a subject a DDoS attack that subsequently rendered popular websites inaccessible to the public. Dyn, in a statement, said that a significant volume of DDoS attack traffic originated from Mirai botnets. To date, the perpetrator of the Dyn DDoS attack remains unknown and no case has been filed against anyone in relation to this attack.
In addition to Lonestar DDoS attacks, Kaye also admitted to launching DDoS attacks using his own Mirai botnet on Deutsche Telekom that affected 1 million customers in November 2016. Kaye was extradited to Germany for this crime but only received a suspended sentence.
Three college-age friends in late 2017, Paras Jha, Josiah White and Dalton Norman, pleaded guilty before a U.S. court in creating the Mirai malware. Jha, in particular, pleaded guilty in launching multiple DDoS attacks using Mirai on Rutgers University computer system, resulting in the shutting of the University’s server used for all communications among faculty, staff and students.
Jha, White and Norman dodged jail. Jha, in particular, was ordered by a New Jersey court to pay $8.6 million in restitution and serve 6 months of home incarceration for launching DDoS attacks on the Rutgers University computer network.
The U.S. Department of Justice, in a statement, said that Jha, White and Norman’s involvement with the Mirai ended when Jha posted the Mirai source code on an online forum. “Since then, other criminal actors have used Mirai variants in a variety of other attacks,” the U.S. Department of Justice said.
The publication of a source code of a malware has two sides. First, it encourages script kiddies – those who attempt to launch cyberattacks using scripts or codes written by others, such as in the case of Mirai. Many script kiddies, using the original Mirai source code, have been able to build their own DDoS botnets and offer the service called “DDoS-for-hire”.
Second, the flipside of making a malware source code public is that this enables the cybersecurity community to study the code and develop tools and advisories that could render this malware inoperable or useless.
There are currently available security tools that block DDoS attacks coming from Mirai botnets. Also, a simple change of factory default username and password combinations can prevent IoT devices from being infected by the Mirai malware and, in effect, could prevent DDoS attacks.
Cybercriminals are, however, relentless in their campaigns. Since the publication of the Mirai source code, cybercriminals have tweaked the Mirai source code, for instance, infecting not just IoT devices, but enterprise servers as well. Attackers also don’t simply use factory default login details in infecting computer devices, but also exploit known security vulnerabilities.
Reaper IoT Botnet Threatens to Take Down Websites
Reaper IoT botnet, considered as more powerful than the Mirai botnet, is spreading worldwide and threatens to take down websites.
According to Check Point researchers, the Reaper botnet already infected one million IoT devices worldwide. "So far we estimate over a million organizations have already been affected worldwide, including the US, Australia and everywhere in between, and the number is only increasing," Check Point researchers said.
Researchers at Qihoo 360 Netlab, meanwhile, reported that the number of “vulnerable devices in one c2 queue waiting to be infected” reached over 2 million.
IoT botnet refers to internet-connected smart devices which are infected by one malware and is controlled by a cyber criminal from a remote location. It’s typically used by cyber criminals to launch a distributed denial-of-service (DDoS) attack.
“In a distributed denial-of-service (DDoS) attack, an attacker may use your computer to attack another computer,” the United States Computer Emergency Readiness Team (US-CERT) defines DDoS attack. “By taking advantage of security vulnerabilities or weaknesses, an attacker could take control of your computer. He or she could then force your computer to send huge amounts of data to a website or send spam to particular email addresses.”
Infecting millions of IoT devices with a malware is a time-consuming task. Cyber criminals found a way to automate this task by creating a botnet – an army of infected IoT devices. The Reaper malware, as well as the Mirai malware, is spread by the IoT devices themselves. After infecting a particular IoT device, this infected device starts to look for other devices to infect.
The Mirai botnet in October 2016 brought down major websites – including Twitter, Spotify and Reddit – by launching a DDoS attack against the DNS infrastructure of New Hampshire-based company Dyn. Many major websites rely on Dyn’s internet infrastructure.
Reaper Botnet versus Mira Botnet
While the Reaper botnet shares similar characteristics with Mirai, it differs in many ways with the Mirai botnet. On September 30, 2016, the attacker known as “Anna-senpai” publicly released the source code of Mirai. According to Check Point and Qihoo 360 Netlab researchers, Reaper borrows some of the source code of Mirai, but this new botnet is significantly different from Mirai in several key behaviors.
Here are some of the differences between Reaper and Mirai:
1. Number of Affected IoT Devices
The first difference between the Reaper botnet and Mirai botnet is in terms of the number of affected IoT devices. Mirai affected about 500,000 IoT devices, while Reaper has infected over a million IoT devices.
2. Means of Infecting IoT Devices
Mirai was able to infect hundreds of thousands of IoT devices by exploiting the lax attitude of IoT users of not changing the factory or default login and password details. By using default login and password details, Mirai attackers were able to infect a massive number of IoT devices.
On the hand, Reaper’s means of infecting IoT are by exploiting several IoT vulnerabilities which the devices’ manufacturers may or may not have issued security updates or patches. Reaper attackers can, therefore, infect IoT devices even if a strong password is used as the means of entry to the device is by exploiting known software vulnerabilities.
According to Check Point researchers, the Reaper, for instance, infects unpatched wireless IP cameras by exploiting the “CVE-2017-8225” vulnerability.
3. Botnet Capabilities
Mirai already showed what it can do: It brought down major websites worldwide even for just a few hours. For Reaper, it’s still unclear what it wants to do. As of this writing, Reaper’s creator or creators just want (based on the code they wrote) to infect as many IoT devices without yet writing the command to attack any internet infrastructure or websites.
"It is too early to guess the intentions of the threat actors behind it, but with previous Botnet DDoS attacks essentially taking down the Internet, it is vital that organizations make proper preparations and defense mechanisms are put in place before an attack strikes," Check Point researchers said.
The sheer number of infected IoT devices by Reaper – more than twice the number of Mirai’s victims – show how powerful and devastating Reaper can do when used as a means to launch a DDoS attack.
Gartner projected that 8.4 billion IoT devices will be in use worldwide in 2017 and will reach 20.4 billion by 2020. Examples of IoT devices include security systems (alarm systems, surveillance cameras), automation devices (devices that control lighting, heating and cooling, electricity), smart appliances (refrigerators, vacuums, stoves) and wearables (fitness trackers, clothing, watches).
"As more businesses and homeowners use Internet-connected devices to enhance company efficiency or lifestyle conveniences, their connection to the Internet provides new vulnerabilities for malicious cyber actors to exploit," the US Federal Bureau of Investigation (FBI) said. "Once an IoT device is compromised, cyber criminals can facilitate attacks on other systems or networks, send spam e-mails, steal personal information, interfere with physical safety, and leverage compromised devices for participation in distributed denial of service (DDoS) attacks."
How to Block Reaper IoT Botnet
In most cases, owners of infected IoT devices are unaware that their devices are infected and are used for criminal activities, such as launching a DDoS attack. IoT users who fail to change their devices’ default login and password details, as well as by failing to apply security updates, are part of the problem for “blindly” contributing to cyber criminal activities like DDoS attacks.
Here are the top cyber security measures to stop attackers from infecting your IoT devices and turned it into a botnet:
1. Timely Apply Security Updates of IoT Software
Always apply in a timely manner all security updates issued by your IoT manufacturer.
2. Use Strong Password
While the sophisticated malware like the Reaper can bypass strong password, it still pays to use a strong password to ward off less sophisticated malware.
3. Isolate IoT devices on their own protected networks.
4. Block traffic from unauthorized IP addresses by configuring network firewalls.
5. Turn off IoT devices when not in use.
6. When buying an IoT device, look for manufacturers that offer software updates.
Steve E. Driz, I.S.P., ITCP