Search This Blog

Showing posts with label Container Security. Show all posts

Safeguarding From Container Attacks Inside the Cloud


As an alternative to virtualization, containerization has become a key trend in software development. It entails encapsulating or packaging software code and all of its dependencies so it may execute consistently and uniformly across any infrastructure. Containers are self-contained units that represent whole software environments that may be transported. They include everything a program needs to run, including binaries, libraries, configuration data, and references. Docker and Amazon Elastic, as an illustration, are two of the extra well-known choices. 

Although many containers can run on the same infrastructure and use the same operating system kernel, they are isolated from such a layer and have a little interface with the actual hosting elements, for instance, a public cloud occasion. The ability to instantly spin up and down apps  for users, is one of the many advantages of running cloud-based containers. Admins may utilize orchestration to centrally manage containerized apps and services at scale, such as putting out automatic updates and isolating any malfunctioning containers.

Container adoption is at an all-time high, worldwide businesses of all sizes are 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. As adoption grows, cybercriminals' interest grows as well. According to a June Red Hat study, 94 percent of respondents have experienced a Kubernetes security problem in the last 12 months. 

Larry Cashdollar, an Akamai security researcher, recently set up a basic Docker container honeypot to test what type of attention it would get from the larger web's cybercriminals. The results were alarming: in just 24 hours, the honeypot was used for four different nefarious campaigns. Cashdollar had integrated SSH protocol for encryption and developed a “guessable” root password. It wouldn't stick out as an obvious honeypot on the web because it was running a typical cloud container configuration, he explained. It would instead appear to be a vulnerable cloud instance. The assaults had a variety of objectives: one campaign aimed to utilize the container as a proxy to access Twitch feeds or other services, another attempted a botnet infection, a third attempted crypto mining, and the fourth attempted a work-from-home hoax. 

"Profit is still the key motivator for cybercriminals attacking containers," as these cases demonstrate, according to Mark Nunnikhoven, a senior cloud strategist at Lacework. "CPU time and bandwidth can be rented to other criminals for buried services, or even used to directly mine cryptocurrencies. Data can be sold or ransomed at any time. In an environment where containers are frequently used, these reasons do not change." 

According to a recent Gartner study, client misconfigurations or mistakes would be the primary cause of more than 99 percent of cloud breaches by 2025. As per Trevor Morgan, product manager at comfort AG, most businesses, particularly smaller businesses, rely on default configuration options rather than more advanced and granular setup capabilities: "Simple errors or selecting default settings  that are far less safe than customized options." The problems with configuration typically go beyond the containers themselves. Last July, for example, misconfigured Argo Workflows servers were detected attacking Kubernetes clusters. 

Argo Workflows is an open-source, container-native workflow engine for coordinating parallel activities on Kubernetes 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 which did not require authentication for outside users to drop crypto miners into the cloud. Far above misconfiguration, compromised images or layers are the next most serious threat to containers, according to Nunnikhoven. "Lacework Labs has witnessed multiple instances of cybercriminals infiltrating containers, either through malware implants or pre-installed crypto mining apps," he said. "When a group deploys the pictures, the attacker has access to the victim's resources."

According to Gal Singer, an Aqua Security researcher, the flaw (CVE-2020-15157) was discovered in the container image-pulling process. Adversaries may take advantage of this by creating dedicated container images which stole the host's token when they were pulled into a 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 image was taken from the registry by an unwary user, the DoS condition was generated.

The second source of concern is vulnerabilities, both known and unknown. 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 exploits that might allow a hostile Azure user to infect other customers' cloud instances. 

Containerized environments can provide unique issues in terms of observability and security controls, according to Nunnikhoven, but a comprehensive security approach can help. Researchers recommended that users apply a laundry list of best practices to secure their Kubernetes assets: 

  • Avoid using default settings; use secure passwords.
  • To prevent attackers from impersonating the token owner, do not send privileged service account tokens to anyone other than the API server. 
  • Enable the feature "BoundServiceAccountTokenVolume": When a pod ends, its token becomes invalid, reducing the risk of token theft.
  • Examine orchestrators for least-privilege settings to verify that CI/CD movements are authenticated, logged, and monitored. 
  • Be comprehensive: 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 react to the findings.

Microsoft Alerted Azure Customers of Bug That Could Have Allowed Hackers to Access Data

 

Microsoft alerted some Azure cloud computing users that a vulnerability uncovered by security experts might have given hackers access to their data. 

In a blog post from its security response team, Microsoft stated it had patched the issue identified by Palo Alto Networks and had no sign malicious attackers had exploited the technique. It further stated that certain users have been asked to change their login passwords as a preventive measure. 

The blog post was in response to an inquiry from Reuters regarding Palo Alto's technique. Microsoft refused to respond to any of the inquiries, including whether or not it was assured that no data had been accessed. 

Palo Alto researcher Ariel Zelivansky told Reuters in a previous interview that his team had cracked Azure's widely used platform for so-called containers, which store applications for users. 

According to him, the Azure containers utilized code that had not been updated to address a known vulnerability. As a result, the Palo Alto team was finally able to gain entire authority over a group that comprised containers from other users. 

Ian Coldwater, a longtime container security expert who evaluated Palo Alto's work at the request of Reuters stated, "This is the first attack on a cloud provider to use container escape to control other accounts." 

In July, Palo Alto reported the problem to Microsoft. Zelivansky added it took his team several months to complete the project and agreed that malicious hackers were unlikely to apply a similar approach in real-world attacks. 

Nonetheless, this is the second significant issue discovered in Microsoft's fundamental Azure infrastructure in less than a month. Wiz security specialists revealed a database vulnerability in late August that would've let one client modify the data of another. 

In both situations, Microsoft's remarks were directed to customers who may have been harmed by the researchers' work, rather than everyone who was put in danger by its own code. 

Microsoft wrote, "Out of an abundance of caution, notifications were sent to customers potentially affected by the researcher's activities."

According to Coldwater, the issue stemmed from a failure to deploy fixes on time, something Microsoft has frequently faulted on its customers. He said that certain cloud security tools would have identified malicious assaults similar to the one predicted by the security firm and that logs would also indicate evidence of such activity. 

The research emphasized that security is a collective responsibility between cloud providers and clients. Cloud architectures, according to Zelivansky, are typically safe, Microsoft and other cloud providers can make improvements themselves rather than relying on customers to do so. 

He further added, cloud attacks by well-funded opponents such as sovereign governments, are a legitimate concern.