Alleged researchers have exploited a zero-day in Kraken crypto exchange to steal $3 million worth of cryptocurrency.

Kraken Chief Security Officer Nick Percoco revealed that alleged security researchers exploited a zero-day flaw to steal $3 million worth of cryptocurrency. The researchers are refusing to return the stolen funds.

Percoco revealed that a security researcher reported an “extremely critical” bug to the exchange on June 9. The researcher did not disclose technical details about the issues, they only explained that the flaw allowed anyone to arbitrary increase the balances in a wallet.

“Everyday we receive fake bug bounty reports from people claiming to be “security researchers”. This is not new to anyone who runs a bug bounty program. However, we treated this seriously and quickly assembled a cross functional team to dig into this issue.” Percoco explained.

The kraken security team discovered “an isolated bug” that allowed an attacker, under specific circumstances, to initiate a deposit onto the platform and receive funds in their account without fully completing the deposit.

The company pointed out that the client’s assets are not at risk, however, an attacker could effectively print assets in their Kraken account for a while.

The security team addressed the vulnerability within an hour. The vulnerability derived from a recent change in the user interface that would promptly credit client accounts before their assets cleared allowing clients to effectively trade crypto markets in real time.

“This UX change was not thoroughly tested against this specific attack vector.” continues the

After patching the vulnerability, the experts discovered that three accounts exploited the vulnerability within a few days. One of these accounts was verified by an individual claiming to be a security researcher.

Percoco added that the researcher disclosed the bug to two other individuals who used it to withdraw $3 million in stolen funds from their Kraken accounts.

The company requested the researchers to return the stolen funds, but they refused.

“This is not white-hat hacking, it is extortion!” said Percoco, who added that his company notified law enforcement.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, zero-day)

Google released Chrome 126 update that addresses a high-severity vulnerability demonstrated at the TyphoonPWN 2024 hacking competition.

Google has issued a Chrome 126 security update, addressing six vulnerabilities, including a flaw, tracked as CVE-2024-6100 which was demonstrated during the SSD Secure Disclosure’s TyphoonPWN 2024. TyphoonPWN is a live hacking competition held annually at TyphoonCon, an Offensive Security Conference in Seoul, South Korea.

The vulnerability is a high-severity type confusion issue in the V8 script engine that was reported by Seunghyun Lee (@0x10n) participating in SSD Secure Disclosure’s TyphoonPWN 2024 on 2024-06-04

Lee received a $20,000 bug bounty reward for reporting the issue.

Google also addressed the following issues:

• A high-severity inappropriate implementation issue, tracked as CVE-2024-6101, in WebAssembly. @ginggilBesel reported the flaw on 2024-05-31 and Google awarded him $7000.
• A high-severity out-of-bounds memory access in Dawn, tracked as CVE-2024-6102. wgslfuzz reported the flaw on 2024-05-07.
• A high-severity use after free in Dawn tracked as CVE-2024-6103: wgslfuzz reported the flaw on 2024-06-04

Google hasn’t shared technical details on the vulnerabilities, the good news is that the company is not aware of attacks in the wild exploiting the flaws addressed by the Chrome 126 security update.

Chrome 126 security update is now rolling out to users as version 126.0.6478.114 for Linux and as versions 126.0.6478.114/115 for Windows and macOS.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Google)

AMD announced an investigation after a threat actor attempted to sell data allegedly stolen from its systems.

AMD has launched an investigation after the threat actor IntelBroker announced they were selling sensitive data allegedly belonging to the company.

“We are aware of a cybercriminal organization claiming to be in possession of stolen AMD data,” the chip maker told media outlets. “We are working closely with law enforcement officials and a third-party hosting partner to investigate the claim and the significance of the data.”

Earlier this week IntelBroker announced on the BreachForums cybercrime forum that they were “selling the AMD.com data breach.”

The seller states that the files were stolen in June 2024.

The allegedly stolen data includes information on future products, datasheets, employee and customer databases, property files, firmware, source code, and financial documentation.

The seller claims compromised employee data includes first and last names, job functions, business phone numbers, email addresses, and status. 

It’s unclear if the data is authentic and which it the source.

IntelBroker recently made the headlines because he attempted to sell data from Europol and Zscaler.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, AMD)

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,”.

“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)

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:

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, VMware)