Threat actors carried out zero-day attacks that targeted Windows users with malware for more than a year before Microsoft fixed the vulnerability that made them possible, researchers said Tuesday.

The vulnerability, present in both Windows 10 and 11, causes devices to open Internet Explorer, a legacy browser that Microsoft decommissioned in 2022 after its aging code base made it increasingly susceptible to exploits. Following the move, Windows made it difficult, if not impossible, for normal actions to open the browser, which was first introduced in the mid-1990s.

Tricks old and new

Malicious code that exploits the vulnerability dates back to at least January 2023 and was circulating as recently as May this year, according to the researchers who discovered the vulnerability and reported it to Microsoft. The company fixed the vulnerability, tracked as CVE-2024-CVE-38112, on Tuesday as part of its monthly patch release program. The vulnerability, which resided in the MSHTML engine of Windows, carried a severity rating of 7.0 out of 10.

The researchers from security firm Check Point said the attack code executed “novel (or previously unknown) tricks to lure Windows users for remote code execution.” A link that appeared to open a PDF file appended a .url extension to the end of the file, for instance, Books_A0UJKO.pdf.url, found in one of the malicious code samples.

When viewed in Windows, the file showed an icon indicating the file was a PDF rather than a .url file. Such files are designed to open an application specified in a link.

A link in the file made a call to msedge.exe, a file that runs Edge. The link, however, incorporated two attributes—mhtml: and !x-usc:—an “old trick” threat actors have been using for years to cause Windows to open applications such as MS Word. It also included a link to a malicious website. When clicked, the .url file disguised as a PDF opened the site, not in Edge, but in Internet Explorer.

“From there (the website being opened with IE), the attacker could do many bad things because IE is insecure and outdated,” Haifei Li, the Check Point researcher who discovered the vulnerability, wrote. “For example, if the attacker has an IE zero-day exploit—which is much easier to find compared to Chrome/Edge—the attacker could attack the victim to gain remote code execution immediately. However, in the samples we analyzed, the threat actors didn’t use any IE remote code execution exploit. Instead, they used another trick in IE—which is probably not publicly known previously—to the best of our knowledge—to trick the victim into gaining remote code execution.”

IE would then present the user with a dialog box asking them if they wanted to open the file masquerading as a PDF. If the user clicked “open,” Windows presented a second dialog box displaying a vague notice that proceeding would open content on the Windows device. If users clicked “allow,” IE would load a file ending in .hta, an extension that causes Windows to open the file in Internet Explorer and run embedded code.

“To summarize the attacks from the exploitation perspective: the first technique used in these campaigns is the “mhtml” trick, which allows the attacker to call IE instead of the more secure Chrome/Edge,” Li wrote. “The second technique is an IE trick to make the victim believe they are opening a PDF file, while in fact, they are downloading and executing a dangerous .hta application. The overall goal of these attacks is to make the victims believe they are opening a PDF file, and it is made possible by using these two tricks.”

The Check Point post includes cryptographic hashes for six malicious .url files used in the campaign. Windows users can use the hashes to check if they have been targeted.

https://arstechnica.com/?p=2036304

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.

https://arstechnica.com/?p=2035011

A critical vulnerability recently discovered in a widely used piece of software is putting huge swaths of the Internet at risk of devastating hacks, and attackers have already begun actively trying to exploit it in real-world attacks, researchers warn.

The software, known as MOVEit and sold by Progress Software, allows enterprises to transfer and manage files using various specifications, including SFTP, SCP, and HTTP protocols and in ways that comply with regulations mandated under PCI and HIPAA. At the time this post went live, Internet scans indicated it was installed inside almost 1,800 networks around the world, with the biggest number in the US. A separate scan performed Tuesday by security firm Censys found 2,700 such instances.

Causing mayhem with a null string

Last year, a critical MOVEit vulnerability led to the compromise of more than 2,300 organizations, including Shell, British Airways, the US Department of Energy, and Ontario’s government birth registry, BORN Ontario, the latter of which led to the compromise of information for 3.4 million people.

On Tuesday, Progress Software disclosed CVE-2024-5806, a vulnerability that enables attackers to bypass authentication and gain access to sensitive data. The vulnerability, found in the MOVEit SFTP module, carries a severity rating of 9.1 out of 10. Within hours of the vulnerability becoming publicly known, hackers were already attempting to exploit it, researchers from the Shadowserver organization said.

A deep-dive technical analysis by researchers with the offensive security firm watchTowr Labs said that the vulnerability, found in the MOVEit SFTP module, can be exploited in at least two attack scenarios. The most powerful attack allows hackers to use a null string—a programming concept for no value—as a public encryption key during the authentication process. As a result, the hacker can log in as an existing trusted user.

“This is a devastating attack,” watchTowr Labs researchers wrote. “It allows anyone who is able to place a public key on the server to assume the identity of any SFTP user at all. From here, this user can do all the usual operations—read, write, or delete files, or otherwise cause mayhem.”

A separate attack described by the watchTowr researchers allows attackers to obtain cryptographic hashes masking user passwords. It works by manipulating SSH public key paths to execute a “forced authentication” using a malicious SMB server and a valid username. The technique will expose the cryptographic hash masking the user password. The hash, in turn, must be cracked.

The researchers said that the requirements of uploading a public key to a vulnerable server isn’t a particularly high hurdle for attackers to clear, because the entire purpose of MOVEit is to transfer files. It’s also not especially hard to learn or guess the names of user accounts of a system. The watchTowr post also noted that their exploits use IPWorks SSH, a commercial product Progress Software extends in MOVEit.

