Linux is now one of the most powerful operating systems prevalent on cloud platforms and servers worldwide. In fact, Linux usage has now surpassed that of Windows on Azure, Microsoft’s own cloud platform. According to the Linux Foundation’s 2017 State of Linux Kernel Development Report, 90% of public cloud workloads ran on Linux and nine of the top ten public cloud providers rely on this operating system. In addition, 82% of smartphones worldwide are equipped with it. Linux has a gigantic 99% market share in supercomputers. However, like any other software, Linux is not free from security-related threats and risks. Therefore, it is not surprising that cybercriminals focus their attention and resources on Linux target environments with their corresponding vulnerabilities. What are the biggest risks for these platforms?
One of the most common ways cybercriminals gain initial access to a Linux environment is by exploiting a vulnerability in a publicly hosted service. The lack of vulnerability management and tracking procedures, as well as the lack of proper system patching processes, can lead to high risks to systems when criminals find a vulnerability and an exploit is released. Currently, it only takes a few days, sometimes hours, for an exploit to be ready for a vulnerability. This problem is even more critical with Linux because most of the code is open source and the time and skills required to reverse engineer a patch are shorter than ever before.
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.
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.
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.
A second part presents the malware families most commonly used for Linux environments, as well as other malicious techniques, and also shows countermeasures against these threats.