Let’s discuss facts: An insight into Mirai’s source-code

In three massive DDoS attacks, Mirai botnet dazzled the cyber-security industry who long feared the implications of the exponentially growing number of devices connecting to the internet.

So many speculations, blogs and Op-Eds emerged following the attacks on Krebs, OVH and DynDNS. You couldn’t ignore them as everybody had something to say – speculation on who the attackers were, their motivation, the attack vectors and the traffic volumes. In this blog post, we would like to put an end to the speculation, and discuss facts.

One of our customers – a global DNS provider – reported fluctuations of 70 to 180 Gbps GRE flood attack mitigated by Radware’s DDoS protection. In analyzing the attack traffic, we identified a bot sending GRE traffic with encapsulated UDP packets which contained 512 bytes of random data. Based on the attack patterns, we created a dedicated mitigation for our customers.

This screenshot shows the bot sending GRE packets.

When Mirai’s source-code became public, our top priority was to validate that the GRE attacks against our customer exist and are identical to the attack within the source code.

Understanding the Malware

Iot devices are attractive targets for hackers for several reasons:

• First, they usually fall short when it gets to endpoint protection implementation.
• Second, there are no regulations or standards for a secure use of IoT devices as exists for PCs and servers, for example. Such regulation shall ensure secured configurations and practices such as changing default passwords, and access control restrictions (for instance, disable remote access to administrative ports).
• Third, they operate 24*7 and can be used at any moment.

Common malware usually takes advantage of zero-day and known exploits to gain control over their target machines. This is usually complex and time consuming. Mirai authors wisely chose to skip the wearing zero-day research and instead attack one of the most insecure areas in the cyber landscape – IoT devices.

Mirai specifically targets devices such as closed-circuit television cameras, routers and DVR’s, taking them over to create a botnet which is later used to launch sophisticated multi-vector DDoS assaults. Mirai scans for potential targets – specifically devices with default manufacturer credentials. Most are hard coded into the device hardware by the manufacturer. Mirai remotely connects to the attacked targets using Telnet and SSH access points which are often left open by default. With a basic dictionary attack, Mirai gains control over its targets using the default credentials.

[You might also like: How Friday’s Massive DDoS Attack in the U.S. Happened]

Figure 2: A portion of the dictionary content used by the malware

New Dangers Lurking in Mirai Source Code

The malware’s source code was written in C and the code for the command and control server (C&C) was written in Go.

Mirai hosts common attacks such as SYN and ACK floods, as well as introduces new DDoS vectors like GRE IP and Ethernet floods. Mirai also features evasion mechanisms to bypass known security controls and mitigation methods before reaching its target.

Figure 3: Menu of Mirai’s attack vectors

GRE Flood Attack

Generic routing encapsulation (GRE) is a tunneling type protocol developed by Cisco. GRE mainly encapsulates data packets and routes them through the tunnel to a destination network that de-encapsulates the payload packets. Sending many GRE packets with large amount of encapsulated data may lead to resource consumption once the victim will try to de-encapsulate them until exhaustion. The payload’s elements confirmed that the GRE flood attack we mitigated was generated by the original form of Mirai botnet.

Figure 4: A function creating a GRE packet and including it within a GRE flood attack

HTTP (Layer 7) flood attack

HTTP flood consists of seemingly legitimate session-based sets of HTTP GET or POST requests sent to a target web server. These requests are specifically designed to consume a significant amount of the server’s resources, and therefore can result in a denial-of-service.

HTTP makes it difficult for network security devices to distinguish between legitimate HTTP traffic and malicious HTTP traffic, and could cause a high number of false-positive detections. Rate-based detection engines are also not successful at detecting HTTP flood attacks, as the traffic volume of HTTP floods may be under detection thresholds. Because of this, it is necessary to use several parameters detection including rate-based and rate-invariant.

Mirai’s HTTP L7 attack’s strings are encrypted within the source code. Using the encryption key, we were able to decrypt it and continue to review the code.

Figure 5: Encryption of Mirai’s scripts

Figure 6: HTTP flood function

Figure 7: Mirai’s HTTP flood program creates 80MB POST requests

The malware is able to recognize DDoS protection solutions and adjust the attack accordingly.

Figure 8: Mirai trying to evade DDoS Protection

Mirai uses common headers and standard user agents to emulate legitimate traffic. This type of attack could be mitigated using an automatically adapting, network behavioral solution that differentiates legitimate user traffic from botnet traffic.

Figure 9: Http headers used by Mirai

TCP STOMP Attack

The classic ACK flood attack with a twist. As simple botnets will be easily blocked by most network security solutions as they send large volumes of ACK packets, Mirai starts with the ACK flood only after gaining a legitimate sequence number by completing the TCP connection process. By receiving a sequence number, Mirai raises the odds of bypassing network security solutions.

DNS Water Torture Attack

The attacker sends a pre-crafted DNS query to the service provider DNS server. The malicious DNS query contains random string concatenated previous to the victim’s domain (For example xxxyyyy.www.VictimDomain.com). The DNS server will attempt to get an answer from the authoritative nameserver over and over with no success. Sending different false strings with the victims’ domain name will eventually dramatically increase the DNS server’s CPU utilization making it unreachable.

Essential DDoS Protection Elements

• Hybrid DDoS Protection– (on-premise + cloud) – for real-time protection that also addresses high volume attacks and protects from pipe saturation.
• Behavioral-Based Detection– to quickly and accurately identify and block anomalies while allowing legitimate traffic through.
• Real-Time SignatureCreation – to promptly protect from unknown threats and 0-day attacks.
• Protect your GRE Tunnels –or have your providers do so by monitoring and probing the traffic that passes through them.
• A cyber-security emergency response plan –that includes a dedicated emergency team of experts.

Research Contributors: Shai Levy, Namik Binyaminov