This post is also available in: 日本語 ( Japanese )

Executive Summary

Palo Alto Networks is proactively trying to safeguard its customers from attacks however possible. By leveraging its Next-Generation Firewall as sensors on the perimeter to detect malicious payloads and attack patterns, Unit 42 researchers are able to hunt down the menaces out there on the network, be they known or not.

Unit 42 researchers have taken a closer look at four Mirai variants from two recently discovered campaigns leveraging command injection vulnerability exploits that reveal a familiar IoT attack pattern.

While this generic approach allows researchers to observe the entire killchain and even acquire the malware binary from the attack, this post-exploitation heuristic does have its caveat: the traffic fingerprinting. Similar services yield similar traffic patterns because of similar, if not identical, code bases and underlying implementation. Since a service can exist in multiple devices with different configurations and there are multiple brands for a specific device, it’s become exponentially hard, if not impossible, to identify the susceptible device(s) in real time.

This blog includes a brief analysis of the two IoT exploits observed in the wild and the four Mirai variants delivered during the attack. Palo Alto Networks Next-Generation Firewall customers are protected against these attacks.

Exploit Payloads Include Mirai Variants

A total of four Mirai variants were recently discovered. Two new vulnerabilities were leveraged as attack vectors to deliver Mirai. Upon successful exploitation, the wget utility is invoked to download a shell script from the malware infrastructure. The shell script then downloads several Mirai binaries compiled for different architectures and executes these downloaded binaries one by one.

The first exploit, shown in Figure 1, targets a command injection vulnerability in a web service with an NTP server setting feature. The service fails to sanitize the value of the HTTP parameter NTP_SERVER, which in turn leads to arbitrary command execution.

Following the leads acquired from the attack traffic, we have narrowed our scope to some IoT devices that are known to synchronize time through HTTP and found several vulnerable NTP-server-handling routines in firmware in some IoT devices, which is concerning since some vendors no longer support the products running said firmware. Figure 2 shows one such vulnerable function found in a library module. While the firmware that we have analyzed have such insecure functions, they are fortunately impervious to this specific attack because the targeted uniform resource identifier (URI) is not present in these firmware. The identification of the affected product is still in progress as we proceed to analyze other IoT devices that are likely to do time synchronization through HTTP.

The initial attack incident of the first exploit was observed on July 23, 2020, at 05:55:06 a.m. UTC. The attack (shown in Figure 1) lasted for a few weeks, with the last incident reported on Sept. 23, 2020, at 15:21:23 p.m. UTC. There were 42 unique alerts at the time of this writing.

The second exploit caught in the wild provides less context than the first exploit; the URL and the HTTP request headers do not yield any useful insights. Evidently, there is a lack of parameter sanitization in the HTTP parameter pid that results in a command injection vulnerability, as shown in Figure 3. We speculate that the targeted service is some type of remote process management tool because of similar parameter patterns in the attack traffic, and that it’s possibly experimental and thus low in usage.

A total of 48 unique attack incidents occurred in just 12 seconds. The attack started on Aug. 16, 2020, at 09:04:39 a.m. UTC, and it ended on Aug. 16, 2020, at 09:04:51 a.m. UTC, indicating that this exploit is quick and short-lived.

We grouped the Mirai variants by numbers: one, two, three and four. The SHA256 for each of the Mirai variants are available in the Indicators of Compromise section below. Table 1 shows the delivery method as well as the embedded decryption key for each variant.

Table 1. Delivery methods and the decryption key.

While these variants do not share the exact same origin and configuration, they all possess the necessary functionality to launch DDoS attacks. Variant four also possesses an infection capability that is not present in the other three variants, making it a more dangerous threat. Table 2 below summarizes the exploits that this particular Mirai variant uses for infecting other vulnerable hosts. Just like its predecessors, this variant inherits exploits that were also used in the previous variants .

Table 2. Variant four’s infection capability.

Conclusion

Security for IoT devices is still concerning. One major challenge for IoT security is that IoT devices that are no longer supported are still being deployed and used. Flaws in their firmware unfortunately do not just go away with an end-of-life and end-of-support announcement. The good news is that Palo Alto Networks offers the following products and services to protect its customers from this kind of attacks, whether the threat is known or not: