A Look at Linux: Threats, Risks, and Recommendations
Linux, which started as a personal project 30 years ago, is presently one of the most powerful operating systems dominating cloud platforms and servers around the world today. In fact, Linux usage has now exceeded that of Windows on Azure, Microsoft’s own cloud platform.
Linux is also undeniably ubiquitous. According to the Linux Foundation’s 2017 State of Linux Kernel Development Report, Linux ran on 90% of the public cloud workloads and nine of the top 10 public cloud providers. On top of these, Linux also ran on 82% of the world’s smartphones and had a gargantuan market share of 99% on the supercomputer market.
Like any software, however, Linux is not free from security-related threats and risks. As enterprises migrate to the cloud and consequently, Linux, it comes as no surprise that cybercriminals would shift their focus and resources to target these environments — including their weak spots — for ill gain.
This article aims to discuss the Linux threat landscape and examine how Linux has become an attractive target for attackers, as well as how it can be prone to a variety of threats and risks. These include vulnerabilities, misconfigurations and security gaps, and malware. Aside from giving a high-level overview of the security issues and threats that affect Linux today, this article will also provide essential security recommendations to defend Linux environments against threats and help mitigate risks.
Vulnerabilities remain prevalent in and on the Linux platform
One of the most common methods used by cybercriminals to gain initial access into an environment is the exploitation of a vulnerability in a publicly hosted service. The lack of both vulnerability management and tracking procedures, not to mention the absence of proper system patching processes, can leave systems highly exposed when a vulnerability is found and an exploit is published. Currently, it only takes a few days — sometimes even just hours — before someone figures out an exploit for a vulnerability. This concern is more critical for Linux as most of the code that runs on it is open-source, and the time and skills required to reverse-engineer a patch is possibly shorter than ever.
Thousands of vulnerabilities plague different Linux distributions
It is important to consider not just the vulnerabilities in the platform itself, but also what is being run on the platform, since exploitability and exposure through either differ from one another. It should be noted, however, that the sheer number of vulnerabilities in a service or platform does not necessarily mean that these vulnerabilities automatically pose a substantial risk to those systems.
To get a better sense of the volume of vulnerabilities across various Linux distributions, we dissected the Common Vulnerabilities and Exposures (CVE) data from Red Hat, Ubuntu, Debian, Oracle Linux, and SUSE. The following graphs show the number of security advisories issued by each vendor for their respective Linux distribution.
Figure 1. The number of Important/High security advisories issued per Linux vendor or distribution per year from January 1, 2015 to December 31, 2020
Figure 2. The number of Critical security advisories issued per Linux vendor or distribution per year from January 1, 2015 to December 31, 2020
Each Linux distribution vendor follows a different vulnerability-handling procedure. While patches from vendors come at varied times, upstream patches — whether original package or utility source — are the first to show up. Linux vendors are responsible for patching vulnerabilities in components such as the kernel, stock utilities, and packages. In 2019, Red Hat fixed over 1,000 CVEs on their Red Hat Enterprise Linux (RHEL) distribution, according to their Product Security Risk Report. That’s more than 70% of the total number of vulnerabilities fixed across all their products.
Linux vulnerabilities lead to RCE, breaches, other critical security risks
Application Stack vulnerabilities
Vulnerabilities in the application stack were the reason behind several breaches in the past. For example, a well-known breach at Equifax was a result of the exploitation of a vulnerability in Apache Struts, known by the identifier CVE-2017-5638. The MITRE ATT&CK framework lists the “Exploit Public-Facing Application” for ID T1190 which is a common initial entry point for attackers that allows them to take advantage of flaws in internet-facing workloads. Some of the most popular vulnerabilities in this category are listed in the Open Web Application Security Project (OWASP) Top 10 and the Common Weakness Enumeration and SysAdmin, Audit, Network, and Security (CWE/SANS) Top 25 Most Dangerous Software Errors, which are both standard awareness references for developers and web application security practitioners. These documents represent a broad consensus of the most critical security risks to web applications, including vulnerabilities such as SQL injection, cross-site scripting (XSS), XML external entities (XXEs), and unsecure deserialization. Notably, web applications have become the initial point of entry on many of these attacks since they are the most exposed and are usually highly vulnerable.
Misconfigurations, security gaps in the cloud
Misconfigurations are quite common and have always been a critical security concern. In fact, the first version of the OWASP Top 10 Web Risks that was released in 2004 included what was then referred to as “Insecure Configuration Management,” which was later revised to “Security Misconfiguration” in the 2017 version of the list. In the CWE system, it’s identified as CWE-16 or Configuration, which is described as “weaknesses that are typically introduced during the configuration of the software.”
When enterprises started shifting to the cloud for operational and economic resiliency (especially during the global pandemic), misconfigurations became an even bigger security concern. It seems that as enterprises and organizations moved to new ecosystems, they inadvertently brought misconfigurations over to these new environments — in particular, the cloud, containers, and serverless.
The following are the most common misconfigurations and security gaps in the Linux environment.
Using default or weak passwords — or none at all
It only takes the use of a weak password — let alone none at all — for cybercriminals to gain unfettered access to systems and environments. Unfortunately, the use of default or weak passwords is still surprisingly common. Passwords, which are pieces of sensitive information, should be as secure as possible. For critical administrative or service accounts, the use of keys and certificates should be encouraged rather than set passwords.
A well-known example of abuse that centered on the lack of authentication happened at Tesla, when cybercriminals were able to access an open and unauthenticated administrative console dashboard. The attackers were able to compromise a running Kubernetes pod and obtained Tesla’s AWS credentials in order to run cryptocurrency-mining malware.
In November 2020, the FBI issued a security alert that cybercriminals were abusing misconfigured instances of SonarQube, an open-source automatic code-reviewing tool that detects bugs and security vulnerabilities in source code, to access and download source code from government agencies and private organizations. According to the FBI, some organizations have left these systems exposed to the internet. These systems run on their default installation configuration (port 9000) using default admin user credentials (admin/admin).
Consumer devices are also prone to misconfiguration. Several internet of things (IoT) devices, including but not limited to routers, IP cameras, and digital video recording (DVR) devices, also come with either no passwords or default passwords that can easily be found online, as seen on the Default Passwords Database.
Exposed services on the internet (aka open ports)
Leaving services exposed to the internet when these are only supposed to be accessible to local or adjacent networks is one of the profoundly serious, yet often overlooked misconfigurations. Furthermore, it’s important to note that not all attacks will manifest themselves with some form of “noise.” Rather, an attacker could simply leave a backdoor installed or run a low-compute activity on the compromised host, which would make such activities difficult to detect. Keeping services and systems away from having direct access to the public internet would therefore reduce the attack surface.
As an example of services that are exposed on the internet, we published a story on how we discovered more than 8,000 Redis instances that run unsecured in different parts of the world, including the ones that are deployed on the public cloud. These Redis instances have been found without TLS encryption and are not password-protected. Later, we identified that these exposed Redis instances were being abused for RCE and cryptocurrency mining.
As part of security assessment, open ports or security groups must be monitored on a regular basis. Threat and risk assessments (TRAs) are helpful but are not regularly performed, so it is recommended to utilize online services (such as Shodan Monitor) that can regularly watch infrastructures and show internet-facing devices and systems. Quite often, Shadow IT, or the use of unsecured services and devices, will lead to exposed services without the knowledge of security or IT groups.
Open file shares
Though not as common as exposing services to the internet, having publicly accessible shares can leave a lot of information at risk. FTP, SMB, and NFS shares, directory listings on web servers, as well as open cloud storage services such as Amazon S3 and Azure Blob can all potentially expose data to an unintended audience. On Shodan alone, we found more than 3 million FTP servers that are exposed publicly using the query, ftp port:"21".
Exposed and unprotected APIs
With the increase in DevOps and automation over the last decade, declarative APIs are more commonplace than ever. Some applications have a robust design and access control on APIs, while others have a weaker design and use very relaxed or non-existent security measures. Some of these services are designed to be run as a microservice with access only from certain consumers. If these APIs are accidentally left open or unencrypted, they can be abused for various motives, such as using compute resources, installing backdoors, or simply sabotaging the normal operations of an organization. We observed the abuse of Docker’s API to run rogue containers and also discuss such abuse in detail in multiple publications.
Figure 3. The total number of publicly exposed FTP servers according to a Shodan search performed on January 5, 2021
Malware families run rampantly on Linux
All the different varieties of malware — such as ransomware, cryptocurrency miners, user- and kernel-mode rootkits, worms, trojans, backdoors, remote access trojans (RATs) — also exist in the Linux platform. The motivation behind such attacks remains the same: financial gain, espionage, sabotage, hacktivism, or simply the desire to prove that systems can be compromised.
The following are the most pervasive malware types in the Linux ecosystem.
Ransomware needs no introduction. With millions of dollars having been paid to cybercriminals (both with and without success of decryption), it is by far the most successful category of malware in recent times. Given the prevalence of Linux, ransomware actors find the operating system to be a very lucrative target.
According to the managed security company Secureworks, RansomEXX (aka Defray777) is associated with the Gold Dupont cybercriminal group. The group’s objectives are focused on financial gain through the use of their main tools: RansomEXX, Cobalt Strike, Metasploit, and the Vatet loader. In 2017, the group was found to have been targeting the healthcare, education, manufacturing, and technology industries. Recently, RansomEXX has been ported to Linux. As a matter of fact, in December 2020, cybercriminals exposed critical company data that they had exfiltrated from a RansomEXX attack because the company opted not to pay the ransom and instead restored their systems via backups.
Erebus was first seen in September 2016 via “malvertising,” the use of ads to propagate malware campaigns. It later reemerged in February 2017 and used a method that bypasses Windows’ User Account Control (UAC). In June 2017, Erebus infected 153 Linux servers of NAYANA, a South Korean web hosting company and consequently, 3,400 business websites that the company hosts. It can be inferred that Erebus could have possibly leveraged either vulnerabilities or a local Linux exploit (such as the Dirty COW vulnerability) which could have provided attackers with root access to vulnerable Linux systems.
A relatively new motive for attackers involves infiltrating and abusing computing resources to mine for cryptocurrency. Cybercriminals can abuse cryptocurrency mining, an extremely resource-intensive activity, by infecting devices and systems with malicious miners in order to steal resources from their victims.
In a blog, we detail how Linux cryptocurrency-mining malware can run arbitrary code via vulnerability exploitation, brute-force attacks, or the abuse of exposed service APIs. We also discuss the behavior of the cryptocurrency-mining malware samples that we’ve seen targeting Linux host machines: These also kill any other cryptocurrency mining malware on an infected machine and look for powerful tools with nearly limitless compute powers, such as Docker or Redis containers.
Another coinminer, detected by Trend Micro as Coinminer.Linux.MALXMR.SMDSL64, was found to have been exploiting common vulnerabilities such as the SaltStack Authorization Bypass (CVE-2020-11651) and the SaltStack Directory Traversal (CVE-2020-11652), according to data from the Trend Micro™ Smart Protection Network™. Earlier this year, researchers found an open directory that contains malicious files, which had been first reported in a series of tweets by the MalwareHunterTeam. After analyzing some of the files, we found a malicious cryptocurrency miner and a distributed denial-of-service (DDoS) bot that targets open Docker Daemon ports. This coinminer was later detected as Coinminer.SH.HADGLIDER.A.
Shell scripts are utilized for their simplicity. With these, Unix programmers can easily execute multiple Linux commands that are embedded in a single file. Shell scripts are interpreted by the shell or by the Linux command-line interpreter. This tool, which can be found in all UNIX machines, is also abused by cybercriminals.
Sneaking in a malicious script is easier than using compiled malware. There are several reasons behind the popularity of using malicious scripts for Linux attacks:
- They are easy to upload as text files.
- They are smaller in size.
- They are less likely to be detected easily.
- They can be created on the fly.
Once these scripts make their way to the target host, they are executed in a safe location where they cannot be flagged, such as the /tmp folder. Generally, these scripts do not carry out anything malicious on their own, although they do connect to the command-and-control (C&C) server to download malware.
Web shells and backdoors
A web shell is a script that an attacker plants in a web server to either help them run commands that they can control or simply gain direct access to compromised systems. In August 2020, we came across Ensiko, a PHP web shell that targets Linux, Windows, macOS, or any other platform that has PHP installed. Aside from executing code remotely, attackers can also execute shell commands and deface websites using this malware variant.
Cybercriminals also use backdoors to gain access to critical systems, such as the one detected by Trend Micro as Backdoor.Linux.KINSING.A. This malware is a Golang-based Linux agent that searches for misconfigured Docker Daemon API ports to run an Ubuntu container.
Rootkits are persistent threats that are intended to be hard to detect or observe. A rootkit’s main purpose is to keep itself and other malware threats unbeknownst, on one hand, to administrators, analysts, and users, and on the other, undetected by scanning, forensic, and system tools. Rootkits might also open a backdoor or use a C&C server and provide an attacker with ways to control and spy on an affected machine.
On Linux, when a program calls the printf() function, there are other cascaded functions in the same library that can get subsequently called, such as _IO_printf() and vprintf(). All these functions end up calling the write() system call. An example of this is the rootkit Umbreon, which we detected a few years ago. In our technical analysis, we provide details of Umbreon, a rootkit with multiple architectures that targets both Linux and other systems that run Intel and ARM processors.
Fancy Bear, which also goes by Pawn Storm, Sednit, APT28, Sofacy, and Strontium, is an active cyberespionage organization that has become notorious for foreign and domestic espionage especially in recent years. This group is responsible for a Linux malware toolset called Drovorub, which can connect to a C&C infrastructure, download and upload malicious files, and perform RCE.
Diamorphine is a loadable kernel module (LKM) rootkit used for Linux kernels 2.6.x/3.x/4.x/5.x and ARM64. It deserves a mention here as it was used in recent attacks in early 2020 by a hacking group called TeamTNT. According to Cado Security, the malicious actors used Diamorphine together with a malware variant that is similar to the Kinsing worm to steal AWS credentials and local credentials, as well as to scan the internet for misconfigured and exposed Docker and Kubernetes API servers.
The ubiquity of Linux and its use to handle critical information make it a very lucrative target for attackers. The growing list of ransomware families targeting Linux and the sheer number of vulnerabilities being exploited by malicious actors to compromise the Linux environment serves as evidence for the same. These Linux-based threats confirm the need for strengthened security, especially for enterprises and organizations that use the operating system in critical business platforms.
Security recommendations for Linux systems
As enterprises operate and innovate at unprecedented speeds, Linux usage is bound to become even more pervasive than it is now. More significantly, as more users and high-value enterprises rely on Linux for their online infrastructures and systems, it is inevitable that cybercriminals will also increasingly target Linux environments for financial gain.
Here are a few security recommendations to keep Linux systems secure:
- Adopt infrastructure as code (IaC) practices to ensure that systems are created properly and that their configurations remain as intended.
- Adopt the principle of least privilege and the shared responsibility model.
- Keep visibility at the forefront. Monitor all devices, systems, and networks.
- Replace default passwords with strong and secure ones. Always opt for multifactor authentication.
- Regularly patch and update systems.
Trend Micro solutions
Trend Micro’s comprehensive XDR solution applies the most effective expert analytics to the deep data sets collected from Trend Micro solutions across the enterprise, making faster connections to identify and stop attacks. Powerful artificial intelligence (AI) and expert security analytics correlate data from customer environments and Trend Micro’s global threat intelligence to deliver fewer, higher-fidelity alerts, leading to better, early detection. One console with one source of prioritized, optimized alerts supported with guided investigation simplifies the steps to achieving a full understanding of the attack path and impact on the organization.
Cloud-specific security solutions such as Trend Micro Hybrid Cloud Security can help protect cloud-native systems and their various layers. Hybrid Cloud Security is powered by Trend Micro Cloud One™, a security services platform for cloud builders that provides automated protection for continuous integration and continuous delivery (CI/CD) pipelines and applications. It also helps identify and resolve security issues sooner and improve delivery time for DevOps teams. Cloud One includes:
- Workload Security: runtime protection for workloads
- Container Security: automated container image and registry scanning
- File Storage Security: security for cloud files and object storage services
- Network Security: cloud network layer for intrusion prevention system (IPS) security
- Application Security: security for serverless functions, APIs, and applications
- Conformity: real-time security for cloud infrastructure — secure, optimize, comply
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.