A Look at Linux: Threats, Risks, and Recommendations

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.

Cryptocurrency miners

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.

Malicious scripts

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

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.

• Umbreon

  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.

• Drovorub

  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

  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.

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