Take control over Synology’s OAuth Service

Dominik
3 min readJan 29, 2020

That’s a rather curious story. Usually the scenario is to gain control over a closed system to access some of their resources. This is about using the hacked server as security feature (identity server). Even if there are simpler scenarios better suited for productive use.

So what’s the background? Synology somewhen decided that a Voice Assistant integration of their NAS’s Audio Station might be a fancy thing. They chose Amazon’s Alexa, which in turn required (in their chosen “remote” setup) an OAuth 2 server.

First warning: they implemented just what they needed for exactly this scenario:

  • The Implicit Grant, which is flawed by itself.
  • A CLI toolset to work with the sqlite database.

They do have a proprietary authentification standard, if you’d like to go the official route, develop a new application and are fancy about not using industry standards.

Since they’ve introduced the OAuth Service, preinstalled on each DSM, without further explanation or use, people gone wary about the present. Most just uninstalled it.

A virgin DSM, essential Services and OAuth

Some knew their trade and the theoretic usefulness of the service, but without a (helpful) manual or accessible interface about how to register a client service …

no help from GUI

Asking synologys support didn’t help either.

But, as I’ve had some basic knowledge from synology’s package setup and unwill to accept that half-baked solution, i had to dig into that. Either till the unwill transforms into desinterest and resignation, or till that flag is captured. (Spoiler: its actually quite easy).

Long story short:

  • you’ll need SSH access
    enable the service, connect, get root access with sudo -i
  • find the packages location
    /usr/local/packages/@appstore/OAuthService/
  • examine the sqlite database (copy onto a client computer)
    /usr/local/packages/@appstore/OAuthService/etc/oauth.db
  • examine the binarys at hand
  • (as i didn’t mind to look for a up to date IDA): play with the commands and parameters of oauth_clientinfo

And after some failed attempts, I’ve added another client into the database.

Last question: how to use that. This one has been even more tricky as finding the tools (or database, which would have been fine too).

As Synologys use is the Alexa integration, i’ve tried to setup that and get to the OAuth Login page in that process. That has proven to be quite a challenge, as using other DDNS providers, custom certificates, missing some prayers, … breaks to process and synologys backend isn’t able to check the availability of the OAuth service, and consequently doesn’t bring it up front to the user. There’s some discussion about that in their forum.

After some fiddling with it, the services found each other, and I’ve got hold of the OAuth URL:

https://yourDSM.domain.demo:5001/oauth/oauth_login.cgi?response_type=code&redirect_uri=https%3A%2F%2Fmedium.com%2Foauth_return_url&state=someStateThatsIncludedInTheCallback&client_id=5f78ed05b4694c55a48b59664c99ecea664e934ea40e40308a19810766ba1a54&scope=SomeUselessScopeIGuess

If a second factor is configured, you’ll have to provide it in the next screen, after that the handoff to the redirect url happens.

For very small companys, home use and lab setups, that might be enough. For professional use: please forget everything detailed till here, go to https://www.keycloak.org/ , get used to the UI with their online courses, and deploy the docker container in your environment.

You’ll be done within an hour and have a versatile, multi-protocol, secure, scalable, … solution.

--

--

Dominik

Developer, Student, Coding, Security, Privacy, Independency, Travelling. Priorities shift between all of them.