Статья When Backups Open Backdoors

[stihl]

​

TL;DR​

We discovered a leaked credential that allowed anyone unauthorized access to all Microsoft tenants of organizations that use Synology’s Для просмотра ссылки Войди или Зарегистрируйся (ABM). This flaw could be leveraged by malicious actors to obtain potentially sensitive information — such as all messages in Microsoft Teams channels. It was reported to Synology and tracked as Для просмотра ссылки Войди или Зарегистрируйся.

This blog post contains the full technical walk-through and discovery of the vulnerability, its impact, and our experience during the responsible disclosure process with Synology.

The standalone disclosure report is available on our Для просмотра ссылки Войди или Зарегистрируйся and potential Indicators of Compromise (IoC) are provided Для просмотра ссылки Войди или Зарегистрируйся further below.

---

Background​

During a red-team engagement against a customer’s Microsoft Entra tenant and Azure infrastructure we came across an application named Для просмотра ссылки Войди или Зарегистрируйся.

The application had broad permissions — such as read access to all groups and Microsoft Teams channel messages — making it an ideal target to obtain information that may be useful for further attacks (i.e. credential abuse or Для просмотра ссылки Войди или Зарегистрируйся).

To analyze it, we created our own lab environment consisting of a Для просмотра ссылки Войди или Зарегистрируйся and the ABM add-on installed within Synology’s Для просмотра ссылки Войди или Зарегистрируйся (DSM) operating system. For research purposes it is not necessary to have a Synology NAS appliance, as the entire OS can be Для просмотра ссылки Войди или Зарегистрируйся. We also built some tools along the way, which can be helpful to reverse engineer Для просмотра ссылки Войди или Зарегистрируйся. We will share them for other security researchers on Для просмотра ссылки Войди или Зарегистрируйся soon.

About ABM​

Synology is best known for its network-attached storage (NAS) solutions, marketed as backup servers for private or business use. “Active Backup for Microsoft 365” (ABM) is their free software add-on developed for the DSM. It offers integration with Microsoft services, such as OneDrive, SharePoint, Exchange Online and Microsoft Teams, to perform automated backups. With over 1.2 million installations, the add-on sees broad adoption among organizations that are transitioning to cloud-based workloads.

Synology DSM Package Center – ABM add-on page​

Setup​

After installing ABM, the user is guided through a setup wizard, which is designed to link the NAS instance to their respective Microsoft tenant. This is the most interesting aspect of the Для просмотра ссылки Войди или Зарегистрируйся, as it facilitates the access to an organization’s data in the cloud.

High-level setup procedure:

1. Login & Consent – The wizard sends the user to the Microsoft login portal where they sign in, and are prompted to grant admin consent for ABM’s requested permissions within the tenant.

ABM permissions admin consent prompt for the organization​

1. Handoff – After confirmation, an OAuth login through the ABM application is performed. Microsoft hands off the user and their resulting authorization details (the auth code) to a Synology middleware service, which then forwards everything back to the user’s NAS instance.

Synology middleware ("SynoOauth") – NAS instance redirect prompt [redacted for display]​

1. Finalization – The ABM add-on on the NAS exchanges the user’s authorization details for a Microsoft Graph API scoped access token at the organization’s Microsoft OAuth endpoint to finalize the setup.

General ABM setup overview​

Sidenote: The user is also required to activate the add-on with their Synology account after installation as part of the setup procedure, for which further details are skipped in this post.

Technical Concepts & Context​

Before diving into the details of the vulnerability, let’s take a step back and cover a few basics related to the Для просмотра ссылки Войди или Зарегистрируйся.

Identities, Applications, and Permissions​

The ABM add-on leverages the Для просмотра ссылки Войди или Зарегистрируйся, allowing companies like Synology to publish Software-as-a-Service (SaaS) applications that users access through their Microsoft account. These accounts are managed by the dedicated Microsoft tenant of an organization, which is a trusted cloud instance of Для просмотра ссылки Войди или Зарегистрируйся. Each tenant stores and manages all organizational data across Microsoft 365 services, like Microsoft Teams.

ABM is published as a multi-tenant application by the Synology tenant, enabling other organizations to “install” it within their own. The application properties, such as authentication settings, are globally defined by the “app registration” of the publishing tenant. Whereas each consuming tenant maintains a local representation known as a “service principal” — determining the application’s effective permissions within that tenant.

Simplified Microsoft Entra multi-tenant application concept (ABM)​

Permissions granted through consent — either by individual users or the organization’s administrators — determine the actions an application can perform against APIs such as Для просмотра ссылки Войди или Зарегистрируйся. These permissions can be of type delegated (signed-in user required) or application (may act independently). Therefore, authenticating as either a user or the service principal of an application grants access to the tenant’s protected data. ABM is configured to request both types of permissions, including privileged access such as reading Для просмотра ссылки Войди или Зарегистрируйся (Group.Read.All) as well as Для просмотра ссылки Войди или Зарегистрируйся (ChannelMessage.Read.All) via application permissions. As such, when ABM is setup for the first time, an organization’s administrator must grant those requested permissions for their entire tenant.

