An in-depth look at how to secure containerized environments and how they bring unique security concerns.
Containers are self-contained, portable application environments. They include all of the binaries, libraries, configuration files, and dependencies that a programme need to execute (Docker and Amazon Elastic, for instance, are two of the more well-known offerings).
Multiple containers can run on the same infrastructure and utilise the same operating system kernel, but they’re separated from that layer and have little interaction with the underlying hosting resources (which could be, for example, a public cloud instance).
The capacity to easily spin up and down programmes for users (think “write once, run everywhere” – a significant boon for enterprises managing pandemic-related distant footprints) is one of the many advantages of operating cloud-based containers. When compared to administering applications on owned-and-operated servers or virtual machines, they also save a lot of money on infrastructure. They also improve agility by assisting DevOps objectives.
Thanks to orchestration engines like Kubernetes, containers are also simple to manage. Admins may utilise orchestration to centrally manage containerized apps and services at scale, such as putting out automated updates and isolating any malfunctioning containers.
As a result, container adoption is at an all-time high, with businesses of all sizes eager to jump on board. According to a poll conducted by the Cloud Native Computing Foundation (CNCF), 83 percent of respondents plan to use Kubernetes in production in 2020, up from 78 percent the year before and just 58 percent in 2018.
The interest of hackers grows in lockstep with adoption. According to a June Red Hat study, 94 percent of those polled had experienced a Kubernetes security problem in the preceding year.
“Kubernetes attacks are fairly regular,” stated Trevor Morgan, product manager at comforte AG. “The threat landscape for Kubernetes setups is fairly diverse.”
“Whether they are state-sponsored operatives attempting to destabilise other political institutions or members of a gang or an individual attempting to steal for financial benefit, the unifying denominator is always sensitive information,” he continued. If threat actors gain access to sensitive data, they can use it to create more detailed data subject profiles (which they can later exploit for malicious reasons), hold data for ransom, and weaponize it in a variety of ways. And don’t overlook the sheer worth of turmoil that all of this may provide. They flourish in fearful surroundings.
As an illustration of how common it is to target weak cloud infrastructure, Akamai security researcher Larry Cashdollar recently set up a basic Docker container honeypot to test what type of attention it would get from the larger web’s cybercriminals. The outcomes were startling: In the period of 24 hours, the honeypot was used for four distinct criminal schemes.
Cashdollar used the SSH protocol for encryption and used a root password that was “guessable.” It wouldn’t stick out as an obvious honeypot on the web since it was running a typical cloud container setup, he stated. It would instead appear to be a vulnerable cloud instance.
The assaults had a variety of objectives: one campaign intended to utilise the container as a proxy to access Twitch feeds or other services, another attempted a botnet infection, a third attempted cryptomining, and the fourth attempted to conduct a work-from-home fraud.
“Profit is still the key motivator for hackers attacking containers,” as these cases demonstrate, according to Mark Nunnikhoven, renowned cloud strategist at Lacework. “Malicious actors want to reclaim access to resources or data that they may use to make money. CPU time and bandwidth may be resold to other criminals for underground services, or even used to directly generate cryptocurrencies. Data can be sold or ransomed at any time. In an ecosystem that strongly relies on containers, these reasons do not alter.”
This can lead to major (and costly) issues. For example, the “Siloscape” spyware, which is the first known malware to target Windows containers, was identified in June. It exploits Kubernetes clusters to install backdoors, raid nodes for credentials, and potentially take over a cluster’s whole database. Its main goal, according to experts from Palo Alto Networks Unit 42, is to open “a backdoor into poorly designed Kubernetes clusters in order to launch malicious containers.”
The problems with container configuration frequently extend beyond the containers themselves. Last July, for example, misconfigured Argo Workflows instances were detected attacking Kubernetes clusters.
Argo Workflows is an open-source, container-native workflow engine for coordinating parallel activities on Kubernetes in order to reduce processing time for compute-intensive tasks such as machine learning and large data processing. According to an examination by Intezer, malware operators were using publicly available dashboards that didn’t need authentication for outside users to drop cryptominers into the cloud.
Container Images that Have Been Compromised
Beyond misconfiguration, compromised images or layers are the second most serious threat to containers, according to Nunnikhoven. Images are static files that contain executable code and may be used to construct a container on a computer. They may be easily deployed by making them available through open-source repositories.
“Lacework Labs has witnessed multiple instances of hackers infiltrating containers, either through malware implants or pre-installed cryptomining apps,” he said. “When a group distributes the pictures, the attacker has access to the victim’s resources.”
A flaw in the Containerd runtime programme, which maintains the whole container lifespan of its host system, was discovered in 2020. According to Gal Singer, a researcher from Aqua Security, the problem (CVE-2020-15157) was discovered in the container image-pulling process. Adversaries may take advantage of it by creating special container images that would steal the host’s token when they were brought into a project. The token might then be used to seize control of a cloud project.
Similarly, a denial-of-service vulnerability in one of Kubernetes’ Go libraries (CVE-2021-20291) was discovered to be exploited by storing a malicious picture in a registry. When the picture was taken from the registry by an unwary user, the DoS condition was generated.
Parade of Bugs
Vulnerabilities, both known and unknown, are the next source of concern. In 2021, several container flaws were discovered, but “Azurescape” was likely the most alarming.
Within Microsoft’s multitenant container-as-a-service offering, Unit 42 researchers found a chain of vulnerabilities that might allow a hostile Azure user to infect other customers’ cloud instances. This important cross-account container takeover was dubbed a “public cloud horror scenario.”
According to Unit 42, “Azurescape is proof that they’re more real than we’d like to believe.” “Cloud companies invest significantly in safeguarding their systems, yet undiscovered zero-day vulnerabilities will inevitably exist, putting users at risk.”
Container Defense Best Practices
Containerized environments can provide unique issues in terms of observability and security controls, according to Nunnikhoven, but a layered security strategy can assist.
“Given the speed of change and the complexity of these settings,” he added, “organisations must be able to swiftly examine operational data in order to look for anomalous behaviours.” “In a container-based system, the typical strategy of having a list of ‘bad’ things to search for won’t work.”
Researchers recommended that users apply a laundry list of best practises to secure their Kubernetes assets:
Maintain patched cluster infrastructure; avoid default settings.
Use secure passwords
To prevent attackers from impersonating the token owner, do not send privileged service account tokens to anybody other than the API server.
Enable the “BoundServiceAccountTokenVolume” functionality by doing the following: When a pod ends, its token becomes invalid, reducing the risk of token theft.
Deploy policy enforcers to monitor and prevent suspicious behaviour within clusters, particularly service accounts or nodes that request permissions using the SelfSubjectAccessReview or SelfSubjectRulesReview APIs;
Take container images from trusted sources, store them in secure repositories, then tag and sign them with trust certificates. Archive obsolete versions from the repository as new versions become available;
Examine orchestrators for least-privilege settings to verify that CI/CD motions are authenticated, documented, and monitored;
Take a comprehensive approach: Create a unified risk picture that includes both cloud-based applications and traditional IT infrastructure.
Have data-analysis software in place, as well as an automatic runbook that can respond to the findings;
Give your security analysts the context and information they need to make an informed judgement, and then perform the appropriate automated reaction.
