Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Docker Engine API. Show all posts

'Leaky Vessels' Cloud Flaws Enable Container Escapes Worldwide

 

Researchers discovered a collection of four vulnerabilities in container engine components dubbed "Leaky Vessels," three of which allow the perpetrators to escape out of containers and perform malicious operations on the host system.

One of the vulnerabilities, CVE-2024-21626, affects runC, a lightweight container runtime for Docker and other container environments. It is the most critical of the four vulnerabilities, with a severity score of 8.6.  According to Rory McNamara, a staff security researcher at Snyk (which identified the flaws and reported them to Docker), the runC bug allows container escape during both build and runtime. 

In worst-case scenarios, a hacker who acquires unauthorised access to an underlying host operating system may be able to access anything else running on the same host, including critical credentials that allow the adversary to launch new attacks.

"Since this vulnerability affects anybody using containers to build applications — essentially every cloud-native developer worldwide — unchecked access could potentially compromise entire Docker or Kubernetes host systems," McNamara stated. 

The other three flaws impact Docker's default container image building toolkit, BuildKit. One of these (CVE-2024-23651) is a race condition affecting how cache levels are installed during runtime. Another vulnerability (CVE-2024-23653) impacts a security model in BuildKit's remote function call protocol, while the third (CVE-2024-23652) is a file deletion flaw in BuildKit.

In a blog post published on January 31, the security vendor urged businesses to "check for updates from any vendors providing their container runtime environments, including Docker, Kubernetes vendors, cloud container services, and open source communities."

Snyk pointed out the widespread use of the impacted container image components and build tools as a reason for businesses to upgrade to patched versions as soon as their providers publish them. 

Two of the Docker BuildKit vulnerabilities (CVE-2024-23651 and CVE-2024-23653) are build-time escapes. "The final Docker bug (CVE-2024-23652) is an arbitrary host file delete, meaning that it's not a traditional container escape," McNamara said. 

A rising concern 

Container vulnerabilities are becoming a growing worry for businesses. A Sysdig study published last year revealed that 87% of container images in production contain at least one high or critical severity vulnerability. 

The company attributed the high percentage of flaws to organisations' hurry to implement cloud apps without prioritising security concerns. Rezilion's 2023 research discovered hundreds of Docker container images with vulnerabilities that typical vulnerability detection and software composition analysis technologies could not detect. 

Over the last year, the trend has shifted perceptions of container security. According to a D-Zone survey, only 51% of respondents believe containerisation makes their applications more safe, down from 69% in 2021. 44% claimed containerisation made their application environment less safe, compared to 7% in 2021.

Malware Targets Weblog Servers And Dockers APIs For Cryptomining

Malicious malware known as Kinsing is using both recently discovered and legacy vulnerabilities in Oracle WebLogic Server to boost cryptocurrency mining malware. 
  
It was discovered by Trend Micro, that a financially-motivated cyber attack group behind the malware was making use of the vulnerability to run Python scripts that could disable Operating System (OS) security features such as Security-Enahnced Linux (SELinux), and many more. 
 
Kinsing malware has a history of acquiring vulnerable servers to co-opt into botnet devices such as Redis, SaltStack, Log4Shell, Spring4Shell, and the Atlassian Confluence vulnerability (CVE-2022-26134). The malware has also reportedly been involved in campaign container environments via misconfigured open Docker Daemon API ports instigating crypto mining and spreading the malware to other containers am host devices. 
 
In the latest wave of attacks, the malicious actor weaponized a two-year-old Remote Code Execution (RCE) bug, dubbed CVE-2020-14882 (CVSS score 9.8), against unpatched vulnerabilities to seize control of the servers and cause harm to the victims through malicious payloads. 
 
The exploitation of the bug further involved deploying a shell script responsible for various actions, such as removing the var/log/syslog/systemlog, disabling security functions and cloud service agents from conglomerates like Alibaba and Tencent – killing competing crypto mining processes.  
 
It is then followed by the shell script downloading the Kinsing malware from a remote server, along with taking steps to ensure persistence through a cron job. 
 
“The successful exploitation of this vulnerability can lead to RCE, which can allow attackers to perform plethora of malicious activities on the affected systems” Trend Micro said. “This can range from malware execution [...] to theft of critical data, and even complete control of a compromised machine.”
 
TeamTNT malwares makes comeback
 