However, we will later learn why granting those privileges to ABM is a fatal mistake.

Authentication​

After ABM is installed and consented to within the tenant, an Для просмотра ссылки Войди или Зарегистрируйся login through the application is performed. This lets third-party applications authorize the logged-in user against the configured APIs via an authorization code issued by Microsoft. This code is then relayed to the ABM add-on on the respective NAS instance where the setup was initiated from.

Now, you might still be wondering how it is determined as to where exactly the authorization details should be returned to in the first place. As noted earlier, the setup process involves a middleware component that acts as a broker between Microsoft and the NAS instance. When the OAuth flow is initiated, the location of the NAS (DNS hostname) is included as part of the redirect URL. After successful authentication, Microsoft forwards the user to the aforementioned Synology middleware service (a web application at synooauth.synology.com), which uses the URL to facilitate the hand off to the NAS instance.

Data Access​

After receiving the authorization details, the ABM add-on exchanges it for access tokens at the respective user’s tenant. This allows the user to complete the setup procedure as Для просмотра ссылки Войди или Зарегистрируйся, by following up with registering a dedicated app registration within the organization on behalf of the authenticated user. Subsequently the actual backup tasks are performed through this access.

The Vulnerability​

With these technical concepts in mind, we can get to the actual vulnerability. The flaw itself is surprisingly trivial, and specifically involves the granted application permissions of ABM and the Synology middleware component (SynoOauth) utilized during the setup process.

In our analysis of ABM we examined our browser’s network traffic during the setup, and noticed something peculiar in the HTTP response of the redirect from the middleware component to our NAS instance:

HTTP/2 302 Found Location: [...]/activebackupoffice365-cgi.cgi?action=oauth &graph_refresh_token=1.Aa4ABLPUicJgkEm4oYYv[...] &resource=https%3A%2F%2Fgraph.microsoft.com &client_id=b4f234da-3a1a-4f4d-a058-23ed08928904 &client_secret=ARI8Q%7EsHOuwMoX.[...]

SynoOauth middleware – HTTP 302 response redirect containing OAuth information [truncated and redacted for display]

Did you spot it? The response includes several parameters within the Location header, one of which is a value for client_secret. But we logged in to ABM through a user account of our Microsoft tenant using OAuth code flow, why would there be a secret credential for an application?

Secret credential exposed in response redirect of SynoOauth middleware during ABM setup​

We initially assumed that we might have overlooked a network request — which would register an application with client credentials within our tenant — but we were surprised that this was not the case. Remember, the full installation procedure does in fact mandate creating an app registration within the user’s tenant, but this is not initiated until the flow reaches the NAS instance to complete the setup.

When we verified that there was no such application created within our lab tenant, an uneasy feeling came over us that the exposed secret might belong to something else…

Discovery​

To test whether the credential was actually valid at all, we sent the following HTTP request to obtain an access token for the ABM service principal from our tenant’s OAuth endpoint:

curl -X POST Для просмотра ссылки Войди или Зарегистрируйся<TENANT_ID>/oauth2/v2.0/token \ -d "grant_type=client_credentials" \ -d "client_id=b4f234da-3a1a-4f4d-a058-23ed08928904" \ -d "client_secret=ARI8Q%7EsHOuwMoX.[...]" \ -d "scope=Для просмотра ссылки Войди или Зарегистрируйся"

cURL command demonstrating the Для просмотра ссылки Войди или Зарегистрируйся to retrieve a Microsoft Graph API access token for the ABM service principal using the client

credentials [redacted for display]
And… we were surprised that it worked:

{ "aud": "Для просмотра ссылки Войди или Зарегистрируйся", "iss": "Для просмотра ссылки Войди или Зарегистрируйся<TENANT_ID>/", [...] "app_displayname": "Synology Active Backup for M365", "appid": "b4f234da-3a1a-4f4d-a058-23ed08928904", [...] "idtyp": "app", [...] "roles": [ "Group.Read.All", "ChannelMessage.Read.All" ], [...] }

Access token (JWT) showing granted application permissions for Microsoft Graph confirming validity of the secret credential [base64-decoded and truncated for display]

Impact​

So, what does this mean? Remember that we went through the concept of multi-tenancy and permissions earlier, and that by default, ABM requests tenant-wide application permissions to access all Teams channel conversations and group data.

Well what if the secret is not actually a credential for a service principal in our tenant but that of the app registration in Synology’s tenant? To verify this, we also tried the credentials with the tenant of our customer during the red-team engagement (to which we had only guest-level access up until that point), which shockingly worked just the same.

And indeed, it turns out that the credential belonged to Synology’s ABM global app registration in their Microsoft tenant. What’s even worse is that this means that their middleware service had been inadvertently exposing this credential during every setup.

As previously mentioned, the add-on had been installed over a million times, meaning that we had discovered a serious backdoor into a lot of organization’s Microsoft tenants and their cloud data through the Synology published application. This ultimately allowed broad read-only access to:

• List and read all groups and their properties, including memberships and their Microsoft 365 content such as Outlook conversations, calendar and events, etc.
• List and read all public and private Teams channel messages (not group chats), including replies and embedded content such as images or cards

