Team82 has developed a unique technique that allowed us to impersonate Synology’s DS920+ network-attached storage device and force its QuickConnect cloud service to redirect users to an attacker-controlled device.
Synology, a top NAS vendor, has addressed the vulnerabilities we uncovered, and has updated its cloud service to protect its users.
The research was conducted in preparation for last December’s Pwn2Own Toronto hacking competition.
We uncovered not only credential theft flaws, but also remote code execution vulnerabilities that could allow an attacker to control devices and launch further attacks.
Our impersonation attack allowed attackers to access a user’s remote device, steal personal information, and access stored data.
The Zero Day Initiative, which organizes the Pwn2Own events, also published advisories:
Synology is a top-tier network-attached storage vendor, and one that has embraced providing users with remote access to their stored data via its Synology QuickConnect cloud-based infrastructure. In preparation for Pwn2Own Toronto, the annual hacking competition focused on small office IoT devices, we zeroed in to Synology and Western Digital NAS given their position in the market and reach across users worldwide.
This cloud-based remote access was particularly appealing from a research perspective given the enhanced security such vendors deploy to secure their API and web-based interfaces from malicious users. In Synology’s case—and Western Digital’s—all API requests require a valid authentication token, and authorization requests are checked before a user is allowed to interact with resources. This approach blocks potential IDOR vulnerabilities (insecure direct object references) and prevents one user from accessing another’s assets.
Today, most developers are aware of the risks associated with these types of vulnerabilities and attacks, and take advantage of a wide variety of authentication frameworks and libraries in order to deploy a strong user authentication and authorization model.
That said, given that user authentication is generally well protected, the same cannot always be said for the device’s communication channel with the cloud, which may be ripe for abuse. In both our Synology and Western Digital research, we attempted to find and exploit vulnerabilities in their cloud service, which enables users to access and interact with their homebound NAS devices from anywhere.
At Pwn2Own Toronto in late December 2022, we demonstrated vulnerabilities during the competition that have since been fixed in Synology’s QuickConnect cloud service, keeping users safe from the device impersonation and credential theft execution flaws we uncovered. Our approach was to develop a technique whereby we were able to impersonate a device and force QuickConnect to redirect users to an attacker-controlled device instead of their device.
Using the stolen credentials, an attacker could authenticate to the cloud as the user, access data stored on their NAS device, and also leverage other legitimate features in order to carry out remote code execution attacks on the real device. An attacker would then be able to backdoor the device and maintain persistence, and also launch other attacks, including ransomware.
In this blog, we will explain the inner workings of QuickConnect, how devices authenticate, and the means by which we were able to leverage device identifiers and secrets in order to pull off our attack.
The Synology DS920+ is a network-attached storage solution running a proprietary Linux-based operating system. Each version has its own nickname; we researched synology_geminilake_920+. (Version DSM 7.1-42962 Update 2) Synology DiskStation Manager (DSM), it offers a flexible all-in-one solution for data management, including sharing, synchronization, and backup.
The web server is NGINX Web server. The ports for the web interface are 5000 for HTTP and 5001 for the HTTPS:
Open services on the NAS Device include web interface (80/443 redirect to 5000/5001), SSH (22), SNMP (161), SMB (445) and more.
The web pages are served by CGI service. All CGI endpoints are C++ compiled binaries and the root directory for all CGIs is: /usr/syno/synoman and the main configuration file is located at /etc/synoinfo.conf. The user web session information is stored in /usr/syno/etc/private/session.
Similarly to our attack on Western Digital, we wanted to examine the cloud services of Synology DS920+, with the goal of identifying vulnerabilities that could allow us to take over devices. To accomplish this goal, the first step was to gain a better understanding of Synology's cloud services: QuickConnect which is mainly managed by the /usr/syno/sbin/synorelayd binary.
One of the main features of Synology SD920+ is its native integration with the QuickConnect service. Synology QuickConnect is a cloud platform for connecting users remotely from anywhere around the world to their device at home, providing them remote access to their stored data, files, and information.
QuickConnect requires a Synology account to access the QuickConnect infrastructure. On updated NAS devices the QuickConnect uses Smart DNS, which enforces certificates on the device IPs. Furthermore, all communication is encrypted (HTTPS), and a Let’s Encrypt-issued SSL certificate is issued for each device.
When remote, external users (via the internet) want to communicate with their devices, they perform the following actions:
The user enters quickconnect.to into a browser or mobile app and enters their device alias name. No client account is needed. Behind the scenes, the following address will be used:
https://ALIAS.quickconnect.to
QuickConnect cloud will return to the client list of addresses to try. These addresses include both local (LAN), external exposed (WAN), and relay addresses.
The client will first try to access the LAN addresses, in case both the user and the device are on the same network.
If none of the local addresses worked, the client will try to access the WAN addresses.
Finally, if all direct access attempts fail, the client will connect over a special relay server that will connect them with their device.
The device will receive a request from the cloud to start VPN access
The device opens an OpenVPN tunnel and acknowledges the QuickConnect server
The client connects to the device using the opened tunnel through a relay server.
After successfully connecting, the user can log in to their device by providing the login credentials to the device.
The device connection and relay mechanism intrigued us as a fascinating area of research, particularly due to its lack of client account requirements. Thus, we embarked on a journey to comprehend the entire mechanism from the perspective of the device (authentication, tunnel, user-connection, user-access).
By identifying vulnerabilities in the device-cloud authentication process, we could potentially mimic the device and spoof its IP address. Consequently, when the user attempts to access their device, the QuickConnect platform would unknowingly redirect them to the attacker. Since the authentication is verified against the device itself, the attacker would then obtain the authentic device credentials.
Therefore, we examined the identification elements such as serial and model numbers, and unique authentication tokens, as well as user information—all of which is used by a device to authenticate to the QuickConnect service. If we were to obtain all of these identification elements, we would be able to impersonate the device and perform actions on its behalf. Interestingly we found that the same procedure is applied for Synology NAS devices, Synology routers, and probably other Synology devices that use QuickConnect as their cloud platform.
When the device boots up it will authenticate itself to the QuickConnect cloud. Once authenticated, it will maintain a pull worker that will wait for further instructions. The main instruction is to start the OpenVPN process and connect to the QuickConnect VPN network. This happens when remote clients are trying to access their Synology device remotely.
The entire device-cloud authentication process is long and complex, but here is the flow, simplified, which will we explain in-depth in a short while:
The important things to notice are:
The device uses many identification elements and keys to authenticate itself to the QuickConnect cloud.
At the end, the device will wait for further instructions to download an OpenVPN configuration and enter the Synology VPN network. This is done so that clients could reach their devices remotely and bypass NAT/firewall restrictions.
If we could collect all these device identifications, we would be able to impersonate the device and force QuickConnect to relay users to our machine instead of their device and we could steal their credentials to the real device.
So let’s see what we need to collect?
Device MAC Address
Device Serial Number
Device Model
DS Token: Deterministically generated from the serial number md5_rec(serial)
API-KEY: Device’s QuickConnect key
provided by the QuickConnect infrastructure. Saved within the device and remains static until removed from the device (for example: performing factory reset). Multiple keys can be generated for single device
AUTH-KEY: User’s QuickConnect key
provided each time a user performs login from the device with a synology account. Each generation of the key will deactivate the previous one.
Device Alias: QuickConnect ID Name
Device ID: QuickConnect ID Number
After we understand what secrets and identifiers are needed for a device to authenticate to QuickConnect’s server and establish a new tunnel, let’s take a look at how we managed to leak these identifiers.
Please note that our assumption is that we are on the same network as the device and we know the victim’s email address (this is regarded as public information).
In order to leak a device’s serial number (SN) and model, we used Synology’s discovery protocol. Synology implemented a pretty extensive discovery protocol, allowing users to interact with their devices locally. The protocol communicates over UDP port 9999, and supports the following set of commands:
Get device information: Get basic information about the device. This command does not require authentication
Set network settings: Alter and change the network settings for the device. To perform this command, the user must supply the admin’s password
Perform memory test: To perform this command, the user must supply the admin’s password
Synology’s discovery protocol implemented two versions of the protocol, v1 and v2, where the main difference between these two versions is that v2 communicates over a secure connection supporting encryption using private/public key cryptography. While the NAS device we researched supports v2 of the protocol, through reverse engineering we discovered that it is actually backwards compatible, meaning we can communicate with it using v1.
By using the discovery protocol, and sending a get device info command, we were able to leak the device serial number and model.
Lastly, since we had the device serial number, we could now also generate its DS-Token. The DS-Token is generated by applying multiple rounds of MD5 on the serial; we call this function MD5-REC.
In addition, we can also easily get the MAC address of the device by sending ARPing or just openly sniff the network to find Synology MAC OUI (90-09-D0).
We now have the device MAC address, serial number, model version and DS-Token.
Device MAC Address: 90:09:d0:01:23:45
Device Serial Number: 2230FG45A0
Device Model: DS920+
DS Token: md5_rec(2230FG45A0)
API-KEY: Device’s QuickConnect key
AUTH-KEY: User’s QuickConnect key
Device Alias: QuickConnect ID Name
Device ID: QuickConnect ID Number
After many hours of researching the Synology-QuickConnect infrastructure and the API routes, we discovered that if we are trying to register the device again we will get a new API-KEY without revoking the previous ones. To register a device all we needed was MAC, serial number, model number, and DS-Token.
Therefore, by using the apiauth.quickconnect.to/api.php route and supplying a device serial number, model and MAC, we got a new valid device API-KEY associated with the device. Even though we issued a new API-KEY, the old one stored on the device still worked, meaning the device could still connect to QuickConnect. This vulnerability is tracked as ZDI-23-658.
Device MAC Address: 90:09:d0:01:23:45
Device Serial Number: 2230FG45A0
Device Model: DS920+
DS Token : md5_rec(2230FG45A0)
API-KEY: 9a8yva45jxzer26j23r..
AUTH-KEY: User’s QuickConnect key
Device Alias: QuickConnect ID Name
Device ID: QuickConnect ID Number
When the user sets up their device to use QuickConnect cloud feature, they login to their device, go to QuickConnect settings and finally connect to their Synology account from the wizard on the device. This is a pairing process that connects the Synology user and their device. Throughout this process a AUTH-KEY token is saved on the device which uses it as part of its authentication process with QuickConnect.
However, after researching many binaries and cloud communication functionality we found an interesting feature: dynamic DNS for our device. Using Synology DDNS we were able to get a new subdomain that points to our external device IP address. For example: claroty.synology.me. As a side note: it’s possible to leak all Synology devices DDNS subdomains by harvesting DNS records and Certificate Transparency Logs (CTL). Check our WD blog for more information about this.
Most of the API is implemented in account.synology.com/dnsauth.php. We started to investigate how this process works, and noticed an interesting action that can be used with this API called get_auth_key. This can be called without needing the device to have a DDNS name so it was a good candidate for us to check.
We played with this functionality a bit and were able to leak the AUTH-KEY without knowing the user’s password! The authentication check for this route was performed based on the user email address, DS-Token, API-KEY, device serial, MAC Address and device model. All of which we already have. This vulnerability is tracked as ZDI-23-659.
Device MAC Address: 90:09:d0:01:23:45
Device Serial Number: 2230FG45A0
Device Model: DS920+
DS Token : md5_rec(2230FG45A0)
API-KEY: 9a8yva45jxzer26j23r..
AUTH-KEY: 8abc54f51is1js2b129..
Device Alias: QuickConnect ID Name
Device ID: QuickConnect ID Number
As we’ve shown before, whenever a user registers their device to the QuickConnect service, it pairs it with an alias. Then, using said alias, the user can access their device from the internet using these URLs:
https://quickconnect.to/ALIAS
https://ALIAS.quickconnect.to
We continued our reverse engineering process on the DDNS mechanism (account.synology.com/dnsauth.php) and found another action we could use to get more data without having a DDNS name set to our device. This action is called: check. We found that this action could return the device alias name if we just ask the API via ds_info parameter.
Device MAC Address: 90:09:d0:01:23:45
Device Serial Number: 2230FG45A0
Device Model: DS920+
DS Token : md5_rec(2230FG45A0)
API-KEY: 9a8yva45jxzer26j23r..
AUTH-KEY: 8abc54f51is1js2b129..
Device Alias: MyNasAlias
Device ID: QuickConnect ID Number
The last thing we need to get before we could authenticate on behalf of the device and steal its tunnel connection is the Device ID (Server ID). To get this identifier, we found an API on global.synology.com/Serv.php that would gladly return information about the device including the Device Identifier if we will send the register command. This vulnerability is tracked as ZDI-23-659.
Device MAC Address: 90:09:d0:01:23:45
Device Serial Number: 2230FG45A0
Device Model: DS920+
DS Token : md5_rec(2230FG45A0)
API-KEY: 9a8yva45jxzer26j23r..
AUTH-KEY: 8abc54f51is1js2b129..
Device Alias: MyNasAlias
Device ID: 123456
Now we have all we need to authenticate as the device impersonating it and stealing its tunnel connection. Here is the full process to obtain all the information:
Finally, we are able to impersonate the device and now we want to update on our “new” IP address so the next time the victim connects to their device they will reach our machine.
The way to do it is by sending a valid update_network command to dec.quickconnet.to/Serv.php with the device's new IP address: pointing to the attacker's machine.
Essentially we are functioning as a Synology NAS, impersonating the victim’s device. So we are getting all the requests from the user including the authentication HTTP request and the credentials. Furthermore, we can communicate with the device in the LAN so we now act as a MiTM between the user and the real device.
So by using simple regex, we retrieve the tokens from the requests. To impersonate the user, we must steal two identifiers: the X-SYNO-TOKEN and session ID (ID parameter in the request).
With these two identifiers, we can perform requests on behalf of the user.
With the tokens in hand, we can use legitimate functionality on the NAS to enable its management SSH service. Then, we can add another backdoor user to the system, and connect to the device using our new user. We now have an SSH shell on the device, with the ability to execute arbitrary OS commands.
Our research into Synology’s NAS and cloud communication channels led to the discovery of a handful of vulnerabilities that allowed us to impersonate a Synology device as it connects to the cloud, and redirect users to a device under an attacker’s control.
Such a scenario puts all user data stored on the NAS devices at risk. In some cases, we could also remotely execute code on the device, gaining complete control.
As with our research into Western Digital’s NAS and cloud service, weak device authentication based on publicly known information rather than secrets was the key issue. We could use this to impersonate Synology devices and redirect users to an attacker-controlled device, allowing us to steal credentials and access data stored on the devices. This issue may not be limited to Synology and WD, and likely affects many vendors and platforms.
These vulnerabilities are severe, and we wish to acknowledge Synology’s cooperation and collaboration in acknowledging these flaws and fixing them in a timely manner. These vulnerabilities were disclosed during Pwn2Own Toronto, and we also wish to acknowledge the Zero Day Initiative’s role in fixing these issues that put the data of millions of users at risk around the world.
https://www.synology.com/en-global/security/advisory/Synology_SA_22_23
https://www.zerodayinitiative.com/advisories/ZDI-23-658
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, a local attacker can escalate their privileges in the system which could allow for arbitrary code execution with root permissions.
Update to Access Commander version 3.2.
CVSS v3: 4.7
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, an Insufficient Verification of Data Authenticity vulnerability could allow an attacker to escalate their privileges and gain root access to the system.
Update to Access Commander version 3.2.
CVSS v3: 6.3
CWE-22 IMPROPER LIMITATION OF A PATHNAME TO A RESTRICTED DIRECTORY ('PATH TRAVERSAL'):
In 2N Access Commander versions 3.1.1.2 and prior, a Path Traversal vulnerability could allow an attacker to write files on the filesystem to achieve arbitrary remote code execution.
Update to Access Commander version 3.2.
CVSS v3: 7.2
CWE-290: AUTHENTICATION BYPASS BY SPOOFING
Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 7.5
CWE-306: MISSING AUTHENTICATION FOR CRITICAL FUNCTION
A vulnerability exists in Snap One OVRC cloud where an attacker can impersonate a Hub device and send requests to claim and unclaimed devices. The attacker only needs to provide the MAC address of the targeted device and can make a request to unclaim it from its original connection and make a request to claim it.
OvrC Pro: All versions prior to 7.3 are affected.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 9.1
