Okay, hello everybody, and welcome to our DEF CON talk, a pain in the NAS, exploiting
cloud connectivity to porn your NAS devices.
So my name is Noah Moshe, I'm a vulnerability researcher in Clarity Team 82, and with me
today is Sharon Brezinov, our director of research.
And as you can see behind us, this is our playground, this is where we have fun.
We mainly look at IoT and OT products, be it PLCs, HMIs, and of course, like I'm going
to showcase to you today, NAS devices.
And our job is basically breaking them and looking for cool vulnerabilities, which let's
say it's heaven in life.
Of course, we'd like to make huge thanks to the other Team 82 researchers that helped
us in this research, Uri Katz and Vera Menz.
Huge thanks to you, and you guys rock.
So let's talk about what we're going to showcase to you today.
You see, I have a NAS at home where I store all of my spicy content, like for example,
my documents, the, of course, government stuff, and some kind of pictures, let's say.
And that's why when Pwn2Own competition in Toronto last year decided to do the NAS category
where the goal was to hack and exploit remote code execution vulnerabilities on these NAS
devices, which one of which I actually own, I said, yeah, let's do it, and let's go all
in.
So let's take a look at how we own both of these devices.
You see, we try to look at kind of esoteric features, because both of these NAS devices
were quite old and looked at by different research groups over the years.
So we try to look at what kind of interesting stuff can we look at that maybe other researchers
less likely put the effort and time into.
And that's when we realized that actually both of these NAS platforms have cloud platforms,
allowing users to actually access and use their NAS remotely through the cloud.
In the case of Western Digital, it is My Cloud OS 5, and in the case of Synology, it is
Quick Connect Cloud Services.
Now I ask myself, what's the use case here?
Why should I enable my cloud, my device to connect to the cloud?
And actually, that's the reason.
You see, my NAS sits at home where I save all my important stuff to it, and I am out
and about.
I could be at work, I could be on a vacation, et cetera, however, I want to access my files
now.
So that way, through the cloud application, I am trying and requesting my files and fetching
them remotely.
But when I saw that this is the use case in business logic, I thought to myself, hey,
maybe we can use it somehow and have attackers access the files we save on our NAS through
the cloud, not requiring direct access.
Somehow they can request and fetch the files and get hold to my sensitive data.
And that is exactly the kind of ability we gain.
In the months leading to Pong 2.1 competition, where we were able to access, read, and write
every file that was stored on a NAS device worldwide.
And you can imagine the catastrophic implications of it.
I shouldn't say seeing sensitive files, of course, and maybe altering them somehow.
However we thought to ourselves, yeah, that's cool, however, what could be cooler?
I mean, fetching files is cool, however, the holy grail is actually executing code
on the NAS device.
So I can access the NAS devices through the cloud, meaning somehow I am able to access
people's home network through the cloud application.
And as it turns out, this is exactly the kind of vulnerability chain we exploited in
the Pong 2.1 competition, netting us $40,000 and, of course, chaining five different vulnerabilities
to attack cloud, the NAS devices.
However, since our attack leveraged the cloud, we were able to not attack just one device,
but instead we could attack everything.
We could, for instance, attack any cloud connected device, giving us access to billions, millions
and millions of different devices worldwide.
And actually the vulnerabilities we uncovered were so severe that Western Digital had to
boot off devices running all frameworks from their cloud access.
Meaning if you are not patched and no longer vulnerable to the vulnerabilities we discovered,
you can no longer access your device through the cloud.
This is because we identified some architecture flaws that had to be changed.
meaning all devices can no longer connect to the cloud services. Well, that is the gist of our
research, so I hope it intrigued you, but let's doop dive and see how we uncovered all of these
vulnerabilities and what kind of vulnerabilities we actually managed to achieve. So let's start
with Western Digital. In the Pwn2Own competition, we looked at Western Digital PR4100. This
is the cutie right there and it is actually a custom Linux based machine running x86 64 bit
processor and inside this machine, many services are running. Of course, we have the usual
suspect, the web management port where most of the prior vulnerabilities were discovered.
However, since it is a NAS device, a lot of file fetching and file accessing services also
exist, like SMB, FTP, and of course, accessing the files of other devices. So let's take a look
at some of theاي
of the HTTP requests. Well the first thing I did was order the device, however, I'm a very
impatient man, I could not wait for the postal service to get my device to me. That's why I went
to the Western Digital website and looked for a firmware download. When trying to emulate my
device and getting access to it even before it arrives, usually when we work with filmwrecks, there
are two options. Either the firmware is encrypted, meaning everything is encrypted somehow and the
the device decrypted during runtime and during the upgrading process, or it is simply unencrypted
and containing all of the different sections within the firmware. Luckily for us, Western
Digital chose to not encrypt the firmware, meaning we add access to all of the different
files, file system, binaries, configurations, et cetera, that are running inside our NAS
device. Sadly, this firmware was not a full-on file system, meaning we had to pick and choose
and reconstruct the file system from the different sections. That is because all of the
different sections contain different files for the file system. However, they were not
organized and not in the corresponding places. Luckily for us, we looked at the few files
inside the firmware and we found an init script that actually reconstructed the firmware for
us. This script is being ran whenever a firmware upgrade procedure happens and then using a
virtual machine and a true device, we were able to reconstruct and reboot the firmware.
And run the web services. We now had access to the NAS device even without ordering it and this
actually gave us two main benefits. First of all, I was more well-versed. I knew what kind of
services were running, what were all the configuration files, what binaries are actually
being executed, and even more important, I had a playground that I could break. I tend to break
devices that I look at and my boss has to reorder ones and he gets mad at me, especially when
they are super expensive. So now I have a free software that I can use to run the web services.
I have a playground, I can just do whatever I want. If I delete the whole file system by
accident, which I did in a few researches in the past, no problem, I'll just boot up to the
latest snapshot. Well, let's take a look at the first part we looked at, the web management
architecture. This is the gist of it and let me explain to you. As I told you before, this was the
main focus of researchers in the past where multiple vulnerabilities in the PHP and CGI scripts
were found and identified and actually exploited in the point-to-own competition. In order to
remediate it, Western Digital had a genius idea of just wrapping it all up in a Golang binary that
actually authenticates and authorizes any request performed to the back ends. This meant that
even though we did, and yeah, we did find a few vulnerabilities and remote code execution
vulnerabilities in the web server, since every request had to be authenticated, it was not that
useful in the point-to-own competition.
Every request, every exploit should be authenticated. This meant that we had to scrap this
entire lead and look for new leads somewhere else and that's when we turned our heads into the
cloud features of the system. You see, the cloud features, especially in Western Digital case, are
very, very opted in and prompted to users to enable them. It is actually in the name of the
device, My Cloud, and most of the users actually enable this feature and are able to access their
files through the cloud services. All you need to do is enable this tick and box right here, which
you are encouraged to do by Western Digital User Interface, and then using an account, a cloud
account, you are able to associate your account with your NAS device and now are able to access it
through either the mobile application or the web application of your choice. However, when we
realized that, we thought to ourselves, how the hell does this magic happen? How am I navigated and
routed to my NAS?
Well, like I've told you before, whenever I'm using the Western Digital application, I am
authenticated to my account and before I create my account, I associate it with my NAS device. Now,
each NAS device is identified by a unique GUID installation and that way, whenever I try to, let's
say, access files, I specify my GUID to Western Digital's cloud services and then behind the
scenes, somehow, they route my request to my account. So, that's how I can authenticate my
connection with my NAS device to my corresponding NAS device and the disk tunnel is created.
However we thought to ourselves, what would happen if some attacker knew my device is GUID and
would try to use the API routes and URLs to access my NAS device? Well, we tried that and it
didn't work, so it's not that easy. However, since we tried it on our device, we opened TCP
dump in the background and we noticed something weird. You see, the request was made to our
device meaning we reached it and instead of being blocked by the cloud application we were
blocked by the NAS meaning we actually reached one of its internal ports. Now this is quite
crazy because my NAS sits at home. It is not internet exposed. It doesn't I didn't open any
ports in the firewall and it doesn't have an external IP address meaning somehow through
Western Digital servers I was able to access my home network my LAN home network and
access one of the internal services that are running there in my NAS device. When we realized
that our game plan was quite simple. I mean all we need to do is just know a device's grid which
is 128 random bit grid find somehow some authentication bypasses and exploit some
vulnerabilities to run code on our device. Yeah pretty easy. So let's try and understand what is
the use case once again. You see these
is the regular use case in the NAS architecture. It's a user trying to access their NAS from
anywhere around the world. However Western Digital also thought about another use case. What
happened when the user sits at home like so for example sitting on couch and wanting to access
their spicy movies. Well if they were able to access if they needed to actually fetch the files
over the cloud it means that there will be a lot of latency and bad user experience and that's not
actually very.
smart. So instead Western Digital implemented this procedure right here. Whenever a user
sits at home they are redirected to their NAS device and then fetch files locally over the LAN
access. However, somehow Western Digital had to make sure that the users were accessing a real,
the real device and not let's say an attacker. How did they do that? Well, in order to do that
Western Digital actually issued a unique certificate to each device and that way whenever I
try to access it I am able to make sure and check that I am indeed accessing my real device.
However, the keen-eyed in you probably noticed something weird. What is that? As you can see
embedded in the certificate here it lies my device's GUID. This means that by simply fetching
and accessing my device through the HTTPS services I am able to get the device to my device
certificate and carve out the GUID through it. While this was pretty cool sadly our attack
scenario involves not being able to access the device meaning we want to access it through the
cloud so it's not pretty practical but maybe somehow we can improve it. Well, that's when we
turn our heads and realized and try to realize how the hell does this redirect work? I mean how
does this message happens? Well, you see Western Digital actually added a DNS name for
each NAS device and that way whenever I'm in local network it tries to access this DSS name.
And this DSS name actually maps to an internal IP address of my device. That- as you can see I can
use NS lookup on my devices name and that way when the result I see the internal IP address of my
device and that way I'm able to access it locally through the LAN interface. However, this meant
that the DNS record was created and because it was created of course this message is not being contains.
we can exploit it and that's why using passive DNS servers we were able to retrieve all the DNS
queries. You see some DNS servers actually sell the metadata of user requests uh that are
performed to their DNS servers to the highest bidder and sadly in the internet there are a lot
of APIs and servers that allow users to search for all DNS queries user performed uh in order
to basically get access to what kind of DNS queries user used and because we the GUID is in
this DNS record we are able to retrieve it and as you can see it's not a one off we actually see
tens of thousands of different DNS records meaning we now had access to tens of thousands uh
uh GUIDs. Sadly when we tried accessing uh actually accessing these GUIDs through Western
Digital's cloud most of them were already uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh
already dead and not disconnected. That's because we don't know when the DNS record was
created and there were no logins connected anyways. Uh this meant we no didn't actually have
ten thousand records. However we had a good lead into actually proving the amount of the uh
GUIDs we know of. That's when we realized that because the certificate is issued to every
device every connected device and this certificate contains the device GUID maybe we can use
what's called certificate hash. So let's say we have a certificate hash and we have a certificate hash
harvesting. Similar to the passive DNS servers there are a lot of servers uh offering the
ability of you to users to look for say certificates they encounter and look for patterns uh in
the certificate name. For example we use census which boasts they have over six billion
certificates in their databases allowing users to query and fetch these certificates. When we
tried and grabbed for Western Digital pattern we realized something shocking. There was over
one point five million devices just in the database. Uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh
and each of the devices could can use access to Resources within the last three months. And now
we had the knowledge of every one of these devices GUID. Meaning we were to access them through
Western Digital eh uh cloud platforms. However sadly in the point on competition you have to do it
live. Meaning we cannot ah know the GUID in advance. And our device is connected in real-time.
This meant we had to somehow get access to GUID. And get knowledge of GUIDs in real-time. That's
when we discovered something pretty cool which I wasn't aware of in the past which called- which like Ah
which is called is written in old-school currencies. Er exit code and my Find Wades account ownership
CTL, Certificate Transparency Log. You see, there was kind of a specification called CTL in the
internet with the goal of improving security and visibility in the internet. What CTL means is
that whenever a certificate authority, a CA, issues a new certificate, it sends the metadata
about this certificate to a live public feed allowing users to simply subscribe to this feed
and get knowledge of the certificate being issued, issued mainly the certificate CN and of
course the validity date, etc. Luckily for us, there are many tools that enable us to
subscribe to the CTL feed and using them we were able to subscribe to the CTL feed and grab for
Western Digital Pattern and that way we were able to get devices, GUIDs, whenever they actually
connected to the network in the first time. Meaning we had the ability to leak GUID and leak
knowledge of the devices GUID in real time whenever it connected. And we simply did it for a few
days and we actually got amazing results, getting us tens of thousands of different devices GUIDs
which we were able to access through the loophole and through the exposed APIs in Western
Digital's cloud services. Cool. That meant that instead of breaking a device's GUID, we simply
leaked all of them and we now had the knowledge of every device GUID worldwide. The next thing we
had to do is...
find some kind of an old bypass. Well, since we are a community in our role, we simply asked
someone, hey, can we ask, can we use your device? We promised not to break it and luckily we
didn't, uh, so we didn't have to buy him a new one. Uh, so we tried basically accessing the
device's GUID using our own authenticated account. So all we did was simply open up our web
browser, connecting to our account and simply stop the request and ch- change the device's GUID
from our own to the GUID we wanted to test our theories on. And that's when we realized that some
API routes actually worked. As you can see here, we are fetching a file ID of a device we do not own
and are not associated with. All we did was simply change the GUID and some API routes just
worked. That's pretty crazy and pretty lucky. As it turns out, Western Digital only checked for
authentication instead of authorization. Meaning as long as I have a valid user ID, I'm not going to
use a session and is connected to my account, I can access anyone, NAS, through some API routes by
simply changing the device's GUID. That meant we now had access to everyone's sensitive files. We
could, for example, view them, change them, leak them, do whatever we want and that's pretty cool.
Yeah, that's pretty lucky. However, there are a lot of things that we can do. Uh, one of the things
is down for the team. Unfortunately, when they checked people's IP addresses in the
which was pretty sad because it took, uh, many months of, uh, work down the drain and we just had to find
some new vulnerabilities. That's when I said, oh, fuck. I'll have to do some overnight. And, yeah,
let's go again.
Well, since I exhausted the API routes lead I thought to myself yeah I need to go back to the
source and look for the main binary handling cloud connection. In Western Digital case it
was a binary called rest SDK. This binary actually binded on the device and connected to
Western Digital proxy servers and handled most of the cloud functionality like fetching files,
changing files, etc. Sadly this binary is written in Golang which I personally hate because
it's huge. It has tons of different functions and tons of different layers of abstraction
making reverse engineering pretty sad and boring. And of course since it's written in Golang
there is less attack surface because the memory is managed by Golang itself. A lot of APIs are
secured by default and there's less error place for developers to make mistakes. So,
in order to avoid reverse engineering as much as possible all I had to do was simply create a
meta middle setup between me and the device, between the device and the cloud. Meaning
whenever the cloud tries to interact with my device or vice versa I will be able to view the
traffic and see what's happening behind the scenes. We did it through many methods mainly
adding a certificate authority CA that we control on the device locally and that way we could
basically man in the middle HTPS requests just making the device trust RCA and issuing
device certificates on the fly. However, that way we were able to view and see the requests in
real time and see what's happening at any time whatsoever. And when we threw when we had this
ability our first goal was simply understanding how the hell does the tunnel pre-proxy
creation happens. How my device connects to the cloud and informs it, informs the device
hey I'm this and that device please redirect users to me. And through the process of man in the
middle and reverse engineering we reached this conclusion. The first thing happened that
happens is my device connecting to Western Digital Proxy servers over TLS connection. The
minute the device connects the cloud says hey cool I want to create a proxy connection and
fetches in HTTP to an API route on my device. The API, my device connects to the cloud and
then says yeah okay I'm ready to connect and simply hands over the device's GUID saying hey I'm
GUID please connect me. Then the cloud says great let's connect and the tunnel is created. Now the
minute we saw that we were like wait what the fuck? Where the hell are the secrets? I mean the
end all the end any all the things that my device sent to the cloud was my device's GUID which
like I've showcased to you before is goddamn.
This is a public knowledge meaning it is actually exposed on my device's certificate. This meant
that by simply knowing the device's GUID we could try and impersonate it and that is exactly what we
did. Meaning we went to Western Digital Proxy servers and simply connected saying hey I'd like to
connect I am this and that GUID. And the minute we did that the server actually trusted that and
said yeah I'm ready to initiate the connection and disconnected the real device. So this is a
орal VR- sustaining work mode so this is the interactive live office presentation and saying
hand side of the device. Meaning that whenever a user tries to connect to it through the device
now they would be redirected to us. That is pretty crazy because now we were able to impersonate
the device and act as this. However what was even crazier was what happened next. You see the
minute we authenticated and created a tunnel. This request reached us. As you can see this is an
HTTP request from the client saying hey I wanted refresh the 와서 that I would like to try to give
volumes on my NAS device. However what's crazy is that it actually contains the user
authentication token. We didn't we were actually pretty stumped at first saying yeah we
didn't make this request. However upon further investigation we realized that in order to make
sure everything is up to date and uh users have good user experience Western Digital
performs background app refresh meaning constantly in the background the API the client
connects to the NAS and says hey please refresh the files and give me access to my newer
files and because of that a new request is made every 10 seconds or so. This meant that
whenever the minute we stole a device's tunnel uh we got a request from the user containing
the user token and this actually meant that the minute we stole device's tunnel we have
authenticated administrative tokens to that device. This meant that once again by
impersonating the device we could
access everyone's file around the world giving us full administrative access to every NAS
device Western Digital employs. Yeah that we actually did it we actually got this
access twice in two months which I think is a personal record for me. So after we gained
administrative access the next step was simply finding an RCE which Sharon will present to you
now.
Great uh so just let let's reiterate real quick uh we were able to leak all the GUIDs all the device
identifications from every Western Digital uh cloud connected device and we used it uh because of
a flaw in their archi- cloud architecture we we used it uh to basically find a bypass to their
authentication and reach the devices. So we first impersonated the device and then we used it to
the devices. Once we impersonated the devices we got redirection and uh we got requests from real
users with their tokens and we now were able to impersonate the users. So basically uh we had
admin access in while impersonating users we had admin access to their devices uh because after we
created the tunnel impersonating the real the devices we got the tokens and we disconnected our
tunnel and we were able to connect to the the the real device tunnel. But sadly we wanted the
remote code execution and admin access admin web access does not mean remote code execution. So we
had to come up with new ways to leverage our admin access to remote code execution. So we turned
out we turned to the REST SDK uh binary once again and we had a lot of new surface to research now.
Because we were fully authenticated. Previously when we researched this binary we looked only on
pre-authenticated routes and APIs and as Noah mentioned this was a go-lanx so it was very
difficult and time consuming to to go over all the functions um. But we now had new uh new
vector uh authenticated vector so it was very important for us to cover more APIs and more
routes. Uh the first one of the first routes we looked at uh was uh the uh the uh the on the uh the uh
the shares. Shares and mounts. So we're talking about a NAS device now. Obviously a NAS
device uh main goal is to store your your files and make sure you have the ability to read those
files and write those files. So basically when you open the the platform the web platform or
the mobile application you see uh directories from your hard drives inside the NAS. And
obviously the goal of the NAS again is to let you the ability to read and write files from
these directories. What we discovered by reverse engineering these routes is behind the
scene the NAS operating system has a sim links to directories inside the hard drives. So
whenever you see for example public directory in the web interface or the mobile application
basically shows you the content of slash HD slash HD whatever and then public. So we thought
what happens if we had the capability to switch this sim link to for example slash. This means
that we will see on the web interface which we have access to because we're now user
authenticated we will see files from slash. And indeed we find a way undocumented way to modify
change uh the routes the mounting points on the device simply by using the the file system API.
We could now change directories change their their mounting points to different directories.
And we actually tried it and it worked. So for example here we created a new share which is
mapped to slash temp and we simply saw files and directories from slash temp on the device.
Previously we could not do this because these files and directories uh were not allowed to be
accessed from the mobile application. Uh obviously the uh the uh the uh the uh the uh the uh the uh the
mobile application the web interface only wanted to show you files that you can interact with
from your hard drive. So it was pretty crazy because we had write read and write primitive
because we just had access to any directory we wanted on the device. The truth is we did not
have unlimited read and write access uh because the file system had some restrictions to where
files can be written. Uh some directories and some mounting points were read only. So for
example we could not overwrite binaries on the device. Uh so we had to be very creative to think
how can we leverage this primitive read and write primitive into a remote code execution. For
example one of the things we thought of is maybe we could we could download the device
configuration modify it for example to change uh where the device downloads the firmware from and then
rewrite the configuration. However we found an easier way. One of the routes we also looked at
is the do reboot. So users Western Digital users can go to their uh cloud platform and reboot their
devices remotely. So since we had the user token we could do this on behalf of the user. So we
could basically initiate uh a reboot process on the device. Now what we found out is the reboot
is not that straightforward on the devices. So it's not just doing reboot. It's actually
activating a specific binary called the do reboot. And as it turned out this binary does more
things than just rebooting the device. For example it reads files from the slash temp directory
and it parses them and uses the parsed data somehow. Western Digital did this because there are many
ways uh or many uh uh ways to do this. Uh so we found a way to do this. Uh so we found a way to do this. Uh so we
found a way to do this. Uh so we found a way to do this. Uh so we found a way to do this. Uh so Undertand
injection point into a system command which will be, which will get executed. So now we have
the ability to execute code on the device if we are authenticated which we were um and we had
our chain complete. So I would like to go over uh the the full chain. Basically it starts with
us licking goods of all the devices in the world uh and we can even do this real time as
Noam mentioned by getting the CTL feed and we used it to impersonate real device and get user
tokens whenever they auto reconnect to the tunnel. Then we're using the user token to connect
to the real tunnel to the real device and we're creating new mounting points and then we're
writing file to the slash stamp and getting uh and doing reboot and getting code execution. So
let's see it uh.
Full scale. Now the user first of all the real user is connected to the device and we as
attackers want to get their uh device so we're impersonating the device by telling the cloud hey
we're this device identification the good and at the moment we're doing this the cloud will
disconnect the real tunnel and connect us. Whenever it happens the user auto reconnects
using their tokens to our device to the our impersonate device and now we can impersonate the
user. So we're cancelling the tunnel and waiting for the real device to issue new tunnel and we're
using the token to actually connect to the real device. Next we're uh creating new mounting point
to point at slash stamp and we are writing our file which will be parsed and be used in the reboot
process. Finally giving us a real device to connect to the real device. And we're uh creating a new
reverse shell. And and this is exactly what we did in Pongtuon so we got uh on top of the
reverse shell we got also 40k so it was nice. Uh we we used it to hack a device in Pongtuon but
basically we were not limited to just Pongtuon or or a single device. We could exploit any device
that we know the it's device identification the GUID and we had thousands of of them maybe
maybe millions. So it was a great power and with great power comes great responsibility. So
uh obviously we reported this to Western Digital and we worked with them until everything was
resolved. Now we uh we had a concept in our hands and we had a concept in our hands that we
had. So basically uh we had the concept of impersonating an IOT device and using and
leverage this impersonation to do something on behalf of the device. In this case in the
Western Digital case it was impersonating a device and waiting to get the user token to use it.
But since we competed in Pongtuon we wanted to leverage this for Synology as well. So let's go
over in real quick uh what we did in Synology. So for Synology we wrote a code that was
designed to research the DS920. Uh this is very similar device uh to the WD. Uh it's also
Linux based with 86 architecture 64 bit. Uh and it had um a really fully featured web interface
uh running CGI's written in C++. Um behind the scene the web server is Nginx and it has a
very rich configuration that we could play with. Uh but we could not find any straightforward pre-authentication.
Uh so without that we changed the code and we have a very dedicated remote code execution uh
chains so we turned out to the cloud. Now similar to previous uh device West Synology has uh a
fully featured cloud called quick connect. So basically if anyone wants to reach their device
they'll go to quick connect dot 2 and will enter their device alias. How do you get to a device
alias? You first need to authenticate on the device itself and associate the SS2 with the other device.
the device with your Synology user. Whenever you do this uh in the web configuration on the
device itself you uh basically exchange a couple of uh tokens and APIs on the device and now the
device is capable to connect to the cloud uh and be associated with the alias you give it. So
very simply how it works whenever a user go goes to quick connect um and wants to initiate uh
connection to their device they will they will go to alias dot quick connect dot two and the
cloud will relay uh the request to the device and basically will tell the device to open a VPN
tunnel. So whenever the Synology quick connect cloud received the request it will initiate a
tunnel open VPN tunnel with the device uh and now the user can reach their device through this uh
relay point through the device. So uh if you have a connection to the device uh you can
connect to the device inside the VPN tunnel. Now if you noticed uh we're also using here
subdomains so we could also harvest all the aliases of all Synology devices in the world uh and
yeah we did the same so we had a list of uh thousands of maybe millions of subdomains
basically aliases of devices of Synology devices. But we wanted more obviously we wanted to
understand how does the device what type of tokens or secrets does the device need to be
used to connect to quick quick connect cloud platform and uh to initiate the VPN tunnel. So we
researched this process for a very long time uh because it it is a long process um and if we
summarize all the digital elements or the tokens or the secrets whatever you want to call it
um we made a a quick list for this. So for example the device needs to know its MAC address serial
number device module some tokens in order to connect to the quick connect cloud platform and start
and initiate this tunnel. So if we wanted to impersonate the device we had to have these
identifiers. And if you look at it some of the identifiers are quite straightforward for example
the MAC address is very easy to get but also the serial number and the device module are easy to get. Uh apparently Synology has this discovery
utility so whenever you buy a new device you can activate the discovery utility and search for devices
around you on the local network. So we basically implemented this protocol to get the basic
identifiers such as serial number module and MAC. So now we had the first uh elements that we needed
uh for uh the first element that we needed to impersonate the device. By the way the DS token is a
uh is some kind of uh deterministic um algorithm that based on the serial number so whenever we
had the serial number we could now calculate this uh DS token. Um next we had to get the API key
which is the device quick connect key. This token and also the authentication token are tokens that
are being generated whenever the user associates their their Synology user on the device. So this is
the device. So we thought it could be impossible to get those because it only happens once on the
device and then they're not being exchanged anymore. But after researching a lot of different endpoints
and routes on the cloud platform and also researching and reverse engineering different binaries
and uh other endpoints on the device itself we figured uh there is a bug uh apparently what seems to be a bug on the
cloud platform. So apparently if we try we ask nicely the cloud to register for us a new API token
and just giving it a serial number it will be enough to generate a new valid API token on behalf of the
device. So just by knowing the serial number and the MAC address and also the mod model we could
actually generate new API token for the device and use it. That was crazy. Next we needed uh uh uh uh
authentication key uh which was very similar it it's another token uh but also a different uh a token
that we needed to get access to. Uh and we thought we were very lucky in the first time so there is no
way we were able to get this the second time but we were able to get this uh due to another bug in
another feature uh of uh DNS uh DDN dynamic DNS feature of the devices. Uh so basically again they
forgot to do some stronger authentication and again we were able to get this token that we
needed to impersonate a device. Now that we had both tokens and all the basic identifiers we
basically could receive any information we want on the device and we had our list completed. So we
had all the information we need in order to impersonate any Synology device that we want.
That's crazy. So what we did with it. We needed to get this uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh
now we're in the context of a real uh device. We impersonated a real device and we thought how
can we leverage this into a remote code execution. So the first thing that we did was telling the
cloud hey we're this real device for real. Please change the IP address that you think I'm at to
a different one. Basically what we were trying to do is to make the cloud plot
form to relay users instead of the real device to our CNC. And it worked because we fully
impersonated the device and the cloud fully trusted us. We had all the secrets. We had the tokens, we
had the serial number, we had the MAC address, we had everything that we need. And the server
really relayed users to our CNC and again we got their tokens and we were able to access uh the real device.
Thank you. Uh so just to sum up real quick. Users wants to connect to their devices. But because
of a couple of flaws and vulnerabilities we uncovered in the cloud architecture we were able to
redirect users to our impersonated device. Once we were getting the user tokens we used these tokens
and impersonated the users so we basically connected on behalf of the users to their real device.
Now to sum up. Cloud services focus on strong user authentication. It's very difficult these
days to bypass user authentication. But we believe that device authentication is a bit
overlooked. So in many cases we've seen IOT architectures using weak or public knowledge to
authenticate devices. So obviously this needs to be changed and we already contacted a couple of
big vendors uh that we found bugs in. So maybe we'll be here next week, next year. Uh and we
really want to change this and emphasize that impersonated devices can be real danger. Thank
you. So I'm not sure about questions. Should we do questions? I'm not sure about questions.
Here? Okay. You're invited to follow us wherever you go. Thank you.