Researchers at Aqua Security, a cloud-native security company, have linked three new attacks to another “vibrant” cryptojacking group called "TeamTNT", which eventually stopped functioning in November 2021.  
 
“TeamTNT has been scanning for microconfigured Docker Daemon and deploying alpine, a vanilla container image, with a command line to download a shell script (k.sh) to C2 server”, stated Aqua Security researcher Assaf Morag. 

The attack chain appears to be designed to crack SECP256K1 encryption, which if successful could give the malicious actor the ability to compute the keys for each cryptocurrency wallet. Thus, using high but illegal processing power of its targets to run the ECDLP solver and acquire the key. The other two attacks carried out by the threat group involve exploiting exposed Redis servers and misconfigured Docker API to provide cryptominers and Tsunami binaries. 
 
The targeting of Docker REST APIs by TeamTNTs has been well-documented over the past years. But in an operational security blunder observed by Trend Micro, credentials connected with two of the attacker-controlled DockerHub accounts have been uncovered. 

The accounts namely 'alpineos' and 'sandeep078' are said to have been used to distribute numerous malicious payloads like rootkits, Kubernetes exploits kits, credential stealers, XMTig Monero miners, and even the Kingsing malware. 
 
“The account alpineos was used in exploitation attempts on out honeypots three times, from mid-September to early October 2021, and we tracked the deployments’ IP addresses to their location in Germany,” stated Nitesh Surana, a researcher at Trend Micro. 
 
As estimated by Trends Micro, alpineos image has been downloaded more than 150,000 times. This further notified Docker about these accounts. 
 
The cybersecurity platform recommends organizations configure the exposed RESR API with TLS to steer clear of the adversary-in-the-middle (AiTM) attacks, along with using credential stores and helpers to host user credentials.

Exposed Docker Apis Used By Attackers In Creation Of New Containers That Perform Cryptojacking


Earlier this year it was revealed that attackers are now utilizing insecure Docker And Kubernetes systems in order to redistribute containers that have been used to mine coins. These containers are packages that include an application and all of the dependencies that are needed to run it. The packages are then redistributed as containers to Docker or Kubernetes structures accordingly.

Even Trend Micro lately detected an attacker scanning explicitly for insecure and exposed Docker Engine APIs and its utilization to deploy containers that download and execute a coin miner.
Docker containers are redistributed on a rostrum referred to as the Docker Engine, wherein they may run within the background together with different containers deployed to the system. 

If Docker Engine isn't accurately safeguarded, attackers can remotely make use of the Docker Engine API to redistribute the containers in their very own advent and start them at the insecure system.
Container Creation

When the container is deployed and stimulated, it releases an auto.sh script that further downloads a Monero miner and configures it to launch instinctively. The script even downloads the port scanning software, in an effort to test for the various vulnerable Docker Engine instances on port 2375 and 2376 and additionally try to spread to them.

Scan all networks seen from the host, with a scan rate of 50,000 packets per second, for open port 2375 and 2376; the result is saved in local.txt (anonymized/defanged):
masscan “$@” -p2375,2376 –rate=50000 -oG local.txt;
Conduct lateral movement by infecting or abusing more hosts found in previous reconnaissance:
sudo sed -i ‘s/^Host: \([0-9.]*\).*Ports: \([0-9]*\).*$/\1:\2/g’ local.txt;
sudo sh test3.sh local.txt;


With this method, a whole lot of Docker Engine containers can be gathered that mine coins for the attacker.

Although Docker Engine API abuse isn't new, but it continues to be a hassle due to the fact that the administrators don't legitimately secure their systems. To keep attackers from abusing the insecure Docker Engine implementations, Trend Micro proposes that the administrators  make use of the following security measures:


  • Harden the security posture. The Centre for Internet Security (CIS) has a reference that can help system administrators and security teams establish a benchmark to secure their Docker engine.     
  • Ensure that container images are authenticated, signed, and from a trusted registry (i.e., Docker Trusted Registry). Employing automated image scanning tools helps improve development cycles.  
  • Enforce the principle of least privilege. For instance, restrict access to the daemon and encrypt the communication protocols it uses to connect to the network. Docker has guidelines on how to protect the daemon socket.
  •   Properly configure how much resources containers are allowed to use (control groups and namespaces).
  • Enable Docker’s built-in security features to help defend against threats. Docker has several guidelines on how to securely configure Docker-based applications