On Wednesday, CISA added CVE-2024-54085 to its list of vulnerabilities known to be exploited in the wild. The notice provided no further details.
In an email on Thursday, Eclypsium researchers said the scope of the exploits has the potential to be broad:
Attackers could chain multiple BMC exploits to implant malicious code directly into the BMC’s firmware, making their presence extremely difficult to detect and allowing them to survive OS reinstalls or even disk replacements.
By operating below the OS, attackers can evade endpoint protection, logging, and most traditional security tools.
With BMC access, attackers can remotely power on or off, reboot, or reimage the server, regardless of the primary operating system’s state.
Attackers can scrape credentials stored on the system, including those used for remote management, and use the BMC as a launchpad to move laterally within the network
BMCs often have access to system memory and network interfaces, enabling attackers to sniff sensitive data or exfiltrate information without detection
Attackers with BMC access can intentionally corrupt firmware, rendering servers unbootable and causing significant operational disruption
With no publicly known details of the ongoing attacks, it’s unclear which groups may be behind them. Eclypsium said the most likely culprits would be espionage groups working on behalf of the Chinese government. All five of the specific APT groups Eclypsium named have a history of exploiting firmware vulnerabilities or gaining persistent access to high-value targets.
Eclypsium said the line of vulnerable AMI MegaRAC devices uses an interface known as Redfish. Server makers known to use these products include AMD, Ampere Computing, ASRock, ARM, Fujitsu, Gigabyte, Huawei, Nvidia, Supermicro, and Qualcomm. Some, but not all, of these vendors have released patches for their wares.
Given the damage possible from exploitation of this vulnerability, admins should examine all BMCs in their fleets to ensure they aren’t vulnerable. With products from so many different server makers affected, admins should consult with their manufacturer when unsure if their networks are exposed.
A jury has awarded WhatsApp $167 million in punitive damages in a case the company brought against Israel-based NSO Group for exploiting a software vulnerability that hijacked the phones of thousands of users.
The verdict, reached Tuesday, comes as a major victory not just for Meta-owned WhatsApp but also for privacy- and security-rights advocates who have long criticized the practices of NSO and other exploit sellers. The jury also awarded WhatsApp $444 million in compensatory damages.
Clickless exploit
WhatsApp sued NSO in 2019 for an attack that targeted roughly 1,400 mobile phones belonging to attorneys, journalists, human-rights activists, political dissidents, diplomats, and senior foreign government officials. NSO, which works on behalf of governments and law enforcement authorities in various countries, exploited a critical WhatsApp vulnerability that allowed it to install NSO’s proprietary spyware Pegasus on iOS and Android devices. The clickless exploit worked by placing a call to a target’s app. A target did not have to answer the call to be infected.
“Today’s verdict in WhatsApp’s case is an important step forward for privacy and security as the first victory against the development and use of illegal spyware that threatens the safety and privacy of everyone,” WhatsApp said in a statement. “Today, the jury’s decision to force NSO, a notorious foreign spyware merchant, to pay damages is a critical deterrent to this malicious industry against their illegal acts aimed at American companies and the privacy and security of the people we serve.”
NSO created WhatsApp accounts in 2018 and used them a year later to initiate calls that exploited the critical vulnerability on phones, which, among others, included 100 members of “civil society” from 20 countries, according to an investigation research group Citizen Lab performed on behalf of WhatsApp. The calls passed through WhatsApp servers and injected malicious code into the memory of targeted devices. The targeted phones would then use WhatsApp servers to connect to malicious servers maintained by NSO.
A leak of 190,000 chat messages traded among members of the Black Basta ransomware group shows that it’s a highly structured and mostly efficient organization staffed by personnel with expertise in various specialties, including exploit development, infrastructure optimization, social engineering, and more.
The trove of records was first posted to file-sharing site MEGA. The messages, which were sent from September 2023 to September 2024, were later posted to Telegram in February 2025. ExploitWhispers, the online persona who took credit for the leak, also provided commentary and context for understanding the communications. The identity of the person or persons behind ExploitWhispers remains unknown. Last month’s leak coincided with the unexplained outage of the Black Basta site on the dark web, which has remained down ever since.
“We need to exploit as soon as possible”
Researchers from security firm Trustwave’s SpiderLabs pored through the messages, which were written in Russian, and published a brief blog summary and a more detailed review of the messages on Tuesday.
“The dataset sheds light on Black Basta’s internal workflows, decision-making processes, and team dynamics, offering an unfiltered perspective on how one of the most active ransomware groups operates behind the scenes, drawing parallels to the infamous Conti leaks,” the researchers wrote. They were referring to a separate leak of ransomware group Conti that exposed workers grumbling about low pay, long hours, and grievances about support from leaders of Russia in its invasion of Ukraine. “While the immediate impact of the leak remains uncertain, the exposure of Black Basta’s inner workings represents a rare opportunity for cybersecurity professionals to adapt and respond.”
Some of the TTPs—short for tactics, techniques, and procedures—Black Basta employed were directed at methods for social engineering employees working for prospective victims by posing as IT administrators attempting to troubleshoot problems or respond to fake breaches.
Thousands of sites running WordPress remain unpatched against a critical security flaw in a widely used plugin that was being actively exploited in attacks that allow for unauthenticated execution of malicious code, security researchers said.
The vulnerability, tracked as CVE-2024-11972, is found in Hunk Companion, a plugin that runs on 10,000 sites that use the WordPress content management system. The vulnerability, which carries a severity rating of 9.8 out of a possible 10, was patched earlier this week. At the time this post went live on Ars, figures provided on the Hunk Companion page indicated that less than 12 percent of users had installed the patch, meaning nearly 9,000 sites could be next to be targeted.
Significant, multifaceted threat
“This vulnerability represents a significant and multifaceted threat, targeting sites that use both a ThemeHunk theme and the Hunk Companion plugin,” Daniel Rodriguez, a researcher with WordPress security firm WP Scan, wrote. “With over 10,000 active installations, this exposed thousands of websites to anonymous, unauthenticated attacks capable of severely compromising their integrity.”
Rodriquez said WP Scan discovered the vulnerability while analyzing the compromise of a customer’s site. The firm found that the initial vector was CVE-2024-11972. The exploit allowed the hackers behind the attack to cause vulnerable sites to automatically navigate to wordpress.org and download WP Query Console, a plugin that hasn’t been updated in years.
Citing the Reddit comment, Beaumont took to Mastodon to explain: “People are quite openly posting what is happening on Reddit now, threat actors are registering rogue FortiGates into FortiManager with hostnames like ‘localhost’ and using them to get RCE.”
Beaumont wasn’t immediately available to elaborate. In the same thread, another user said that based on the brief description, it appears attackers are somehow stealing digital certificates authenticating a device to a customer network, loading it onto a FortiGate device they own, and then registering the device into the customer network.
The person continued:
From there, they can configure their way into your network or possibly take other admin actions (eg. possibly sync configs from trustworthy managed devices to their own?) It’s not super clear from these threads. The mitigation to prevent unknown serial numbers suggests that a speedbump to fast onboarding prevents even a cert-bearing(?) device from being included into the fortimanager.
Beaumont went on to say that based on evidence he’s seen, China-state hackers have “been hopping into internal networks using this one since earlier in the year, looks like.”
60,000 devices exposed
After this post went live on Ars, Beaumont published a post that said the vulnerability likely resides in the FortiGate to FortiManager protocol. FGFM is the language that allows Fortigate firewall devices to communicate with the manager over port 541. As Beaumont pointed out, the Shodan search engine shows more than 60,000 such connections exposed to the Internet.
Beaumont wrote:
There’s one requirement for an attacker: you need a valid certificate to connect. However, you can just take a certificate from a FortiGate box and reuse it. So, effectively, there’s no barrier to registering.
Once registered, there’s a vulnerability which allows remote code execution on the FortiManager itself via the rogue FortiGate connection.
From the FortiManager, you can then manage the legit downstream FortiGate firewalls, view config files, take credentials and alter configurations. Because MSPs — Managed Service Providers — often use FortiManager, you can use this to enter internal networks downstream.
Because of the way FGFM is designed — NAT traversal situations — it also means if you gain access to a managed FortiGate firewall you then can traverse up to the managing FortiManager device… and then back down to other firewalls and networks.
To make matters harder for FortiGate customers and defenders, the company’s support portal was returning connection errors at the time this post went live on Ars that prevented people from accessing the site.
The ability to remain installed and undetected makes Perfctl hard to fight.
Thousands of machines running Linux have been infected by a malware strain that’s notable for its stealth, the number of misconfigurations it can exploit, and the breadth of malicious activities it can perform, researchers reported Thursday.
The malware has been circulating since at least 2021. It gets installed by exploiting more than 20,000 common misconfigurations, a capability that may make millions of machines connected to the Internet potential targets, researchers from Aqua Security said. It can also exploit CVE-2023-33246, a vulnerability with a severity rating of 10 out of 10 that was patched last year in Apache RocketMQ, a messaging and streaming platform that’s found on many Linux machines.
Perfctl storm
The researchers are calling the malware Perfctl, the name of a malicious component that surreptitiously mines cryptocurrency. The unknown developers of the malware gave the process a name that combines the perf Linux monitoring tool and ctl, an abbreviation commonly used with command line tools. A signature characteristic of Perfctl is its use of process and file names that are identical or similar to those commonly found in Linux environments. The naming convention is one of the many ways the malware attempts to escape notice of infected users.
Perfctl further cloaks itself using a host of other tricks. One is that it installs many of its components as rootkits, a special class of malware that hides its presence from the operating system and administrative tools. Other stealth mechanisms include:
Stopping activities that are easy to detect when a new user logs in
Using a Unix socket over TOR for external communications
Deleting its installation binary after execution and running as a background service thereafter
Manipulating the Linux process pcap_loop through a technique known as hooking to prevent admin tools from recording the malicious traffic
Suppressing mesg errors to avoid any visible warnings during execution.
The malware is designed to ensure persistence, meaning the ability to remain on the infected machine after reboots or attempts to delete core components. Two such techniques are (1) modifying the ~/.profile script, which sets up the environment during user login so the malware loads ahead of legitimate workloads expected to run on the server and (2) copying itself from memory to multiple disk locations. The hooking of pcap_loop can also provide persistence by allowing malicious activities to continue even after primary payloads are detected and removed.
Besides using the machine resources to mine cryptocurrency, Perfctl also turns the machine into a profit-making proxy that paying customers use to relay their Internet traffic. Aqua Security researchers have also observed the malware serving as a backdoor to install other families of malware.
Assaf Morag, Aqua Security’s threat intelligence director, wrote in an email:
Perfctl malware stands out as a significant threat due to its design, which enables it to evade detection while maintaining persistence on infected systems. This combination poses a challenge for defenders and indeed the malware has been linked to a growing number of reports and discussions across various forums, highlighting the distress and frustration of users who find themselves infected.
Perfctl uses a rootkit and changes some of the system utilities to hide the activity of the cryptominer and proxy-jacking software. It blends seamlessly into its environment with seemingly legitimate names. Additionally, Perfctl’s architecture enables it to perform a range of malicious activities, from data exfiltration to the deployment of additional payloads. Its versatility means that it can be leveraged for various malicious purposes, making it particularly dangerous for organizations and individuals alike.
“The malware always manages to restart”
While Perfctl and some of the malware it installs are detected by some antivirus software, Aqua Security researchers were unable to find any research reports on the malware. They were, however, able to find a wealth of threads on developer-related sites that discussed infections consistent with it.
This Reddit comment posted to the CentOS subreddit is typical. An admin noticed that two servers were infected with a cryptocurrency hijacker with the names perfcc and perfctl. The admin wanted help investigating the cause.
“I only became aware of the malware because my monitoring setup alerted me to 100% CPU utilization,” the admin wrote in the April 2023 post. “However, the process would stop immediately when I logged in via SSH or console. As soon as I logged out, the malware would resume running within a few seconds or minutes.” The admin continued:
I have attempted to remove the malware by following the steps outlined in other forums, but to no avail. The malware always manages to restart once I log out. I have also searched the entire system for the string “perfcc” and found the files listed below. However, removing them did not resolve the issue. as it keep respawn on each time rebooted.
After exploiting a vulnerability or misconfiguration, the exploit code downloads the main payload from a server, which, in most cases, has been hacked by the attacker and converted into a channel for distributing the malware anonymously. An attack that targeted the researchers’ honeypot named the payload httpd. Once executed, the file copies itself from memory to a new location in the /tmp directory, runs it, and then terminates the original process and deletes the downloaded binary.
Once moved to the /tmp directory, the file executes under a different name, which mimics the name of a known Linux process. The file hosted on the honeypot was named sh. From there, the file establishes a local command-and-control process and attempts to gain root system rights by exploiting CVE-2021-4043, a privilege-escalation vulnerability that was patched in 2021 in Gpac, a widely used open source multimedia framework.
The malware goes on to copy itself from memory to a handful of other disk locations, once again using names that appear as routine system files. The malware then drops a rootkit, a host of popular Linux utilities that have been modified to serve as rootkits, and the miner. In some cases, the malware also installs software for “proxy-jacking,” the term for surreptitiously routing traffic through the infected machine so the true origin of the data isn’t revealed.
The researchers continued:
As part of its command-and-control operation, the malware opens a Unix socket, creates two directories under the /tmp directory, and stores data there that influences its operation. This data includes host events, locations of the copies of itself, process names, communication logs, tokens, and additional log information. Additionally, the malware uses environment variables to store data that further affects its execution and behavior.
All the binaries are packed, stripped, and encrypted, indicating significant efforts to bypass defense mechanisms and hinder reverse engineering attempts. The malware also uses advanced evasion techniques, such as suspending its activity when it detects a new user in the btmp or utmp files and terminating any competing malware to maintain control over the infected system.
The diagram below captures the attack flow:
Credit: Aqua Security
Credit: Aqua Security
The following image captures some of the names given to the malicious files that are installed:
Credit: Aqua Security
Credit: Aqua Security
By extrapolating data such as the number of Linux servers connected to the Internet across various services and applications, as tracked by services such as Shodan and Censys, the researchers estimate that the number of machines infected by Perfctl is measured in the thousands. They say that the pool of vulnerable machines—meaning those that have yet to install the patch for CVE-2023-33246 or contain a vulnerable misconfiguration—is in the millions. The researchers have yet to measure the amount of cryptocurrency the malicious miners have generated.
People who want to determine if their device has been targeted or infected by Perfctl should look for indicators of compromise included in Thursday’s post. They should also be on the lookout for unusual spikes in CPU usage or sudden system slowdowns, particularly if they occur during idle times. To prevent infections, it’s important that the patch for CVE-2023-33246 be installed and that the the misconfigurations identified by Aqua Security be fixed. Thursday’s report provides other steps for preventing infections.
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at @dangoodin on Mastodon. Contact him on Signal at DanArs.82.
Malicious hackers are exploiting a critical vulnerability in a widely used security camera to spread Mirai, a family of malware that wrangles infected Internet of Things devices into large networks for use in attacks that take down websites and other Internet-connected devices.
The attacks target the AVM1203, a surveillance device from Taiwan-based manufacturer AVTECH, network security provider Akamai said Wednesday. Unknown attackers have been exploiting a 5-year-old vulnerability since March. The zero-day vulnerability, tracked as CVE-2024-7029, is easy to exploit and allows attackers to execute malicious code. The AVM1203 is no longer sold or supported, so no update is available to fix the critical zero-day.
That time a ragtag army shook the Internet
Akamai said that the attackers are exploiting the vulnerability so they can install a variant of Mirai, which arrived in September 2016 when a botnet of infected devices took down cybersecurity news site Krebs on Security. Mirai contained functionality that allowed a ragtag army of compromised webcams, routers, and other types of IoT devices to wage distributed denial-of-service attacks of record-setting sizes. In the weeks that followed, the Mirai botnet delivered similar attacks on Internet service providers and other targets. One such attack, against dynamic domain name provider Dyn paralyzed vast swaths of the Internet.
Complicating attempts to contain Mirai, its creators released the malware to the public, a move that allowed virtually anyone to create their own botnets that delivered DDoSes of once-unimaginable size.
Kyle Lefton, a security researcher with Akamai’s Security Intelligence and Response Team, said in an email that it has observed the threat actor behind the attacks perform DDoS attacks against “various organizations,” which he didn’t name or describe further. So far, the team hasn’t seen any indication the threat actors are monitoring video feeds or using the infected cameras for other purposes.
Akamai detected the activity using a “honeypot” of devices that mimic the cameras on the open Internet to observe any attacks that target them. The technique doesn’t allow the researchers to measure the botnet’s size. The US Cybersecurity and Infrastructure Security Agency warned of the vulnerability earlier this month.
The technique, however, has allowed Akamai to capture the code used to compromise the devices. It targets a vulnerability that has been known since at least 2019 when exploit code became public. The zero-day resides in the “brightness argument in the ‘action=’ parameter” and allows for command injection, researchers wrote. The zero-day, discovered by Akamai researcher Aline Eliovich, wasn’t formally recognized until this month, with the publishing of CVE-2024-7029.
Wednesday’s post went on to say:
How does it work?
This vulnerability was originally discovered by examining our honeypot logs. Figure 1 shows the decoded URL for clarity. Decoded payload
Enlarge/ Fig. 1: Decoded payload body of the exploit attempts
Akamai
Fig. 1: Decoded payload body of the exploit attempts
The vulnerability lies in the brightness function within the file /cgi-bin/supervisor/Factory.cgi (Figure 2).
In the exploit examples we observed, essentially what happened is this: The exploit of this vulnerability allows an attacker to execute remote code on a target system.
Figure 3 is an example of a threat actor exploiting this flaw to download and run a JavaScript file to fetch and load their main malware payload. Similar to many other botnets, this one is also spreading a variant of Mirai malware to its targets.
Enlarge/ Fig. 3: Strings from the JavaScript downloader
Akamai
In this instance, the botnet is likely using the Corona Mirai variant, which has been referenced by other vendors as early as 2020 in relation to the COVID-19 virus.
Upon execution, the malware connects to a large number of hosts through Telnet on ports 23, 2323, and 37215. It also prints the string “Corona” to the console on an infected host (Figure 4).
Enlarge/ Fig. 4: Execution of malware showing output to console
Akamai
Static analysis of the strings in the malware samples shows targeting of the path /ctrlt/DeviceUpgrade_1 in an attempt to exploit Huawei devices affected by CVE-2017-17215. The samples have two hard-coded command and control IP addresses, one of which is part of the CVE-2017-17215 exploit code:
The botnet also targeted several other vulnerabilities including a Hadoop YARN RCE, CVE-2014-8361, and CVE-2017-17215. We have observed these vulnerabilities exploited in the wild several times, and they continue to be successful.
Given that this camera model is no longer supported, the best course of action for anyone using one is to replace it. As with all Internet-connected devices, IoT devices should never be accessible using the default credentials that shipped with them.
More than 1.5 million email servers are vulnerable to attacks that can deliver executable attachments to user accounts, security researchers said.
The servers run versions of the Exim mail transfer agent that are vulnerable to a critical vulnerability that came to light 10 days ago. Tracked as CVE-2024-39929 and carrying a severity rating of 9.1 out of 10, the vulnerability makes it trivial for threat actors to bypass protections that normally prevent the sending of attachments that install apps or execute code. Such protections are a first line of defense against malicious emails designed to install malware on end-user devices.
A serious security issue
“I can confirm this bug,” Exim project team member Heiko Schlittermann wrote on a bug-tracking site. “It looks like a serious security issue to me.”
Researchers at security firm Censys said Wednesday that of the more than 6.5 million public-facing SMTP email servers appearing in Internet scans, 4.8 million of them (roughly 74 percent) run Exim. More than 1.5 million of the Exim servers, or roughly 31 percent, are running a vulnerable version of the open-source mail app.
While there are no known reports of active exploitation of the vulnerability, it wouldn’t be surprising to see active targeting, given the ease of attacks and the large number of vulnerable servers. In 2020, one of the world’s most formidable hacking groups—the Kremlin-backed Sandworm—exploited a severe Exim vulnerability tracked as CVE-2019-10149, which allowed them to send emails that executed malicious code that ran with unfettered root system rights. The attacks began in August 2019, two months after the vulnerability came to light. They continued through at least May 2020.
CVE-2024-39929 stems from an error in the way Exim parses multiline headers as specified in RFC 2231. Threat actors can exploit it to bypass extension blocking and deliver executable attachments in emails sent to end users. The vulnerability exists in all Exim versions up to and including 4.97.1. A fix is available in the Release Candidate 3 of Exim 4.98.
Given the requirement that end users must click on an attached executable for the attack to work, this Exim vulnerability isn’t as serious as the one that was exploited starting in 2019. That said, social engineering people remains among the most effective attack methods. Admins should assign a high priority to updating to the latest version.
Researchers have warned of a critical vulnerability affecting the OpenSSH networking utility that can be exploited to give attackers complete control of Linux and Unix servers with no authentication required.
The vulnerability, tracked as CVE-2024-6387, allows unauthenticated remote code execution with root system rights on Linux systems that are based on glibc, an open source implementation of the C standard library. The vulnerability is the result of a code regression introduced in 2020 that reintroduced CVE-2006-5051, a vulnerability that was fixed in 2006. With thousands, if not millions, of vulnerable servers populating the Internet, this latest vulnerability could pose a significant risk.
Complete system takeover
“This vulnerability, if exploited, could lead to full system compromise where an attacker can execute arbitrary code with the highest privileges, resulting in a complete system takeover, installation of malware, data manipulation, and the creation of backdoors for persistent access,” wrote Bharat Jogi, the senior director of threat research at Qualys, the security firm that discovered it. “It could facilitate network propagation, allowing attackers to use a compromised system as a foothold to traverse and exploit other vulnerable systems within the organization.”
The risk is in part driven by the central role OpenSSH plays in virtually every internal network connected to the Internet. It provides a channel for administrators to connect to protected devices remotely or from one device to another inside the network. The ability for OpenSSH to support multiple strong encryption protocols, its integration into virtually all modern operating systems, and its location at the very perimeter of networks further drive its popularity.
Besides the ubiquity of vulnerable servers populating the Internet, CVE-2024-6387 also provides a potent means for executing malicious code stems with the highest privileges, with no authentication required. The flaw stems from faulty management of the signal handler, a component in glibc for responding to potentially serious events such as division-by-zero attempts. When a client device initiates a connection but doesn’t successfully authenticate itself within an allotted time (120 seconds by default), vulnerable OpenSSH systems call what’s known as a SIGALRM handler asynchronously. The flaw resides in sshd, the main OpenSSH engine. Qualys has named the vulnerability regreSSHion.
The severity of the threat posed by exploitation is significant, but various factors are likely to prevent it from being mass exploited, security experts said. For one, the attack can take as long as eight hours to complete and require as many as 10,000 authentication steps, Stan Kaminsky, a researcher at security firm Kaspersky, said. The delay results from a defense known as address space layout randomization, which changes the memory addresses where executable code is stored to thwart attempts to run malicious payloads.
Other limitations apply. Attackers must also know the specific OS running on each targeted server. So far, no one has found a way to exploit 64-bit systems since the number of available memory addresses is exponentially higher than those available for 32-bit systems. Further mitigating the chances of success, denial-of-service attacks that limit the number of connection requests coming into a vulnerable system will prevent exploitation attempts from succeeding.
All of those limitations will likely prevent CVE-2024-6387 from being mass exploited, researchers said, but there’s still the risk of targeted attacks that pepper a specific network of interest with authentication attempts over a matter of days until allowing code execution. To cover their tracks, attackers could spread requests through a large number of IP addresses in a fashion similar to password-spraying attacks. In this way, attackers could target a handful of vulnerable networks until one or more of the attempts succeeded.
The vulnerability affects the following:
OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109.
Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure.
The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.
Anyone running a vulnerable version should update as soon as practicable.
Ransomware criminals have quickly weaponized an easy-to-exploit vulnerability in the PHP programming language that executes malicious code on web servers, security researchers said.
As of Thursday, Internet scans performed by security firm Censys had detected 1,000 servers infected by a ransomware strain known as TellYouThePass, down from 1,800 detected on Monday. The servers, primarily located in China, no longer display their usual content; instead, many list the site’s file directory, which shows all files have been given a .locked extension, indicating they have been encrypted. An accompanying ransom note demands roughly $6,500 in exchange for the decryption key.
Enlarge/ The output of PHP servers infected by TellYouThePass ransomware.
The vulnerability, tracked as CVE-2024-4577 and carrying a severity rating of 9.8 out of 10, stems from errors in the way PHP converts Unicode characters into ASCII. A feature built into Windows known as Best Fit allows attackers to use a technique known as argument injection to convert user-supplied input into characters that pass malicious commands to the main PHP application. Exploits allow attackers to bypass CVE-2012-1823, a critical code execution vulnerability patched in PHP in 2012.
CVE-2024-4577 affects PHP only when it runs in a mode known as CGI, in which a web server parses HTTP requests and passes them to a PHP script for processing. Even when PHP isn’t set to CGI mode, however, the vulnerability may still be exploitable when PHP executables such as php.exe and php-cgi.exe are in directories that are accessible by the web server. This configuration is extremely rare, with the exception of the XAMPP platform, which uses it by default. An additional requirement appears to be that the Windows locale—used to personalize the OS to the local language of the user—must be set to either Chinese or Japanese.
The critical vulnerability was published on June 6, along with a security patch. Within 24 hours, threat actors were exploiting it to install TellYouThePass, researchers from security firm Imperva reported Monday. The exploits executed code that used the mshta.exe Windows binary to run an HTML application file hosted on an attacker-controlled server. Use of the binary indicated an approach known as living off the land, in which attackers use native OS functionalities and tools in an attempt to blend in with normal, non-malicious activity.
In a post published Friday, Censys researchers said that the exploitation by the TellYouThePass gang started on June 7 and mirrored past incidents that opportunistically mass scan the Internet for vulnerable systems following a high-profile vulnerability and indiscriminately targeting any accessible server. The vast majority of the infected servers have IP addresses geolocated to China, Taiwan, Hong Kong, or Japan, likely stemming from the fact that Chinese and Japanese locales are the only ones confirmed to be vulnerable, Censys researchers said in an email.
Since then, the number of infected sites—detected by observing the public-facing HTTP response serving an open directory listing showing the server’s filesystem, along with the distinctive file-naming convention of the ransom note—has fluctuated from a low of 670 on June 8 to a high of 1,800 on Monday.
Enlarge/ Image tracking day-to-day compromises of PHP servers and their geolocation.
Censys
Censys researchers said in an email that they’re not entirely sure what’s causing the changing numbers.
“From our perspective, many of the compromised hosts appear to remain online, but the port running the PHP-CGI or XAMPP service stops responding—hence the drop in detected infections,” they wrote. “Another point to consider is that there are currently no observed ransom payments to the only Bitcoin address listed in the ransom notes (source). Based on these facts, our intuition is that this is likely the result of those services being decommissioned or going offline in some other manner.”
XAMPP used in production, really?
The researchers went on to say that roughly half of the compromises observed show clear signs of running XAMPP, but that estimate is likely an undercount since not all services explicitly show what software they use.
“Given that XAMPP is vulnerable by default, it’s reasonable to guess that most of the infected systems are running XAMPP,” the researchers said. This Censys query lists the infections that are explicitly affecting the platform. The researchers aren’t aware of any specific platforms other than XAMPP that have been compromised.
The discovery of compromised XAMPP servers took Will Dormann, a senior vulnerability analyst at security firm Analygence, by surprise because XAMPP maintainers explicitly say their software isn’t suitable for production systems.
“People choosing to run not-for-production software have to deal with the consequences of that decision,” he wrote in an online interview.
While XAMPP is the only platform confirmed to be vulnerable, people running PHP on any Windows system should install the update as soon as possible. The Imperva post linked above provides IP addresses, file names, and file hashes that administrators can use to determine whether they have been targeted in the attacks.
Hackers working for the Chinese government gained access to more than 20,000 VPN appliances sold by Fortinet using a critical vulnerability that the company failed to disclose for two weeks after fixing it, Netherlands government officials said.
The vulnerability, tracked as CVE-2022-42475, is a heap-based buffer overflow that allows hackers to remotely execute malicious code. It carries a severity rating of 9.8 out of 10. A maker of network security software, Fortinet silently fixed the vulnerability on November 28, 2022, but failed to mention the threat until December 12 of that year, when the company said it became aware of an “instance where this vulnerability was exploited in the wild.” On January 11, 2023—more than six weeks after the vulnerability was fixed—Fortinet warned a threat actor was exploiting it to infect government and government-related organizations with advanced custom-made malware.
Enter CoatHanger
The Netherlands officials first reported in February that Chinese state hackers had exploited CVE-2022-42475 to install an advanced and stealthy backdoor tracked as CoatHanger on Fortigate appliances inside the Dutch Ministry of Defense. Once installed, the never-before-seen malware, specifically designed for the underlying FortiOS operating system, was able to permanently reside on devices even when rebooted or receiving a firmware update. CoatHanger could also escape traditional detection measures, the officials warned. The damage resulting from the breach was limited, however, because infections were contained inside a segment reserved for non-classified uses.
On Monday, officials with the Military Intelligence and Security Service (MIVD) and the General Intelligence and Security Service in the Netherlands said that to date, Chinese state hackers have used the critical vulnerability to infect more than 20,000 FortiGate VPN appliances sold by Fortinet. Targets include dozens of Western government agencies, international organizations, and companies within the defense industry.
“Since then, the MIVD has conducted further investigation and has shown that the Chinese cyber espionage campaign appears to be much more extensive than previously known,” Netherlands officials with the National Cyber Security Center wrote. “The NCSC therefore calls for extra attention to this campaign and the abuse of vulnerabilities in edge devices.”
Monday’s report said that exploitation of the vulnerability started two months before Fortinet first disclosed it and that 14,000 servers were backdoored during this zero-day period. The officials warned that the Chinese threat group likely still has access to many victims because CoatHanger is so hard to detect and remove.
Netherlands government officials wrote in Monday’s report:
Since the publication in February, the MIVD has continued to investigate the broader Chinese cyber espionage campaign. This revealed that the state actor gained access to at least 20,000 FortiGate systems worldwide within a few months in both 2022 and 2023 through the vulnerability with the identifier CVE-2022-42475 . Furthermore, research shows that the state actor behind this campaign was already aware of this vulnerability in FortiGate systems at least two months before Fortinet announced the vulnerability. During this so-called ‘zero-day’ period, the actor alone infected 14,000 devices. Targets include dozens of (Western) governments, international organizations and a large number of companies within the defense industry.
The state actor installed malware at relevant targets at a later date. This gave the state actor permanent access to the systems. Even if a victim installs security updates from FortiGate, the state actor continues to have this access.
It is not known how many victims actually have malware installed. The Dutch intelligence services and the NCSC consider it likely that the state actor could potentially expand its access to hundreds of victims worldwide and carry out additional actions such as stealing data.
Even with the technical report on the COATHANGER malware, infections from the actor are difficult to identify and remove. The NCSC and the Dutch intelligence services therefore state that it is likely that the state actor still has access to systems of a significant number of victims.
Fortinet’s failure to timely disclose is particularly acute given the severity of the vulnerability. Disclosures are crucial because they help users prioritize the installation of patches. When a new version fixes minor bugs, many organizations often wait to install it. When it fixes a vulnerability with a 9.8 severity rating, they’re much more likely to expedite the update process. Given the vulnerability was being exploited even before Fortinet fixed it, the disclosure likely wouldn’t have prevented all of the infections, but it stands to reason it could have stopped some.
Fortinet officials have never explained why they didn’t disclose the critical vulnerability when it was fixed. They have also declined to disclose what the company policy is for the disclosure of security vulnerabilities. Company representatives didn’t immediately respond to an email seeking comment for this post.
A maximum severity vulnerability that allows hackers to hijack GitLab accounts with no user interaction required is now under active exploitation, federal government officials warned as data showed that thousands of users had yet to install a patch released in January.
A change GitLab implemented in May 2023 made it possible for users to initiate password changes through links sent to secondary email addresses. The move was designed to permit resets when users didn’t have access to the email address used to establish the account. In January, GitLab disclosed that the feature allowed attackers to send reset emails to accounts they controlled and from there click on the embedded link and take over the account.
While exploits require no user interaction, hijackings work only against accounts that aren’t configured to use multifactor authentication. Even with MFA, accounts remained vulnerable to password resets, but the attackers ultimately are unable to access the account, allowing the rightful owner to change the reset password. The vulnerability, tracked as CVE-2023-7028, carries a severity rating of 10 out of 10.
On Wednesday, the US Cybersecurity and Infrastructure Security Agency said it is aware of “evidence of active exploitation” and added the vulnerability to its list of known exploited vulnerabilities. CISA provided no details about the in-the-wild attacks. A GitLab representative declined to provide specifics about the active exploitation of the vulnerability.
The vulnerability, classified as an improper access control flaw, could pose a grave threat. GitLab software typically has access to multiple development environments belonging to users. With the ability to access them and surreptitiously introduce changes, attackers could sabotage projects or plant backdoors that could infect anyone using software built in the compromised environment. An example of a similar supply chain attack is the one that hit SolarWinds in 2020 and pushed malware to more than 18,000 of its customers, 100 of whom received follow-on hacks. Other recent examples of supply chain attacks are here, here, and here.
These sorts of attacks are powerful. By hacking a single, carefully selected target, attackers gain the means to infect thousands of downstream users, often without requiring them to take any action at all.
According to Internet scans performed by security organization Shadowserver, more than 2,100 IP addresses showed they were hosting one or more vulnerable GitLab instances.
Shadowserver
The biggest concentration of IP addresses was in India, followed by the US, Indonesia, Algeria, and Thailand.
Shadowserver
The number of IP addresses showing vulnerable instances has fallen over time. Shadowserver shows that there were more than 5,300 addresses on January 22, one week after GitLab issued the patch.
Shadowserver
The vulnerability is classed as an improper access control flaw.
CISA has ordered all civilian federal agencies that have yet to patch the vulnerability to do so immediately. The agency made no mention of MFA, but any GitLab users who haven’t already done so should enable it, ideally with a form that complies with the FIDO industry standard.
GitLab users should also remember that patching does nothing to secure systems that have already been breached through exploits. GitLab has published incident response guidance here.
