Hardware manufacturer Asus has released updates patching multiple critical vulnerabilities that allow hackers to remotely take control of a range of router models with no authentication or interaction required of end users.
The most critical vulnerability, tracked as CVE-2024-3080 is an authentication bypass flaw that can allow remote attackers to log into a device without authentication. The vulnerability, according to the Taiwan Computer Emergency Response Team / Coordination Center (TWCERT/CC), carries a severity rating of 9.8 out of 10. Asus said the vulnerability affects the following routers:
A favorite haven for hackers
A second vulnerability tracked as CVE-2024-3079 affects the same router models. It stems from a buffer overflow flaw and allows remote hackers who have already obtained administrative access to an affected router to execute commands.
TWCERT/CC is warning of a third vulnerability affecting various Asus router models. It’s tracked as CVE-2024-3912 and can allow remote hackers to execute commands with no user authentication required. The vulnerability, carrying a severity rating of 9.8, affects:
Security patches, which have been available since January, are available for those models at the links provided in the table above. CVE-2024-3912 also affects Asus router models that are no longer supported by the manufacturer. Those models include:
DSL-N10_C1
DSL-N10_D1
DSL-N10P_C1
DSL-N12E_C1
DSL-N16P
DSL-N16U
DSL-AC52
DSL-AC55
TWCERT/CC advises owners of these devices to replace them.
Asus has advised all router owners to regularly check their devices to ensure they’re running the latest available firmware. The company also recommended users set a separate password from the wireless network and router-administration page. Additionally, passwords should be strong, meaning 11 or more characters that are unique and randomly generated. Asus also recommended users disable any services that can be reached from the Internet, including remote access from the WAN, port forwarding, DDNS, VPN server, DMZ, and port trigger. The company provided FAQs here and here.
There are no known reports of any of the vulnerabilities being actively exploited in the wild. That said, routers have become a favorite haven for hackers, who often use them to hide the origins of their attacks. In recent months, both nation-state espionage spies and financially motivated threat actors have been found camping out in routers, sometimes simultaneously. Hackers backed by the Russian and Chinese governments regularly wage attacks on critical infrastructure from routers that are connected to IP addresses with reputations for trustworthiness. Most of the hijackings are made possible by exploiting unpatched vulnerabilities or weak passwords.
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 critical vulnerability in the PHP programming language can be trivially exploited to execute malicious code on Windows devices, security researchers warned as they urged those affected to take action before the weekend starts.
Within 24 hours of the vulnerability and accompanying patch being published, researchers from the nonprofit security organization Shadowserver reported Internet scans designed to identify servers that are susceptible to attacks. That—combined with (1) the ease of exploitation, (2) the availability of proof-of-concept attack code, (3) the severity of remotely executing code on vulnerable machines, and (4) the widely used XAMPP platform being vulnerable by default—has prompted security practitioners to urge admins check to see if their PHP servers are affected before starting the weekend.
When “Best Fit” isn’t
“A nasty bug with a very simple exploit—perfect for a Friday afternoon,” researchers with security firm WatchTowr wrote.
CVE-2024-4577, as the vulnerability is tracked, 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 pass user-supplied input into commands executed by an application, in this case, PHP. Exploits allow attackers to bypass CVE-2012-1823, a critical code execution vulnerability patched in PHP in 2012.
“While implementing PHP, the team did not notice the Best-Fit feature of encoding conversion within the Windows operating system,” researchers with Devcore, the security firm that discovered CVE-2024-4577, wrote. “This oversight allows unauthenticated attackers to bypass the previous protection of CVE-2012-1823 by specific character sequences. Arbitrary code can be executed on remote PHP servers through the argument injection attack.”
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 set by default in XAMPP for Windows, making the platform vulnerable unless it has been modified.
One example, WatchTowr noted, occurs when queries are parsed and sent through a command line. The result: a harmless request such as http://host/cgi.php?foo=bar could be converted into php.exe cgi.php foo=bar, a command that would be executed by the main PHP engine.
No escape
Like many other languages, PHP converts certain types of user input to prevent it from being interpreted as a command for execution. This is a process known as escaping. For example, in HTML, the < and > characters are often escaped by converting them into their unicode hex value equivalents < and > to prevent them from being interpreted as HTML tags by a browser.
The WatchTowr researchers demonstrate how Best Fit fails to escape characters such as a soft hyphen (with unicode value 0xAD) and instead converts it to an unescaped regular hyphen (0x2D), a character that’s instrumental in many code syntaxes.
The researchers went on to explain:
It turns out that, as part of unicode processing, PHP will apply what’s known as a ‘best fit’ mapping, and helpfully assume that, when the user entered a soft hyphen, they actually intended to type a real hyphen, and interpret it as such. Herein lies our vulnerability—if we supply a CGI handler with a soft hyphen (0xAD), the CGI handler won’t feel the need to escape it, and will pass it to PHP. PHP, however, will interpret it as if it were a real hyphen, which allows an attacker to sneak extra command line arguments, which begin with hyphens, into the PHP process.
This is remarkably similar to an older PHP bug (when in CGI mode), CVE-2012-1823, and so we can borrow some exploitation techniques developed for this older bug and adapt them to work with our new bug. A helpful writeup advises that, to translate our injection into RCE, we should aim to inject the following arguments:
This will accept input from our HTTP request body, and process it using PHP. Straightforward enough – let’s try a version of this equipped with our 0xAD ‘soft hyphen’ instead of the usual hyphen. Maybe it’s enough to slip through the escaping?
Oh joy—we’re rewarded with a phpinfo page, showing us we have indeed achieved RCE.
The vulnerability was discovered by Devcore researcher Orange Tsai, who said: “The bug is incredibly simple, but that’s also what makes it interesting.”
The Devcore writeup said that the researchers have confirmed that XAMPP is vulnerable when Windows is configured to use the locales for Traditional Chinese, Simplified Chinese, or Japanese. In Windows, a locale is a set of user preference information related to the user’s language, environment, and/or cultural conventions. The researchers haven’t tested other locales and have urged people using them to perform a comprehensive asset assessment to test their usage scenarios.
CVE-2024-4577 affects all versions of PHP running on a Windows device. That includes version branches 8.3 prior to 8.3.8, 8.2 prior to 8.2.20, and 8.1 prior to 8.1.29.
The 8.0, 7, and 5 version branches are also vulnerable, but since they’re no longer supported, admins will have to follow mitigation advice since patches aren’t available. One option is to apply what are known as rewrite rules such as:
The researchers caution these rules have been tested only for the three locales they have confirmed as vulnerable.
XAMPP for Windows had yet to release a fix at the time this post went live. For admins without the need for PHP CGI, they can turn it off using the following Apache HTTP Server configuration:
C:/xampp/apache/conf/extra/httpd-xampp.conf
Locating the corresponding lines:
ScriptAlias /php-cgi/ "C:/xampp/php/"
And comment it out:
# ScriptAlias /php-cgi/ "C:/xampp/php/"
Additional analysis of the vulnerability is available here.
Researchers on Wednesday reported critical vulnerabilities in a widely used networking appliance that leaves some of the world’s biggest networks open to intrusion.
The vulnerabilities reside in BIG-IP Next Central Manager, a component in the latest generation of the BIG-IP line of appliances organizations use to manage traffic going into and out of their networks. Seattle-based F5, which sells the product, says its gear is used in 48 of the top 50 corporations as tracked by Fortune. F5 describes the Next Central Manager as a “single, centralized point of control” for managing entire fleets of BIG-IP appliances.
As devices performing load balancing, DDoS mitigation, and inspection and encryption of data entering and exiting large networks, BIG-IP gear sits at their perimeter and acts as a major pipeline to some of the most security-critical resources housed inside. Those characteristics have made BIG-IP appliances ideal for hacking. In 2021 and 2022, hackers actively compromised BIG-IP appliances by exploiting vulnerabilities carrying severity ratings of 9.8 out of 10.
On Wednesday, researchers from security firm Eclypsium reported finding what they said were five vulnerabilities in the latest version of BIG-IP. F5 has confirmed two of the vulnerabilities and released security updates that patch them. Eclypsium said three remaining vulnerabilities have gone unacknowledged, and it’s unclear if their fixes are included in the latest release. Whereas the exploited vulnerabilities from 2021 and 2022 affected older BIG-IP versions, the new ones reside in the latest version, known as BIG-IP Next. The severity of both vulnerabilities is rated as 7.5.
“BIG-IP Next marks a completely new incarnation of the BIG-IP product line touting improved security, management, and performance,” Eclypsium researchers wrote. “And this is why these new vulnerabilities are particularly significant—they not only affect the newest flagship of F5 code, they also affect the Central Manager at the heart of the system.”
The vulnerabilities allow attackers to gain full administrative control of a device and then create accounts on systems managed by the Central Manager. “These attacker-controlled accounts would not be visible from the Next Central Manager itself, enabling ongoing malicious persistence within the environment,” Eclypsium said. The researchers said they have no indication any of the vulnerabilities are under active exploitation.
Both of the fixed vulnerabilities can be exploited to extract password hashes or other sensitive data that allow for the compromise of administrative accounts on BIG-IP systems. F5 described one of them—tracked as CVE-2024-21793—as an Odata injection flaw, a class of vulnerability that allows attackers to inject malicious data into Odata queries. The other vulnerability, CVE-2024-26026, is an SQL injection flaw that can execute malicious SQL statements.
Eclypsium said it reported three additional vulnerabilities. One is an undocumented programming interface that allows for server-side request forgeries, a class of attack that gains access to sensitive internal resources that are supposed to be off-limits to outsiders. Another is the ability for unauthenticated administrators to reset their password even without knowing what it is. Attackers who gained control of an administrative account could exploit this last flaw to lock out all legitimate access to a vulnerable device.
The third is a configuration in the bcrypt password hashing algorithm that makes it possible to perform brute-force attacks against millions of passwords per second. The Open Web Application Security Project says that the bcrypt “work factor”—meaning the amount of resources required to convert plaintext into cryptographic hashes—should be set to a level no lower than 10. When Eclypsium performed its analysis, the Central Manager set it at six.
Eclypsium researchers wrote:
The vulnerabilities we have found would allow an adversary to harness the power of Next Central Manager for malicious purposes. First, the management console of the Central Manager can be remotely exploited by any attacker able to access the administrative UI via CVE 2024-21793 or CVE 2024-26026. This would result in full administrative control of the manager itself. Attackers can then take advantage of the other vulnerabilities to create new accounts on any BIG-IP Next asset managed by the Central Manager. Notably, these new malicious accounts would not be visible from the Central Manager itself.
All 5 vulnerabilities were disclosed to F5 in one batch, but F5 only formally assigned CVEs to the 2 unauthenticated vulnerabilities. We have not confirmed if the other 3 were fixed at the time of publication.
F5 representatives didn’t immediately have a response to the report. Eclypsium went on to say:
These weaknesses can be used in a variety of potential attack paths. At a high level attackers can remotely exploit the UI to gain administrative control of the Central Manager. Change passwords for accounts on the Central Manager. But most importantly, attackers could create hidden accounts on any downstream device controlled by the Central Manager.
Eclypsium
The vulnerabilities are present in BIG-IP Next Central Manager versions 20.0.1 through 20.1.0. Version 20.2.0, released Wednesday, fixes the two acknowledged vulnerabilities. As noted earlier, it’s unknown if version 20.2.0 fixes the other behavior Eclypsium described.
“If they are fixed, it is +- okay-ish, considering the version with them will still be considered vulnerable to other things and need a fix,” Eclypsium researcher Vlad Babkin wrote in an email. “If not, the device has a long-term way for an authenticated attacker to keep their access forever, which will be problematic.”
A query using the Shodan search engine shows only three instances of vulnerable systems being exposed to the Internet.
Given the recent rash of active exploits targeting VPNs, firewalls, load balancers, and other devices positioned at the network edge, BIG-IP Central Manager users would do well to place a high priority on patching the vulnerabilities. The availability of proof-of-concept exploitation code in the Eclypsium disclosure further increases the likelihood of active attacks.
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.
Linux developers are in the process of patching a high-severity vulnerability that, in certain cases, allows the installation of malware that runs at the firmware level, giving infections access to the deepest parts of a device where they’re hard to detect or remove.
The vulnerability resides in shim, which in the context of Linux is a small component that runs in the firmware early in the boot process before the operating system has started. More specifically, the shim accompanying virtually all Linux distributions plays a crucial role in secure boot, a protection built into most modern computing devices to ensure every link in the boot process comes from a verified, trusted supplier. Successful exploitation of the vulnerability allows attackers to neutralize this mechanism by executing malicious firmware at the earliest stages of the boot process before the Unified Extensible Firmware Interface firmware has loaded and handed off control to the operating system.
The vulnerability, tracked as CVE-2023-40547, is what’s known as a buffer overflow, a coding bug that allows attackers to execute code of their choice. It resides in a part of the shim that processes booting up from a central server on a network using the same HTTP that the Internet is based on. Attackers can exploit the code-execution vulnerability in various scenarios, virtually all following some form of successful compromise of either the targeted device or the server or network the device boots from.
“An attacker would need to be able to coerce a system into booting from HTTP if it’s not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it,” Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. “An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code).”
Stated differently, these scenarios include:
Acquiring the ability to compromise a server or perform an adversary-in-the-middle impersonation of it to target a device that’s already configured to boot using HTTP
Already having physical access to a device or gaining administrative control by exploiting a separate vulnerability.
While these hurdles are steep, they’re by no means impossible, particularly the ability to compromise or impersonate a server that communicates with devices over HTTP, which is unencrypted and requires no authentication. These particular scenarios could prove useful if an attacker has already gained some level of access inside a network and is looking to take control of connected end-user devices. These scenarios, however, are largely remedied if servers use HTTPS, the variant of HTTP that requires a server to authenticate itself. In that case, the attacker would first have to forge the digital certificate the server uses to prove it’s authorized to provide boot firmware to devices.
The ability to gain physical access to a device is also difficult and is widely regarded as grounds for considering it to be already compromised. And, of course, already obtaining administrative control through exploiting a separate vulnerability in the operating system is hard and allows attackers to achieve all kinds of malicious objectives.
Mass exploitation began over the weekend for yet another critical vulnerability in widely used VPN software sold by Ivanti, as hackers already targeting two previous vulnerabilities diversified, researchers said Monday.
The new vulnerability, tracked as CVE-2024-21893, is what’s known as a server-side request forgery. Ivanti disclosed it on January 22, along with a separate vulnerability that so far has shown no signs of being exploited. Last Wednesday, nine days later, Ivanti said CVE-2024-21893 was under active exploitation, aggravating an already chaotic few weeks. All of the vulnerabilities affect Ivanti’s Connect Secure and Policy Secure VPN products.
A tarnished reputation and battered security professionals
The new vulnerability came to light as two other vulnerabilities were already under mass exploitation, mostly by a hacking group researchers have said is backed by the Chinese government. Ivanti provided mitigation guidance for the two vulnerabilities on January 11, and released a proper patch last week. The Cybersecurity and Infrastructure Security Agency, meanwhile, mandated all federal agencies under its authority disconnect Ivanti VPN products from the Internet until they are rebuilt from scratch and running the latest software version.
By Sunday, attacks targeting CVE-2024-21893 had mushroomed, from hitting what Ivanti said was a “small number of customers” to a mass base of users, research from security organization Shadowserver showed. The steep line in the right-most part of the following graph tracks the vulnerability’s meteoric rise starting on Friday. At the time this Ars post went live, the exploitation volume of the vulnerability exceeded that of CVE-2023-46805 and CVE-2024-21887, the previous Ivanti vulnerabilities under active targeting.
Shadowserver
Systems that had been inoculated against the two older vulnerabilities by following Ivanti’s mitigation process remained wide open to the newest vulnerability, a status that likely made it attractive to hackers. There’s something else that makes CVE-2024-21893 attractive to threat actors: because it resides in Ivanti’s implementation of the open-source Security Assertion Markup Language—which handles authentication and authorization between parties—people who exploit the bug can bypass normal authentication measures and gain access directly to the administrative controls of the underlying server.
Exploitation likely got a boost from proof-of-concept code released by security firm Rapid7 on Friday, but the exploit wasn’t the sole contributor. Shadowserver said it began seeing working exploits a few hours before the Rapid7 release. All of the different exploits work roughly the same way. Authentication in Ivanti VPNs occurs through the doAuthCheck function in an HTTP web server binary located at /root/home/bin/web. The endpoint /dana-ws/saml20.ws doesn’t require authentication. As this Ars post was going live, Shadowserver counted a little more than 22,000 instances of Connect Secure and Policy Secure.
Shadowserver
VPNs are an ideal target for hackers seeking access deep inside a network. The devices, which allow employees to log into work portals using an encrypted connection, sit at the very edge of the network, where they respond to requests from any device that knows the correct port configuration. Once attackers establish a beachhead on a VPN, they can often pivot to more sensitive parts of a network.
The three-week spree of non-stop exploitation has tarnished Ivanti’s reputation for security and battered security professionals as they have scrambled—often in vain—to stanch the flow of compromises. Compounding the problem was a slow patch time that missed Ivanti’s own January 24 deadline by a week. Making matters worse still: hackers figured out how to bypass the mitigation advice Ivanti provided for the first pair of vulnerabilities.
Given the false starts and high stakes, CISA’s Friday mandate of rebuilding all servers from scratch once they have installed the latest patch is prudent. The requirement doesn’t apply to non-government agencies, but given the chaos and difficulty securing the Ivanti VPNs in recent weeks, it’s a common-sense move that all users should have taken by now.