Attack scenario leveraging the ABM application secret to access an organization's cloud data​

One could also imagine scenarios where malicious actors exploit such access for industrial espionage, ransomware preparation, or selling sensitive data on underground forums.

Crucially, exploitation requires no prior foothold in any target’s Microsoft tenant, as simply observing the leaked secret from the SynoOauth middleware once is sufficient. Thus, for an unknown period of time, anyone could have obtained this secret to compromise organizations that use ABM.

Sidenote: What’s even more confusing is that the secret is never actually used within the setup, whether in the tenant nor add-on in DSM.

The Cloud​

Before we dissect the disclosure process, it is worth pausing to reflect on what this tells us about cloud-based services.

Cloud providers and managed solutions promise advantages like easier server hosting and running certain services, yet this convenience often substitutes the complexity of operating with that of configuring (i.e. securing) everything correctly. This complexity increases with the number of components that you integrate, which inherently expands your attack surface. Supply-chain issues, like the one discussed in this blog post, are a textbook example of how this is becoming increasingly prevalent. For that reason, it is important to ensure that you do your best in all aspects over which you still have control; such as implementing appropriate logging, monitoring, and detection capabilities across the organization, as well as realizing the Для просмотра ссылки Войди или Зарегистрируйся.

Managed cloud services differ substantially from traditional, self-hosted solutions, primarily because vulnerability disclosure is often opaque or absent. Since the vendor is responsible for fixing any issues, users often remain unaware of vulnerabilities that may exist or have existed. This might seem desirable from a customer point of view, but it feeds into a bigger issue. When vendors silently update, their users will never learn that they were vulnerable in the first place, as they did not (have to) disclose that. Additionally, there would be no way to properly evaluate the vendor’s security posture, i.e. by how many vulnerabilities there have been in the past, especially concerning how long it took to fix them. This typically means that no CVE is assigned specifically in cases of cloud vulnerabilities.

Recognizing this, industry leaders such as Microsoft have started Для просмотра ссылки Войди или Зарегистрируйся by calling upon providers to disclose vulnerabilities even in fully managed cloud-based scenarios. We share this sentiment and have explicitly requested Synology (Для просмотра ссылки Войди или Зарегистрируйся) to assign a CVE during our disclosure. Synology seemingly concurred and assigned Для просмотра ссылки Войди или Зарегистрируйся for the vulnerability. We want to highly commend them at that point, but the subsequent disclosure process is unfortunately where the good part ends…

Disclosure​

Following our standard Для просмотра ссылки Войди или Зарегистрируйся, we reported our finding to Synology on April 4th 2025, while also explicitly requesting CVE assignment. They acknowledged and confirmed the vulnerability and informed us that CVE-2025-3695 (note: a different one at first) had been reserved, while also working on a fix. However, from here on the communication mainly involved discussions about the discrepancies in the assessment of severity and scope.

In a follow up email, Synology had determined the details of the CVE and stated that they had come up with a CVSS score of 6.5 (severity "Moderate"), a big step down from our proposed 8.6 (severity "High"). The main difference in their calculation being the metrics “privileges required” (PR) from None to Low, and the “scope” (S) from Changed to Unchanged. We explained that these changes did not reflect our assessment of the issue, which made us question whether the vulnerability was understood correctly by Synology in the first place. This doubt was further raised by the bug bounty amount they wanted to “reward” us, as they initially assumed that our report was submitted as part of their Для просмотра ссылки Войди или Зарегистрируйся. However, since we generally deny accepting the restrictive nature of bug bounty conditions (i.e. restriction of publication), we clarified that we submitted following industry practice responsible disclosure, and declined their offer of ~$417 for the report.

We further emphasized that it is trivial to obtain the secret, as an attacker does not require any “special” privileges for neither Synology’s middleware component nor any target’s Microsoft tenant. This circumstance clearly demonstrates the Для просмотра ссылки Войди или Зарегистрируйся, as the exploited vulnerability affects data within entirely different security boundaries — namely all organizations’ Microsoft tenants, not just Synology’s own systems.

Despite our attempts at clarification, Synology would not consider our arguments further. Later it came to our surprise that they maintained their own assessment, as they Для просмотра ссылки Войди или Зарегистрируйся without informing us. In our opinion, apart from severely lowering the impact rating, they opted to be vague in the abstract of the vulnerability:


Excerpt from the advisory of Synology's description of the vulnerability
This description omits all the interesting details, such as which and how “sensitive information” could have been accessed. It also makes it sound like the requirement for an attacker to authenticate somewhere would constitute a security boundary. In reality, malicious actors could trivially compromise all users of ABM by leveraging the publicly exposed credential.

To our knowledge, Synology also has yet to inform impacted users of this attack vector having potentially been exploited. Apart from publishing the advisory which states that customer action is not required, we believe that a more informative notice i.e. containing Для просмотра ссылки Войди или Зарегистрируйся would have been more appropriate. Therefore, we independently provide a few of those in this post further below.


Для просмотра ссылки Войди или Зарегистрируйся