Cyber miscreants have developed a new strain of malware based on Mirai to turn insecure IoT devices into a DDoS attack platform.
Last week, a distributed denial of service attack (DDoS) on DNS provider Dyn last week managed to disrupt an array of the internet’s biggest websites, including Spotify, Twitter, and PayPal.
What was most interesting about this attack was that it was largely carried out using an Internet of Things (IoT) botnet called Mirai (Linux.Gafgyt).
The new version of this malware has been discovered by security researchers at MalwareMustDie.org and relies on default hard-coded credentials to spread across vulnerable devices like the infamous Mirai botnet. The malware is primed for DDoS and IPv6 ready.
According to the researchers, it is designed to target IoT device via telnet protocol. It then deploys the originally coded telnet scanner function, which is brute-forcing the known vulnerable credential of the Linux IoT boxes, via a command sent from a CNC malicious IRC server.
The botnet is having DoS attack mechanism like UDP flood, TCP flood, along with other attack methods, in both IPv4 and IPv6 protocol, with extra IP spoof option in IPv4 or IPv6 too.
When did Mirai emerge?
Mirai first came to public attention when it was used in a huge DDoS attack against the website of journalist Brian Krebs, which reached 620 Gbps, on September 20. The source code for the botnet was then publicly released on the English-language hacking community Hack forums on September 30 by a user using the screen name Anna-senpai.
How does Mirai work?
Mirai works by exploiting the weak security on many IoT devices. It operates by continuously scanning for IoT devices that are accessible over the internet and are protected by factory default or hardcoded user names and passwords. In a Security Response blog last month, Symantec indicated that the default user names and passwords for IoT devices are often never changed. Mirai infects devices with malware that forces them to report to a central control server, turning them into a bot that can be used in DDoS attacks.
In which attacks has Mirai been used?
Following the aforementioned Krebs attacks, which was record-breaking at the time, Mirai was used in an attack on French hosting company OVH that peaked at 1 Tbps. However, it was last week’s attack on Dyn, which brought the internet to a standstill and raised questions about how powerful these DDoS attacks could become. In a blog following the attack, Dyn said it had “observed 10s of millions of discrete IP addresses associated with the Mirai botnet that were part of the attack.” Upon further analysis, Dyn lowered that estimate.
What devices are at risk of exploitation/infection?
Routers, DVRs, CCTV cameras, and any other ‘smart’, internet-connected appliances are at risk of attack. Webcams were the primary devices exploited in the Dyn attack, while CCTV cameras are believed to have been the IoT device primarily utilized in the attack on OVH. These devices weren’t protected by a firewall or router using NAT, which allowed them to be easily compromised. Additionally, many IoT devices take advantage of a feature known as Universal Plug and Play (UPnP) which opens a port on the router to allow them to be accessible from the internet.
How are device manufacturers responding?
The Chinese electronics firm behind many of the webcams used in the attack on Dyn’s services, XiongMai Technologies, issued a recall for many of its devices following the attack.
What is the likelihood my device will be attacked?
Analysis this week by Symantec concluded the average IoT device is scanned every two minutes. This means that a vulnerable device, such as one with a default password, could be compromised within minutes of going online.
Why are IoT devices being targeted?
Poor security on many IoT devices makes them soft targets and attackers often pre-program their malware with commonly used and default passwords. Processing power limitations and basic operating systems mean many IoT devices don’t have advanced security features. As they are often designed to be plugged in and forgotten about, owners often don’t apply security updates and it is easy for an attack on such devices to go unnoticed.
Why was Mirai’s source code leaked?
This is unknown. However, leaks often occur when attackers become concerned about discovery and want to “muddy the waters” by putting the malware in the hands of more attackers.
Source code leaks can also lead to new varieties of the malware emerging. It is possible that other attack groups may modify Mirai to attack a wider range of IoT devices.
How many passwords is Mirai configured to try?
Analysis by Symantec of recent Mirai samples has found the malware is configured to use a list of at least 62 username and password combinations, most of which are commonly used default credentials for IoT devices.
Can a Mirai infection be removed?
Devices that become infected with Mirai can be cleaned by restarting them. However, due to constant scanning for devices by the botnet, vulnerable devices can become re-infected within a matter of minutes of going back online unless the default credentials are changed.
Symantec Security Response has the following tips to protect your IoT device from becoming infected with malware.
Research the capabilities and security features of an IoT device before purchase
Perform an audit of IoT devices used on your network
Change the default credentials on devices. Use strong and unique passwords for device accounts and Wi-Fi networks.
Use a strong encryption method when setting up Wi-Fi network access (WPA)
Disable features and services that are not required
Disable Telnet login and use SSH where possible
Disable Universal Plug and Play (UPnP) on routers unless absolutely necessary
Modify the default privacy and security settings of IoT devices according to your requirements and security policy
Disable or protect remote access to IoT devices when not needed
Use wired connections instead of wireless where possible
Regularly check the manufacturer’s website for firmware updates
Ensure that a hardware outage does not result in an unsecure state of the device