The Progress Software advisory said: “A newly identified vulnerability in a third-party component used in MOVEit Transfer elevates the risk of the original issue mentioned above if left unpatched. While the patch distributed by Progress on June 11th successfully remediates the issue identified in CVE-2024-5806, this newly disclosed third-party vulnerability introduces new risk.”

The post advised customers to ensure inbound RDP access to MOVEit servers is blocked and to restrict outbound access to known trusted endpoints from MOVEit servers. A company representative declined to say if that component was IPWorks SSH.

The vulnerability affects MOVEit Transfer versions:

• 2023.0.0 before 2023.0.11
• 2023.1.0 before 2023.1.6
• 2024.0.0 before 2024.0.2

Fixes for 2023.0.11, 2023.1.6, and 2024.0.2 are available here, here, and here, respectively. MOVEit users can check the version they’re running using this link.

Given the damage resulting from the mass exploitation of last year’s MOVEit vulnerability, it’s likely this latest one could follow a similar path. Affected admins should prioritize investigating if they’re vulnerable ASAP and respond appropriately. Additional analysis and guidance is available here and here.

https://arstechnica.com/?p=2033848

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. https://arstechnica.com/?p=2031993

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:

-d allow_url_include=1 -d auto_prepend_file=php://input

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?

POST /test.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1
Host: {{host}}
User-Agent: curl/8.3.0
Accept: */*
Content-Length: 23
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive  

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:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^%ad [NC]
RewriteRule .? - [F,L]

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.

https://arstechnica.com/?p=2029943

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.

https://arstechnica.com/?p=2019186

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.

https://arstechnica.com/?p=2017043

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=<BASE64_ENCODED_COMMAND_TO_BE_EXECUTED>

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.

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

According to netsecfish, Internet scans found roughly 92,000 devices that were vulnerable.

According to the Greynoise email, exploits company researchers are seeing look like this:

GET /cgi-bin/nas_sharing.cgi?dbg=1&cmd=15&user=messagebus&passwd=&cmd=Y2QgL3RtcDsgcLnNo HTTP/1.1

Other malware invoked in the exploit attempts include:

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.

https://arstechnica.com/?p=2015480

VMware is urging customers to patch critical vulnerabilities that make it possible for hackers to break out of sandbox and hypervisor protections in all versions, including out-of-support ones, of VMware ESXi, Workstation, Fusion, and Cloud Foundation products.

A constellation of four vulnerabilities—two carrying severity ratings of 9.3 out of a possible 10—are serious because they undermine the fundamental purpose of the VMware products, which is to run sensitive operations inside a virtual machine that’s segmented from the host machine. VMware officials said that the prospect of a hypervisor escape warranted an immediate response under the company’s IT Infrastructure Library, a process usually abbreviated as ITIL.

“Emergency change”

“In ITIL terms, this situation qualifies as an emergency change, necessitating prompt action from your organization,” the officials wrote in a post. “However, the appropriate security response varies depending on specific circumstances.”

Among the specific circumstances, one concerns which vulnerable product a customer is using, and another is whether and how it may be positioned behind a firewall. A VMware advisory included the following matrix showing how the vulnerabilities—tracked as CVE-2024-22252, CVE-2024-22253, CVE-2024-22254, CVE-2024-22255—affect each of the vulnerable products:

Three of the vulnerabilities affect the USB controller the products use to support peripheral devices such as keyboards and mice. The advisory describes the vulnerabilities as:

CVE-2024-22252: a use-after-free vulnerability in XHCI USB controller with a maximum severity range of 9.3 for Workstation/Fusion and a base score of 8.4 for ESXi. Someone with local administrative privileges on a virtual machine can execute code as the virtual machine’s VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox, whereas, on Workstation and Fusion, this could lead to code execution on the machine where Workstation or Fusion is installed.

CVE-2024-22253: a use-after-free vulnerability in UHCI USB controller with a maximum severity rating of 9.3 for Workstation/Fusion and a base score of 8.4 for ESXi. Exploitation requirements and outcomes are the same as for CVE-2024-22252.

CVE-2024-22254: an out-of-bounds write vulnerability with a maximum severity base score of 7.9. This vulnerability makes it possible for someone with privileges within the VMX process to trigger an out-of-bounds write leading to a sandbox escape.

CVE-2024-22255: an information disclosure vulnerability in the UHCI USB controller with a maximum CVSSv3 base score of 7.1. Someone with administrative access to a virtual machine can exploit it to leak memory from the vmx process.

Broadcom, the VMware parent company, is urging customers to patch vulnerable products. As a workaround, users can remove USB controllers from vulnerable virtual machines, but Broadcom stressed that this measure could degrade virtual console functionality and should be viewed as only a temporary solution. In an article explaining how to remove a USB controller, officials wrote:

The workaround is to remove all USB controllers from the Virtual Machine. As a result, USB passthrough functionality will be unavailable.

In addition, virtual/emulated USB devices, such as VMware virtual USB stick or dongle, will not be available for use by the virtual machine. In contrast, the default keyboard/mouse as input devices are not affected as they are, by default, not connected through USB protocol but have a driver that does software device emulation in the guest OS.

IMPORTANT:
Certain guest operating systems, including Mac OS, do not support using a PS/2 mouse and keyboard. These guest operating systems will be left without a mouse and keyboard without a USB controller.

VMware said it isn’t aware of any evidence that any of the vulnerabilities are under active exploitation.

https://arstechnica.com/?p=2008406

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.

https://arstechnica.com/?p=2001542