Normal view

There are new articles available, click to refresh the page.
Today — 19 June 2024Security Affairs

Cryptojacking campaign targets exposed Docker APIs

19 June 2024 at 07:31

A malware campaign targets publicly exposed Docker API endpoints to deliver cryptocurrency miners and other payloads.

Researchers at Datadog uncovered a new cryptojacking campaign linked to the attackers behind Spinning YARN campaign.

The threat actors target publicly exposed and unsecured Docker API endpoints for initial access.

The attack begins with the threat actor scanning the internet to find hosts with Docker’s default port 2375 open. After locating a valid host, they perform Docker reconnaissance by querying the Docker host’s version using the docker version command. Following this confirmation, the attacker starts the exploitation phase by attempting to create an Alpine Linux container and using Docker’s Binds parameter to map the host’s root directory (/) to a directory within the container (/mnt). Below is the command snippet used in the campaign:

"Image": "alpine",
"HostConfig": {
  "Binds": ["/:/mnt"]
}

If this step is successful, the attacker gains access to the Docker host’s underlying filesystem through the /mnt directory inside the container, allowing them to escalate their privileges.

In addition to defining the container image and host configuration parameters, the attacker executes a shell command within the container itself to set the root of subsequent processes.

The attackers were observed deploying multiple payloads, including a remote access tool (chkstart) that downloads and executes additional malicious payloads and a tool to perform lateral movement (exeremo) used to propagate the malware via SSH.

The threat actors used a a shell script named “vurl” to retrieve the malicious payloads from a server under their control. The script includes another shell script called “b.sh” that, in turn, packs a Base64-encoded binary named “vurl” and is also responsible for fetching and launching a third shell script known as “ar.sh” (or “ai.sh”).

“After the attacker gains initial access and achieves execution via cron, the next stage of the campaign is to fetch and execute a new shell script—b.sh. This script contains a base64-encoded tar archive of a new binary named vurl. The script decodes and extracts this binary to /usr/bin/vurl, overwriting the existing shell script version, before fetching and executing one of two shell scripts—ar.sh or ai.sh.” reads the report published by the researchers.

The attackers use an unusual persistence mechanism by modifying existing systemd services and using the ExecStartPost configuration option to execute malicious commands.

The shell script “ar.sh” is used for multiple purposes including setting up a working directory, installing tools to scan the internet for vulnerable hosts, remove existing cron entries, weaken the system by disabling firewalls, clearing shell history, and preventing new lines from being added to the history file.

The script is ultimately used to fetch the next-stage payload “chkstart.”

Attackers used Golang binary, such as vurl, to set up a remote access and download additional tools from a remote server. The experts observed attackers downloading “m.tar,” and an XMRig miner called “top,”.

Docker malware

“This update to the Spinning YARN campaign shows a willingness to continue attacking misconfigured Docker hosts for initial access. The threat actor behind this campaign continues to iterate on deployed payloads by porting functionality to Go, which could indicate an attempt to hinder the analysis process, or point to experimentation with multi-architecture builds.” concludes the report.

“Although the likely objective of this campaign is to deploy an XMRig miner to compromised hosts, the attackers also ensured that they maintain access to victim machines via SSH. Maintaining remote code execution to victim hosts could mean that attackers can leverage their access for additional objectives”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Docker)

Yesterday — 18 June 2024Security Affairs

VMware fixed RCE and privilege escalation bugs in vCenter Server

18 June 2024 at 17:23

VMware addressed vCenter Server vulnerabilities that can allow remote code execution or privilege escalation.

VMware addressed multiple vCenter Server vulnerabilities that remote attackers can exploit to achieve remote code execution or privilege escalation.

vCenter Server is a centralized management platform developed by VMware for managing virtualized environments.

The vCenter Server contains multiple heap-overflow flaws, tracked as CVE-2024-37079, CVE-2024-37080 (maximum CVSSv3 base score 9.8), in the implementation of the DCERPC protocol.

A malicious actor with network access to vCenter Server may trigger these vulnerabilities by sending a specially crafted network packet potentially leading to remote code execution.” reads the advisory published by the company.

Customers are recommended to install the released security patches, no workarounds are available.

The vulnerabilities were reported by Hao Zheng (@zhz) and Zibo Li (@zbleet) from TianGong Team of Legendsec at Qi’anxin Group.

VMware also addressed multiple local privilege escalation vulnerabilities, tracked as CVE-2024-37081 (maximum CVSSv3 base score of 7.8), in the vCenter Server. 

“The vCenter Server contains multiple local privilege escalation vulnerabilities due to misconfiguration of sudo.” reads the advisory. “An authenticated local user with non-administrative privileges may exploit these issues to elevate privileges to root on vCenter Server Appliance.”

The issue was reported by Matei “Mal” Badanoiu from Deloitte Romania

VMware confirmed that it is not aware of attacks in the wild exploiting these issues.

The following table reports impacted products and fixed versions:

VMware ProductVersionRunning OnCVECVSSv3SeverityFixed VersionWorkaroundsAdditional Documentation
vCenter Server 8.0AnyCVE-2024-37079, CVE-2024-37080, CVE-2024-370819.89.87.8Critical8.0 U2dNoneFAQ
vCenter Server 8.0AnyCVE-2024-37079, CVE-2024-370809.89.8Critical8.0 U1eNoneFAQ
vCenter Server7.0AnyCVE-2024-37079, CVE-2024-37080, CVE-2024-370819.89.87.8Critical7.0 U3rNoneFAQ

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, VMware)

❌
❌