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.
Kremlin-backed hackers have been exploiting a critical Microsoft vulnerability for four years in attacks that targeted a vast array of organizations with a previously undocumented tool, the software maker disclosed Monday.
When Microsoft patched the vulnerability in October 2022—at least two years after it came under attack by the Russian hackers—the company made no mention that it was under active exploitation. As of publication, the company’s advisory still made no mention of the in-the-wild targeting. Windows users frequently prioritize the installation of patches based on whether a vulnerability is likely to be exploited in real-world attacks.
Exploiting CVE-2022-38028, as the vulnerability is tracked, allows attackers to gain system privileges, the highest available in Windows, when combined with a separate exploit. Exploiting the flaw, which carries a 7.8 severity rating out of a possible 10, requires low existing privileges and little complexity. It resides in the Windows print spooler, a printer-management component that has harbored previous critical zero-days. Microsoft said at the time that it learned of the vulnerability from the US National Security Agency.
On Monday, Microsoft revealed that a hacking group tracked under the name Forest Blizzard has been exploiting CVE-2022-38028 since at least June 2020—and possibly as early as April 2019. The threat group—which is also tracked under names including APT28, Sednit, Sofacy, GRU Unit 26165, and Fancy Bear—has been linked by the US and the UK governments to Unit 26165 of the Main Intelligence Directorate, a Russian military intelligence arm better known as the GRU. Forest Blizzard focuses on intelligence gathering through the hacking of a wide array of organizations, mainly in the US, Europe, and the Middle East.
Since as early as April 2019, Forest Blizzard has been exploiting CVE-2022-38028 in attacks that, once system privileges are acquired, use a previously undocumented tool that Microsoft calls GooseEgg. The post-exploitation malware elevates privileges within a compromised system and goes on to provide a simple interface for installing additional pieces of malware that also run with system privileges. This additional malware, which includes credential stealers and tools for moving laterally through a compromised network, can be customized for each target.
“While a simple launcher application, GooseEgg is capable of spawning other applications specified at the command line with elevated permissions, allowing threat actors to support any follow-on objectives such as remote code execution, installing a backdoor, and moving laterally through compromised networks,” Microsoft officials wrote.
GooseEgg is typically installed using a simple batch script, which is executed following the successful exploitation of CVE-2022-38028 or another vulnerability, such as CVE-2023-23397, which Monday’s advisory said has also been exploited by Forest Blizzard. The script is responsible for installing the GooseEgg binary, often named justice.exe or DefragmentSrv.exe, then ensuring that they run each time the infected machine is rebooted.
Highly capable hackers are rooting multiple corporate networks by exploiting a maximum-severity zero-day vulnerability in a firewall product from Palo Alto Networks, researchers said Friday.
The vulnerability, which has been under active exploitation for at least two weeks now, allows the hackers with no authentication to execute malicious code with root privileges, the highest possible level of system access, researchers said. The extent of the compromise, along with the ease of exploitation, has earned the CVE-2024-3400 vulnerability the maximum severity rating of 10.0. The ongoing attacks are the latest in a rash of attacks aimed at firewalls, VPNs, and file-transfer appliances, which are popular targets because of their wealth of vulnerabilities and direct pipeline into the most sensitive parts of a network.
“Highly capable” UTA0218 likely to be joined by others
The zero-day is present in PAN-OS 10.2, PAN-OS 11.0, and/or PAN-OS 11.1 firewalls when they are configured to use both the GlobalProtect gateway and device telemetry. Palo Alto Networks has yet to patch the vulnerability but is urging affected customers to follow the workaround and mitigation guidance provided here. The advice includes enabling Threat ID 95187 for those with subscriptions to the company’s Threat Prevention service and ensuring vulnerability protection has been applied to their GlobalProtect interface. When that’s not possible, customers should temporarily disable telemetry until a patch is available.
Volexity, the security firm that discovered the zero-day attacks, said that it’s currently unable to tie the attackers to any previously known groups. However, based on the resources required and the organizations targeted, they are “highly capable” and likely backed by a nation-state. So far, only a single threat group—which Volexity tracks as UTA0218—is known to be leveraging the vulnerability in limited attacks. The company warned that as new groups learn of the vulnerability, CVE-2024-3400, is likely to come under mass exploitation, just as recent zero-days affecting products from the likes of Ivanti, Atlassian, Citrix, and Progress have in recent months.
“As with previous public disclosures of vulnerabilities in these kinds of devices, Volexity assesses that it is likely a spike in exploitation will be observed over the next few days by UTA0218 and potentially other threat actors who may develop exploits for this vulnerability,” company researchers wrote Friday. “This spike in activity will be driven by the urgency of this window of access closing due to mitigations and patches being deployed. It is therefore imperative that organizations act quickly to deploy recommended mitigations and perform compromise reviews of their devices to check whether further internal investigation of their networks is required.”
The earliest attacks Volexity has seen took place on March 26 in what company researchers suspect was UTA0218 testing the vulnerability by placing zero-byte files on firewall devices to validate exploitability. On April 7, the researchers observed the group trying unsuccessfully to install a backdoor on a customer’s firewall. Three days later, the group’s attacks were successfully deploying malicious payloads. Since then, the threat group has deployed custom, never-before-seen post-exploitation malware. The backdoor, which is written in the Python language, allows the attackers to use specially crafted network requests to execute additional commands on hacked devices.
Hackers are actively exploiting a pair of recently discovered vulnerabilities to remotely commandeer network-attached storage devices manufactured by D-Link, researchers said Monday.
Roughly 92,000 devices are vulnerable to the remote takeover exploits, which can be remotely transmitted by sending malicious commands through simple HTTP traffic. The vulnerability came to light two weeks ago. The researcher said they were making the threat public because D-Link said it had no plans to patch the vulnerabilities, which are present only in end-of-life devices, meaning they are no longer supported by the manufacturer.
An ideal recipe
On Monday, researchers said their sensors began detecting active attempts to exploit the vulnerabilities starting over the weekend. Greynoise, one of the organizations reporting the in-the-wild exploitation, said in an email that the activity began around 02: 17 UTC on Sunday. The attacks attempted to download and install one of several pieces of malware on vulnerable devices depending on their specific hardware profile. One such piece of malware is flagged under various names by 40 endpoint protection services.
Security organization Shadowserver has also reported seeing scanning or exploits from multiple IP addresses but didn’t provide additional details.
The vulnerability pair, found in the nas_sharing.cgi programming interface of the vulnerable devices, provide an ideal recipe for remote takeover. The first, tracked as CVE-2024-3272 and carrying a severity rating of 9.8 out of 10, is a backdoor account enabled by credentials hardcoded into the firmware. The second is a command-injection flaw tracked as CVE-2024-3273 and has a severity rating of 7.3. It can be remotely activated with a simple HTTP GET request.
Netsecfish, the researcher who disclosed the vulnerabilities, demonstrated how a hacker could remotely commandeer vulnerable devices by sending a simple set of HTTP requests to them. The code looks like this:
GET /cgi-bin/nas_sharing.cgiuser=messagebus&passwd=&cmd=15&system=
In the exploit example below, the text inside the first red rectangle contains the hardcoded credentials—username messagebus and an empty password field—while the next rectangle contains a malicious command string that has been base64 encoded.
netsecfish
“Successful exploitation of this vulnerability could allow an attacker to execute arbitrary commands on the system, potentially leading to unauthorized access to sensitive information, modification of system configurations, or denial of service conditions,” netsecfish wrote.
Last week, D-Link published an advisory. D-Link confirmed the list of affected devices:
The best defense against these attacks and others like them is to replace hardware once it reaches end of life. Barring that, users of EoL devices should at least ensure they’re running the most recent firmware. D-Link provides this dedicated support page for legacy devices for owners to locate the latest available firmware. Another effective protection is to disable UPnP and connections from remote Internet addresses unless they’re absolutely necessary and configured correctly.
