Today saw Microsoft patch an interesting vulnerability in Microsoft Outlook. The vulnerability is described as follows:
Microsoft Office Outlook contains a privilege escalation vulnerability that allows for a NTLM Relay attack against another service to authenticate as the user.
However, no specific details were provided on how to exploit the vulnerability.
At MDSec, we’re continually looking to weaponise both private and public vulnerabilities to assist us during our red team operations. Having recently given a talk on leveraging NTLM relaying during red team engagements at FiestaCon, this vulnerability particularly stood out to me and warranted further analysis.
While no particular details were provided, Microsoft did provide a script to audit your Exchange server for mail items that might be being used to exploit the issue.
Review of the audit script reveals it is specifically looking for the PidLidReminderFileParameterproperty inside the mail items and offers the option to “clean” it if found:
Diving in to what this property is, we find the following definition:
This property controls what filename should be played by the Outlook client when the reminder for the mail item is triggered. This is of course particularly interesting as it implies that the property accepts a filename, which of could potentially be a UNC path in order to trigger the NTLM authentication.
Following further analysis of the available properties, we also note the PidLidReminderOverride property which is described as follows:
With this in mind, we should likely set the PidLidReminderOverride property in order to trigger Outlook to parse our malicious UNC inside PidLidReminderFileParameter.
Let’s begin to build an exploit….
The first step to exploit this issue is to create an Outlook MSG file; these files are compound files in CFB format. To speed up the generation of these files, I leveraged the .NET MsgKit library.
Reviewing the MsgKit library, we find that the Appointment class defines a number of properties to add to the mail item before the MSG file is saved:
To create our malicious calendar appointment, I extended the Appointment class to add our required PidLidReminderOverride and PidLidReminderFileParameter properties, as shown above.
From that point, we simply need to create a new appointment and save it, before sending to our victim:
This vulnerability is particularly interesting as it will trigger NTLM authentication to an IP address (i.e. a system outside of the Trusted Intranet Zone or Trusted Sites) and this occurs immediately on opening the e-mail, irrespective of whether the user has selected the option to load remote images or not.
This one is worth patching as a priority as its incredibly easy to exploit and will no doubt be adopted by adversaries fast.
Here’s a demonstration of our exploit which will relay the incoming request to LDAP to obtain a shadow credential:
This article walks us through a current Snyk Security Labs research project focusing on cloud based development environments (CDEs) — which resulted in a full workspace takeover on the Gitpod platform and extended to the user’s SCM account. The issues here have been responsibly disclosed to Gitpod and were resolved within a single working day!
Cloud development environments and Gitpod
As more and more companies begin to leverage cloud-based development environments for benefits such as improved performance, developer experience, consistent development environments, and low setup times, we couldn’t help but wonder about the security implications of adopting these cloud based IDEs.
First, let’s provide a brief overview of how CDEs operate so we can understand the difference between cloud-based and traditional, local-workstation based development — and how it changes the developer security landscape.
In contrast to traditional development, CDEs run on a cloud hosted machine with an IDE backend. This typically provides a web application version of the IDE and support for integrating with a locally installed IDE over SSH, giving users a seamless and familiar experience. When using a CDE, the organization’s code and any supporting services, such as a development database, are hosted within the cloud. Check out the following diagram for a visual representation of information flow in a CDE.
The security risks of locally installed development environments are not new. However, they historically haven’t received much attention from developers. In May 2021, Snyk disclosed vulnerable VS Code extensions that lead to a 1-click data leak or arbitrary command execution. These traditional workstation-based development environments, such as a local instance of VS Code or IntelliJ, carry other information security concerns — including hardware failure, data security, and malware. While these concerns can be addressed by employing Full Disk Encryption, version control, backups, and anti-malware systems, many questions remain unanswered with the adoption of cloud-based development environments:
What happens if a cloud IDE workspace is infected with malware?
What happens when access controls are insufficient and allow cross-user or even cross-organization access to workspaces?
What happens when a rogue developer exfiltrates company intellectual property from a cloud-hosted machine outside the visibility of the organization’s data loss prevention or endpoint security software?
In a current security research project here at Snyk, we examine the security implications of adopting cloud based IDEs. In this article we present a case study of one of the vulnerabilities discovered during our initial exploration in the Gitpod platform.
Examining the Gitpod platform
Disclaimer: When it came to looking at cloud IDE solutions for our research, we settled on either self-hosted or cloud-based solutions, where the vendor has a clearly defined security policy providing safe harbor for researchers.
One of the most popular CDE’s is Gitpod. Its wide adoption and extended feature set — including automated backups, Git integration out of the box, and multiple IDE backends — ensured that Gitpod was among the first products we looked into.
The first stage of our research involved becoming familiar with the basic workflows of Gitpod, setting up an organization, and experimenting with the product while capturing traffic using Burpsuite to observe the various APIs and transactions. We then pulled the Gitpod source code from GitHub to study the inner workings of its APIs, and reviewed any relevant architecture documentation to better understand each of the components and their function. A great resource for this was a video that provided an initial deep dive into the architecture of Gitpod. At a high level, Gitpod leverages multiple microservices deployed in a Kubernetes environment, where each user workspace is deployed to a dedicated ephemeral pod.
Gitpod’s primary set of external components are concerned with the dashboard, authentication, and the creation and management of workspaces, organizations, and accounts. At its core, the main component here is aptly named server, a TypeScript application that exposes a JSONRPC API over WebSocket that is consumed by a React frontend called dashboard.
From the dashboard, it’s easy to integrate with a SCM provider, such as GitHub or Bitbucket, to import a repository and spin up a development environment — which then serves the source code and provides a working Git environment. Once the workspace is provisioned, it is made accessible via
SSH
and
HTTPS
on a subdomain of gitpod.io (i.e
https://[WORKSPACE_NAME].[CLUSTER_NAME].gitpod.io
) through a Golang-based component called ws-proxy.
The security vulnerability that was discovered through our research relates primarily to the server component and the JSONRPC served over a WebSocket connection, which ultimately led to a workspace takeover in Gitpod.
Technical details
WebSockets and Same Origin Policy
WebSocket is a technology that allows for real-time, two-way communication between a client (typically a web browser) and a server. It enables a persistent connection between the client and server, allowing for continuous “real-time” data transfer without the need for repeated HTTP requests.
An interesting aspect of WebSockets from a security perspective, is that a browser security mechanism, the Same Origin Policy (SOP), does not apply. This is the security control which prevents a website from issuing an AJAX request to another website and being able to read the response. If this were possible, it would present a security concern because browsers typically submit cookies along with every request (even for Cross Origin requests, such as CSRF related attacks). Without SOP, any website would be able to issue requests to foreign websites and obtain your data from other domains.
This leads us to the vulnerability class known as Cross-Site WebSocket Hijacking. This attack is similar to a combination of a Cross-Site Request Forgery and CORS misconfiguration. When a WebSocket handshake relies solely upon HTTP cookies for authentication, a malicious website is able to instantiate a new WebSocket connection to the vulnerable application, allowing an attacker to both send and receive data through the connection.
When reviewing an application with WebSocket connections, it’s always worth examining this in depth. Let’s take a look at the WebSocket request for the Gitpod server.
In normal circumstances, the connection is successfully upgraded to a WebSocket and communication begins. There was no additional authentication taking place within the WebSocket exchange itself, and the JSONRPC can be invoked via the WebSocket connection.
So far, we’ve found no additional authentication taking place within the established channel — a good sign for any potential attackers. Now, let’s verify that no additional Origin checks are taking place by taking a handshake we have observed and tampering with the Origin header.
This looks promising! It seems that the domain
evil.com
is able to issue Cross-Origin WebSocket requests to
gitpod.io
. However, another security mechanism introduces a challenge.
SameSite Cookie bypass
SameSite cookies are a fairly recent addition, providing partial mitigation against Cross-Site Request Forgery (CSRF) attacks. While not everyone has adopted them, most popular browsers have made the default value for all cookies which do not explicitly disable
SameSite
to be
Lax
. So while the underlying vulnerability is present, without a bypass for
SameSite
cookies our attack would largely be theoretical and only work against a subset of outdated and niche browsers.
So what is a
site
in the context of
SameSite
? Simply put, the site corresponds to the combination of the scheme and the registrable domain (if any) of the origin’s host. If we look at the specifications for
SameSite
we can see that subdomains are not considered. This is more relaxed than the specification of an Origin used by the Same Origin Policy, which is comprised of a scheme + host (including subdomains) + port (eg: https://security.snyk.io:8443).
Earlier, we observed that the workspace was exposed via a subdomain on
gitpod.io
. In the context of
SameSite
, the workspace URL is considered to be the same site as
gitpod.io
. So, it should be possible for one workspace to issue a cross-domain
SameSite
request to a
*.gitpod.io
domain with the original user’s cookies attached. Let’s see if we can leverage an attacker controlled workspace to serve a WebSocket Hijacking payload.
To first verify that the cookies are indeed transmitted and the WebSocket communication is successfully achieved, let’s open the browser console from a workspace and attempt to initiate a WebSocket connection.
As we can see in the above screenshot, we attempt to open a new WebSocket connection and, once open, submit a JSONRPC request. We can see in the console output that a message has been received containing the result of our request, confirming that the cookies are submitted and the origin is permitted to open a websocket to
gitpod.io
.
We now need a way to serve JavaScript from the workspace that can be accessed by a Gitpod user. When looking through the features available, it is possible to expose ports in the workspace and make them accessible using a command line utility called
gitpod-cli
— available on the path inside the workspace by typing
gp
. We can invoke
gp ports expose 8080
, and then set up a basic Python web server using
python -m http.server 8080
. This in turn creates a new subdomain where the exposed port can be accessed as shown below.
However, the connection failed. This is somewhat concerning and requires more investigation. Here we open the source code and start looking for what could be causing the problem. We found the following regular expression pattern, which appears to be used to extract the workspace name from the URL.
The way this matching is performed results in the wrong workspace name being extracted, as demonstrated in the following screenshot:
So, it looks like we can’t serve our content from an exposed port inside the Gitpod hosted workspace and we need another way. By now we already know that we have privileged access to a machine that’s running the VS Code service and is serving requests issued to our workspace URL — so can we abuse this in some way?
The initial idea was to terminate the
vscode
process and start a Python web server to serve an HTML file. Unfortunately, this did not work and resulted in the workspace being restarted. This appeared to be performed by a local service
supervisor
. While testing this approach we noticed that when we terminated the process without binding another process to the VS Code port, the
supervisor
service will automatically restart the
vscode
process, resulting in a brief hang to the UI without a full restart of the workspace.
This brought a promising idea. Can we patch VS Code to serve a built-in exploit for us?
Patching VS Code was relatively easy. By comparing the original VS Code server source code to the distributed version, we quickly found a convenient location to serve the exploit.
VS Code contains an API endpoint at
/version
, which returns the commit of the current version:
We modified it so that the correct
Content-Type
of
text/html
and the contents of an HTML file were returned. Now, we terminated the
vscode
process, allowing our newly introduced changes to load into a newly spawned VS Code process instance:
Finally, we can leverage the JSONRPC methods
getLoggedInUser
,
getGitpodTokens
,
getOwnerToken
, and
addSSHPublicKey
to build a payload that grants us full control over the user’s workspaces when an unsuspecting Gitpod user visits our link!
Here it is in action:
We can see that we’ve been able to extract some sensitive information about the user account, and are notified that our SSH key has been added to the account. Let’s see if we can SSH to the workspace:
Mission successful! As shown above, we have full access to the user’s workspaces after they’ve visited a link we sent them!
Timeline
Mon, Feb. 13, 2023 — Vulnerability disclosed to vendor
In this post, we presented the first findings from our current research into Cloud Development Environments (CDEs) — which allowed a full account takeover through visiting a link, exploiting a commonly misunderstood vulnerability (WebSocket Hijacking), and leveraging a practical SameSite cookie bypass. As cloud developer workspaces are becoming increasingly popular, it’s important to consider the additional risks that are introduced.
We would like to praise Gitpod for their fantastic turnaround on addressing this security vulnerability, and look forward to presenting more of our findings on cloud-based remote development solutions in the near future.
JWT is short for JSON Web Token, where JSON itself is short for JavaScript Object Notation.
JSON is a modernish way of representing structured data; its format is a bit like XML, and can often be used instead, but without all the opening-and-closing angle brackets to get in the way of legibility.
For example, data that might be recorded like this in XML…
Whether the JSON really is easier to read than the XML is an open question, but the big idea of JSON is that because the data is encoded as legal JavaScript source, albeit without any directly or indirectly executable code in it, you can parse and process it using your existing JavaScript engine, like this:
The output string undefined above merely reflects the fact that console.log() is a procedure – a function that does some work but doesn’t return a value. The word Sophos is printed out as a side-effect of calling the function, while undefined denotes what the function calculated and sent back: nothing.
The popularity of JavaScript for both in-browser and server-side programming, plus the visual familiarity of JSON to JavaScript coders, means that JSON is widely used these days, especially when exchanging structured data between web clients and servers.
And one popular use of JSON is the JWT system, which isn’t (officially, at any rate) read aloud as juh-witt, as it is written, but peculiarly pronounced jot, an English word that is sometimes used to refer the little dot we write above above an
i
or
j
, and that refers to a tiny but potentially important detail.
Authenticate strongly, then get a temporary token
Loosely speaking, a JWT is a blob of encoded data that is used by many cloud servers as a service access token.
The idea is that you start by proving your identity to the service, for example by providing a username, password and 2FA code, and you get back a JWT.
The JWT sent back to you is a blob of base64-encoded (actually, URL64-encoded) data that includes three fields:
Which crytographic algorithm was used in constructing the JWT.
What sort of access the JWT grants, and for how long.
A keyed cryptographic hash of the first two fields, using a secret key known only to your service provider.
Once you’ve authenticated up front, you can make subsequent requests to the online service, for example to check a product price or to look up an email address in a database, simply by including the JWT in each request, using it as a sort-of temporary access card.
Clearly, if someone steals your JWT after it’s been issued, they can play it back to the relevant server, which will typically give them access instead of you…
…but JWTs don’t need to be saved to disk, usually have a limited lifetime, and are sent and received over HTTPS connections, so that they can’t (in theory at least) easily be sniffed out or stolen.
When JWTs expire, or if they are cancelled for security reasons by the server, you need to go through the full-blown authentication process again in order to re-establish your right to access the service.
But for as long they’re valid, JWTs improve performance because they avoid the need to reauthenticate fully for every online request you want to make – rather like session cookies that are set in your browser while you’re logged into a social network or a news site.
Security validation as infiltration
Well, cybersecurity news today is full of a revelation by researchers at Palo Alto that we’ve variously seen described as a “high-severity flaw” or a “critical security flaw” in a popular JWT implementation.
In theory, at least, this bug could be exploited by cybercriminals for attacks ranging from implanting unauthorised files onto a JWT server, thus maliciously modifying its configuration or modifying the code it might later use, to direct and immediate code execution inside a victim’s network.
Simply put, the act of presenting a JWT to a back-end server for validation – something that typically happens at every API call (jargon for making a service request) – could lead malware being implanted.
But here’s the good news:
The flaw isn’t intrinsic to the JWT protocol. It applies to a specific implementation of JWT called
from 8.5.1 or earlier to version 9.0.0, which came out on 2022-12-21, you’re now protected from this particular vulnerability.
Cybercriminals can’t directly exploit the bug simply by logging in and making API calls. As far as we can see, although an attacker could subsequently trigger the vulnerability by making remote API requests, the bug needs to be “primed” first by deliberately writing a booby-trapped secret key into your authentication server’s key-store.
According to the researchers, the bug existed in the part of Auth0’s code that validated incoming JWTs against the secret key stored centrally for that user.
As mentioned above, the JWT itself consists of two fields of data denoting your access privileges, and a third field consisting of the first two fields hashed using a secret key known only to the service you’re calling.
To validate the token, the server needs to recalculate the keyed hash of those first two JWT fields, and to confirm the hash that you presented matches the hash it just calculated.
Given that you don’t know the secret key, but you can present a hash that was computed recently using that key…
…the server can infer that you must have acquired the hash from the authentication server in the first place, by proving your identity up front in some suitable way.
Data type confusion
It turns out that the hash validation code in
jsonwebtoken
assumes (or, until recently, assumed) that the secret key for your account in the server’s own authentication key-store really was a cryptographic secret key, encoded in a standard text-based format such as PEM (short for privacy enhanced mail, but mainly used for non-email purposes these days).
If you could somehow corrupt a user’s secret key by replacing it with data that wasn’t in PEM format, but that was, in fact, some other more complex sort of JavaScript data object…
…then you could booby-trap the secret-key-based hash validation calculation by tricking the authentication server into running some JavaScript code of your choice from that infiltrated “fake key”.
Simply put, the server would try to decode a secret key that it assumed was in a format it could handle safely, even if the key wasn’t in a safe format and the server couldn’t deal with it securely.
Note, however, that you’d pretty much need to hack into the secret key-store database first, before any sort of truly remote code execution trigger would be possible.
And if attackers are already able to wander around your network to the point that they can not only poke their noses into but also modify your JWT secret-key database, you’ve probably got bigger problems than CVE-2022-23539, as this bug has been designated.
However, if you’ve now patched but you think crooks might realistically have been able to pull off this sort of JWT attack on your network, patching alone isn’t enough.
In other words, if you think you might have been at risk here, don’t just patch and move on.
Use threat detection and response techniques to look for holes by which cybercriminals could get far enough to attack your network more generally…
…and make sure you don’t have crooks in your network anyway, even after applying the patch.
The open-source jsonwebtoken (JWT) library is affected by a high-severity security flaw that could lead to remote code execution.
The open-source JsonWebToken (JWT) library is affected by a high-severity security flaw, tracked as CVE-2022-23529 (CVSS score: 7.6), that could lead to remote code execution.
The package is maintained by Auth0, it had over 9 million weekly downloads as of January 2022 and it is used by more than 22.000 projects.
The flaw was discovered by Unit 42 researchers, it can be exploited by threat actors by tricking a server into verifying a maliciously crafted JSON web token (JWT) request.
“By exploiting this vulnerability, attackers could achieve remote code execution (RCE) on a server verifying a maliciously crafted JSON web token (JWT) request.” reads the advisory published by Palo Alto Networks.“With that being said, in order to exploit the vulnerability described in this post and control the secretOrPublicKey value, an attacker will need to exploit a flaw within the secret management process.”
JsonWebToken is an open-source JavaScript package that allows users to verify/sign JSON web tokens (JWT).
The flaw impacts JsonWebToken package version 8.5.1 or an earlier version, the JsonWebToken package version 9.0.0 addressed the issue.
“For versions <=8.5.1 of jsonwebtoken library, if a malicious actor has the ability to modify the key retrieval parameter (referring to the secretOrPublicKey argument from the readme link) of the jwt.verify() function, they can gain remote code execution (RCE).” reads the advisory published on GitHub.“You are affected only if you allow untrusted entities to modify the key retrieval parameter of the jwt.verify() on a host that you control.”
Vulnerabilities in open-source projects are very dangerous, threat actors could exploit them as part of supply chain attacks that can impact any projects relying on them.
“Open source projects are commonly used as the backbone of many services and platforms today. This is also true for the implementation of sensitive security mechanisms such as JWTs, which play a huge role in authentication and authorization processes.” concludes Palo Alto. “Security awareness is crucial when using open source software. Reviewing commonly used security open source implementations is necessary for maintaining their dependability, and it’s something the open source community can take part in.”
Below is the timeline for this vulnerability:
July 13, 2022 – Unit 42 researchers sent a disclosure to the Auth0 team under responsible disclosure procedures
July 27, 2022 – Auth0 team updated that the issue was under review
Aug. 23, 2022 – Unit 42 researchers sent an update request
Aug. 24, 2022 – Auth0 team updated that the engineering team was working on the resolution
Dec. 21, 2022 – A patch was provided by the Auth0 engineering team
Write a class directly to call the decrypt function
cryptTag is
<strong>EnDecryptUtil.getCryptTag()</strong>
obtained by
Parse the persistence-configurations.xml file to get the CryptTag attribute and view the file content
Attempt to
<strong>MLITE_ENCRYPT_DECRYPT</strong>
decrypt unsuccessfully, and then found that an external entity was introduced at the top of the xml file
Finally
<strong>conf\customer-config.xml</strong>
found the CryptTag in the file
The algorithm is AES256. After decryption, link to the database and check the AaaLogin table.
The domainName is obtained
<strong>-</strong>
, and the final request package is as follows
Get restapi from this
The rce method looked at the restapi documentation. There is a workflow that can be used for rce, but there is a problem with accessing through restapi.
an internal api, the isAPIClient in the session will only be assigned when you log in, so this place isApiclient is false, and NmsUtil.isRMMEdition is false, causing an exception to be thrown
APIError.internalAPI(request, response)
. then all internal apis cannot be called.
The
conf\OpManager\do\RestApi.xml
key APIs that define the workflow are
<strong><em>EXPOSED_API=TRUE</em></strong>
the internal APIs.
At this point, the rce is broken. I traced back the
isInternalAPI()
function and found that all the APIs are in the database
, a total of 955 APIs can be accessed through restapi.
I looked at it and saw that nothing was added, deleted, modified, and checked. I hope someone who is destined can dig out a rce.
Replenish
My colleague looked at the cve injected by the other two commands of opmanager and found that it should be possible to string rce together. see colleagues’ articles
The writing is rubbish, the wording is frivolous, the content is simple, and the operation is unfamiliar. The deficiencies are welcome to give pointers and corrections from the masters, and I am grateful.
CVE-2022-36923 Detail
Current Description
Zoho ManageEngine OpManager, OpManager Plus, OpManager MSP, Network Configuration Manager, NetFlow Analyzer, Firewall Analyzer, and OpUtils before 2022-07-27 through 2022-07-28 (125657, 126002, 126104, and 126118) allow unauthenticated attackers to obtain a user’s API key, and then access external APIs.
Zoho ManageEngine OpManager, OpManager Plus, OpManager MSP, Network Configuration Manager, NetFlow Analyzer, Firewall Analyzer, and OpUtils before 2022-07-27 through 2022-07-28 (125657, 126002, 126104, and 126118) allow unauthenticated attackers to obtain a user’s API key, and then access external APIs.
Networking equipment vendor Zyxel addressed a critical vulnerability impacting its network-attached storage (NAS) devices.
Zyxel addressed a critical vulnerability, tracked as CVE-2022-34747, impacting its network-attached storage (NAS) devices.
The CVE-2022-34747 (CVSS score: 9.8) flaw is classified as a format string vulnerability that resides in Zyxel NAS326 firmware versions prior to V5.21(AAZF.12)C0. An attacker can exploit the vulnerability to achieve unauthorized remote code execution via a crafted UDP packet.
“A format string vulnerability was found in a specific binary of Zyxel NAS products that could allow an attacker to achieve unauthorized remote code execution via a crafted UDP packet.” reads the advisory published by the vendor.
Below is the list of affected models and the firmware patches released by the company.
The vulnerability was reported to Zyxel by Shaposhnikov Ilya.
In May 2022, Zyxel released security updates to address multiple vulnerabilities affecting multiple products, including firewall, AP, and AP controller products.
Below is the list of the four vulnerabilities, the most severe one is a command injection flaw in some CLI commands tracked as CVE-2022-26532 (CVSS v3.1 7.8):
CVE-2022-0734: A cross-site scripting vulnerability was identified in the CGI program of some firewall versions that could allow an attacker to obtain some information stored in the user’s browser, such as cookies or session tokens, via a malicious script.
CVE-2022-26531: Multiple improper input validation flaws were identified in some CLI commands of some firewall, AP controller, and AP versions that could allow a local authenticated attacker to cause a buffer overflow or a system crash via a crafted payload.
CVE-2022-26532: A command injection vulnerability in the “packet-trace” CLI command of some firewall, AP controller, and AP versions could allow a local authenticated attacker to execute arbitrary OS commands by including crafted arguments to the command.
CVE-2022-0910: An authentication bypass vulnerability caused by the lack of a proper access control mechanism has been found in the CGI program of some firewall versions. The flaw could allow an attacker to downgrade from two-factor authentication to one-factor authentication via an IPsec VPN client.
Networking device maker Zyxel is warning customers today of a new critical remote code execution (RCE) vulnerability impacting three models of its Networked Attached Storage (NAS) products.
The vulnerability is tracked as CVE-2022-34747 and has received a CVSS v3 severity score of 9.8, rated critical, but not many details have been disclosed.
“A format string vulnerability was found in a specific binary of Zyxel NAS products that could allow an attacker to achieve unauthorized remote code execution via a crafted UDP packet,” explains the advisory.
Security researcher Shaposhnikov Ilya discovered the vulnerability on June 2022. As a result, Zyxel gradually released security updates for the impacted models over the following months.
The NAS devices vulnerable to this flaw are NAS326, NAS540, and NAS542, all still within their active support period.
The vulnerable firmware versions are V5.21(AAZF.11)C0 and earlier for NAS326, V5.21(AATB.8)C0 and earlier for NAS540, and V5.21(AATB.8)C0 or older for NAS542.
The vendor has already released security updates for the impacted devices in the form of firmware updates, with links to the downloads in the security advisory.
Alternatively, you can visit Zyxel’s official download portal, enter your device model, and download the latest firmware update listed in the results.
Remote code execution flaws allow many different attacks, including bypassing the need for user authentication, elevation of privilege, or any other limiting prerequisite.
The vulnerability could be abused to steal data, delete data, or deploy ransomware on Internet-exposed NAS devices.
While all scenarios are dire, ransomware is the most common, as it gives the threat actors the best way to monetize a successful attack.
Only yesterday, we reported that QNAP patched a zero-day vulnerability over the weekend that was used in a new wave of DeadBolt ransomware attacks.
In February, the same group also targeted ASUSTOR devices by leveraging an exploit for a previously unknown flaw.
Thus, DeadBolt is competent enough to find undocumented security gaps, let alone exploit known vulnerabilities.
Other ransomware gangs actively targeting NAS devices are Checkmate and eChoraix, both very active in 2022.
QNAP is warning customers of ongoing DeadBolt ransomware attacks that started on Saturday by exploiting a zero-day vulnerability in Photo Station.
The company has patched the security flaw but attacks continue today.
«QNAP® Systems, Inc. today detected the security threat DEADBOLT leveraging exploitation of Photo Station vulnerability to encrypt QNAP NAS that are directly connected to the Internet,» explains the security notice.
The attacks were widespread, with the ID Ransomware service seeing a surge in submissions on Saturday and Sunday.
A surge in DeadBolt submissions to ID Ransomware Source: BleepingComputer
QNAP releases patches for a zero-day flaw
QNAP released Photo Station security updates 12 hours after DeadBolt began using the zero-day vulnerability in attacks, urging NAS customers to immediately update Photo Station to the newest version.
The following security updates fix the vulnerability:
QTS 5.0.1: Photo Station 6.1.2 and later
QTS 5.0.0/4.5.x: Photo Station 6.0.22 and later
QTS 4.3.6: Photo Station 5.7.18 and later
QTS 4.3.3: Photo Station 5.4.15 and later
QTS 4.2.6: Photo Station 5.2.14 and later
Alternatively, QNAP suggests users replace Photo Station with QuMagie, a safer photo storage management tool for QNAP NAS devices.
“We strongly urge that their QNAP NAS should not be directly connected to the internet. We recommend users to make use of the myQNAPcloud Link feature provided by QNAP, or enable the VPN service.” - QNAP.
Applying the security updates will prevent the DeadBolt ransomware and other threat actors from exploiting the vulnerability and encrypting devices. However, NAS devices should never be publicly exposed to the Internet and instead placed behind a firewall.
QNAP customers can find detailed instructions on applying the available updates and setting up myQNAPcloud in the security advisory.
Finally, it is recommended to use strong passwords on all NAS user accounts and take regular snapshots to prevent data loss in the case of attacks.
DeadBolt: the NAS ransomware bane
The DeadBolt ransomware gang has been targeting NAS devices since January 2022, using an alleged zero-day vulnerability on Internet-exposed NAS devices.
The ransomware operation conducted further attacks on QNAP devices in May and June 2022.
DeadBolt ransom notes Source: BleepingComputer
Earlier in February, DeadBolt began targeting ASUSTOR NAS devices using a zero-day vulnerability they attempted to sell to the vendor for 7.5 Bitcoin.
In most of these attacks, DeadBolt demanded a payment of just over a thousand USD from impacted users in exchange for a working decryptor.
However, other NAS ransomware groups demand more significant amounts from their victims.
The Checkmate ransomware targeted QNAP NAS products in July, demanding victims pay $15,000.
