1 00:00:04,080 --> 00:00:08,720 Okay, hello everybody, and welcome to our DEF CON talk, a pain in the NAS, exploiting 2 00:00:08,720 --> 00:00:10,780 cloud connectivity to porn your NAS devices. 3 00:00:11,820 --> 00:00:18,100 So my name is Noah Moshe, I'm a vulnerability researcher in Clarity Team 82, and with me 4 00:00:18,100 --> 00:00:20,380 today is Sharon Brezinov, our director of research. 5 00:00:20,800 --> 00:00:25,000 And as you can see behind us, this is our playground, this is where we have fun. 6 00:00:25,000 --> 00:00:31,920 We mainly look at IoT and OT products, be it PLCs, HMIs, and of course, like I'm going 7 00:00:31,920 --> 00:00:33,660 to showcase to you today, NAS devices. 8 00:00:34,560 --> 00:00:39,460 And our job is basically breaking them and looking for cool vulnerabilities, which let's 9 00:00:39,460 --> 00:00:40,480 say it's heaven in life. 10 00:00:41,120 --> 00:00:45,180 Of course, we'd like to make huge thanks to the other Team 82 researchers that helped 11 00:00:45,180 --> 00:00:47,980 us in this research, Uri Katz and Vera Menz. 12 00:00:48,200 --> 00:00:50,380 Huge thanks to you, and you guys rock. 13 00:00:51,480 --> 00:00:54,480 So let's talk about what we're going to showcase to you today. 14 00:00:54,480 --> 00:01:00,540 You see, I have a NAS at home where I store all of my spicy content, like for example, 15 00:01:00,560 --> 00:01:06,180 my documents, the, of course, government stuff, and some kind of pictures, let's say. 16 00:01:06,400 --> 00:01:12,820 And that's why when Pwn2Own competition in Toronto last year decided to do the NAS category 17 00:01:12,820 --> 00:01:18,600 where the goal was to hack and exploit remote code execution vulnerabilities on these NAS 18 00:01:18,600 --> 00:01:23,080 devices, which one of which I actually own, I said, yeah, let's do it, and let's go all 19 00:01:23,080 --> 00:01:23,320 in. 20 00:01:24,480 --> 00:01:25,560 So let's take a look at how we own both of these devices. 21 00:01:25,980 --> 00:01:30,860 You see, we try to look at kind of esoteric features, because both of these NAS devices 22 00:01:31,380 --> 00:01:36,320 were quite old and looked at by different research groups over the years. 23 00:01:36,460 --> 00:01:41,180 So we try to look at what kind of interesting stuff can we look at that maybe other researchers 24 00:01:41,180 --> 00:01:43,920 less likely put the effort and time into. 25 00:01:44,160 --> 00:01:49,520 And that's when we realized that actually both of these NAS platforms have cloud platforms, 26 00:01:49,900 --> 00:01:54,020 allowing users to actually access and use their NAS remotely through the cloud. 27 00:01:54,480 --> 00:01:59,800 In the case of Western Digital, it is My Cloud OS 5, and in the case of Synology, it is 28 00:01:59,800 --> 00:02:02,340 Quick Connect Cloud Services. 29 00:02:03,000 --> 00:02:05,440 Now I ask myself, what's the use case here? 30 00:02:05,600 --> 00:02:09,440 Why should I enable my cloud, my device to connect to the cloud? 31 00:02:09,720 --> 00:02:11,140 And actually, that's the reason. 32 00:02:11,300 --> 00:02:17,380 You see, my NAS sits at home where I save all my important stuff to it, and I am out 33 00:02:17,380 --> 00:02:17,680 and about. 34 00:02:17,820 --> 00:02:22,420 I could be at work, I could be on a vacation, et cetera, however, I want to access my files 35 00:02:22,420 --> 00:02:22,780 now. 36 00:02:22,780 --> 00:02:29,100 So that way, through the cloud application, I am trying and requesting my files and fetching 37 00:02:29,100 --> 00:02:29,740 them remotely. 38 00:02:30,220 --> 00:02:34,980 But when I saw that this is the use case in business logic, I thought to myself, hey, 39 00:02:35,040 --> 00:02:41,520 maybe we can use it somehow and have attackers access the files we save on our NAS through 40 00:02:41,520 --> 00:02:43,640 the cloud, not requiring direct access. 41 00:02:44,280 --> 00:02:48,760 Somehow they can request and fetch the files and get hold to my sensitive data. 42 00:02:49,220 --> 00:02:52,700 And that is exactly the kind of ability we gain. 43 00:02:52,700 --> 00:02:58,720 In the months leading to Pong 2.1 competition, where we were able to access, read, and write 44 00:02:59,260 --> 00:03:02,900 every file that was stored on a NAS device worldwide. 45 00:03:03,480 --> 00:03:06,840 And you can imagine the catastrophic implications of it. 46 00:03:06,980 --> 00:03:11,080 I shouldn't say seeing sensitive files, of course, and maybe altering them somehow. 47 00:03:11,960 --> 00:03:15,800 However we thought to ourselves, yeah, that's cool, however, what could be cooler? 48 00:03:16,180 --> 00:03:21,560 I mean, fetching files is cool, however, the holy grail is actually executing code 49 00:03:21,560 --> 00:03:22,680 on the NAS device. 50 00:03:22,700 --> 00:03:26,280 So I can access the NAS devices through the cloud, meaning somehow I am able to access 51 00:03:26,280 --> 00:03:28,940 people's home network through the cloud application. 52 00:03:29,680 --> 00:03:35,260 And as it turns out, this is exactly the kind of vulnerability chain we exploited in 53 00:03:35,260 --> 00:03:41,580 the Pong 2.1 competition, netting us $40,000 and, of course, chaining five different vulnerabilities 54 00:03:42,100 --> 00:03:44,520 to attack cloud, the NAS devices. 55 00:03:45,160 --> 00:03:50,460 However, since our attack leveraged the cloud, we were able to not attack just one device, 56 00:03:50,660 --> 00:03:52,360 but instead we could attack everything. 57 00:03:52,360 --> 00:03:56,660 We could, for instance, attack any cloud connected device, giving us access to billions, millions 58 00:03:56,660 --> 00:03:58,720 and millions of different devices worldwide. 59 00:03:59,540 --> 00:04:05,640 And actually the vulnerabilities we uncovered were so severe that Western Digital had to 60 00:04:05,640 --> 00:04:09,580 boot off devices running all frameworks from their cloud access. 61 00:04:10,260 --> 00:04:14,460 Meaning if you are not patched and no longer vulnerable to the vulnerabilities we discovered, 62 00:04:14,840 --> 00:04:17,680 you can no longer access your device through the cloud. 63 00:04:18,340 --> 00:04:22,340 This is because we identified some architecture flaws that had to be changed. 64 00:04:22,360 --> 00:04:28,540 meaning all devices can no longer connect to the cloud services. Well, that is the gist of our 65 00:04:28,540 --> 00:04:33,560 research, so I hope it intrigued you, but let's doop dive and see how we uncovered all of these 66 00:04:33,560 --> 00:04:39,380 vulnerabilities and what kind of vulnerabilities we actually managed to achieve. So let's start 67 00:04:39,380 --> 00:04:46,380 with Western Digital. In the Pwn2Own competition, we looked at Western Digital PR4100. This 68 00:04:46,380 --> 00:04:54,220 is the cutie right there and it is actually a custom Linux based machine running x86 64 bit 69 00:04:54,220 --> 00:05:00,760 processor and inside this machine, many services are running. Of course, we have the usual 70 00:05:00,760 --> 00:05:06,180 suspect, the web management port where most of the prior vulnerabilities were discovered. 71 00:05:06,480 --> 00:05:11,440 However, since it is a NAS device, a lot of file fetching and file accessing services also 72 00:05:11,440 --> 00:05:16,360 exist, like SMB, FTP, and of course, accessing the files of other devices. So let's take a look 73 00:05:16,380 --> 00:05:16,860 at some of theاي 74 00:05:16,860 --> 00:05:23,040 of the HTTP requests. Well the first thing I did was order the device, however, I'm a very 75 00:05:23,040 --> 00:05:29,100 impatient man, I could not wait for the postal service to get my device to me. That's why I went 76 00:05:29,100 --> 00:05:34,900 to the Western Digital website and looked for a firmware download. When trying to emulate my 77 00:05:34,900 --> 00:05:40,600 device and getting access to it even before it arrives, usually when we work with filmwrecks, there 78 00:05:40,600 --> 00:05:45,720 are two options. Either the firmware is encrypted, meaning everything is encrypted somehow and the 79 00:05:45,720 --> 00:05:51,320 the device decrypted during runtime and during the upgrading process, or it is simply unencrypted 80 00:05:51,320 --> 00:05:55,600 and containing all of the different sections within the firmware. Luckily for us, Western 81 00:05:55,600 --> 00:05:59,780 Digital chose to not encrypt the firmware, meaning we add access to all of the different 82 00:05:59,780 --> 00:06:05,240 files, file system, binaries, configurations, et cetera, that are running inside our NAS 83 00:06:05,240 --> 00:06:12,600 device. Sadly, this firmware was not a full-on file system, meaning we had to pick and choose 84 00:06:12,600 --> 00:06:17,500 and reconstruct the file system from the different sections. That is because all of the 85 00:06:17,500 --> 00:06:21,520 different sections contain different files for the file system. However, they were not 86 00:06:21,520 --> 00:06:27,280 organized and not in the corresponding places. Luckily for us, we looked at the few files 87 00:06:27,280 --> 00:06:32,660 inside the firmware and we found an init script that actually reconstructed the firmware for 88 00:06:33,010 --> 00:06:38,780 us. This script is being ran whenever a firmware upgrade procedure happens and then using a 89 00:06:38,780 --> 00:06:42,580 virtual machine and a true device, we were able to reconstruct and reboot the firmware. 90 00:06:42,580 --> 00:06:50,040 And run the web services. We now had access to the NAS device even without ordering it and this 91 00:06:50,040 --> 00:06:54,880 actually gave us two main benefits. First of all, I was more well-versed. I knew what kind of 92 00:06:54,880 --> 00:06:59,440 services were running, what were all the configuration files, what binaries are actually 93 00:06:59,440 --> 00:07:04,540 being executed, and even more important, I had a playground that I could break. I tend to break 94 00:07:04,540 --> 00:07:10,000 devices that I look at and my boss has to reorder ones and he gets mad at me, especially when 95 00:07:10,000 --> 00:07:12,560 they are super expensive. So now I have a free software that I can use to run the web services. 96 00:07:12,580 --> 00:07:17,240 I have a playground, I can just do whatever I want. If I delete the whole file system by 97 00:07:17,240 --> 00:07:22,600 accident, which I did in a few researches in the past, no problem, I'll just boot up to the 98 00:07:22,600 --> 00:07:29,060 latest snapshot. Well, let's take a look at the first part we looked at, the web management 99 00:07:29,060 --> 00:07:35,160 architecture. This is the gist of it and let me explain to you. As I told you before, this was the 100 00:07:35,160 --> 00:07:41,040 main focus of researchers in the past where multiple vulnerabilities in the PHP and CGI scripts 101 00:07:41,040 --> 00:07:46,780 were found and identified and actually exploited in the point-to-own competition. In order to 102 00:07:46,780 --> 00:07:53,300 remediate it, Western Digital had a genius idea of just wrapping it all up in a Golang binary that 103 00:07:53,300 --> 00:07:58,800 actually authenticates and authorizes any request performed to the back ends. This meant that 104 00:07:58,800 --> 00:08:03,340 even though we did, and yeah, we did find a few vulnerabilities and remote code execution 105 00:08:03,340 --> 00:08:09,080 vulnerabilities in the web server, since every request had to be authenticated, it was not that 106 00:08:09,080 --> 00:08:10,420 useful in the point-to-own competition. 107 00:08:11,040 --> 00:08:17,480 Every request, every exploit should be authenticated. This meant that we had to scrap this 108 00:08:17,480 --> 00:08:22,880 entire lead and look for new leads somewhere else and that's when we turned our heads into the 109 00:08:22,880 --> 00:08:29,240 cloud features of the system. You see, the cloud features, especially in Western Digital case, are 110 00:08:29,240 --> 00:08:35,080 very, very opted in and prompted to users to enable them. It is actually in the name of the 111 00:08:35,080 --> 00:08:40,820 device, My Cloud, and most of the users actually enable this feature and are able to access their 112 00:08:41,040 --> 00:08:46,400 files through the cloud services. All you need to do is enable this tick and box right here, which 113 00:08:46,400 --> 00:08:53,180 you are encouraged to do by Western Digital User Interface, and then using an account, a cloud 114 00:08:53,180 --> 00:08:58,200 account, you are able to associate your account with your NAS device and now are able to access it 115 00:08:58,200 --> 00:09:03,960 through either the mobile application or the web application of your choice. However, when we 116 00:09:03,960 --> 00:09:09,620 realized that, we thought to ourselves, how the hell does this magic happen? How am I navigated and 117 00:09:09,620 --> 00:09:11,020 routed to my NAS? 118 00:09:11,680 --> 00:09:17,600 Well, like I've told you before, whenever I'm using the Western Digital application, I am 119 00:09:17,600 --> 00:09:24,580 authenticated to my account and before I create my account, I associate it with my NAS device. Now, 120 00:09:24,620 --> 00:09:31,180 each NAS device is identified by a unique GUID installation and that way, whenever I try to, let's 121 00:09:31,180 --> 00:09:37,920 say, access files, I specify my GUID to Western Digital's cloud services and then behind the 122 00:09:37,920 --> 00:09:41,020 scenes, somehow, they route my request to my account. So, that's how I can authenticate my 123 00:09:41,020 --> 00:09:45,160 connection with my NAS device to my corresponding NAS device and the disk tunnel is created. 124 00:09:45,680 --> 00:09:51,880 However we thought to ourselves, what would happen if some attacker knew my device is GUID and 125 00:09:51,880 --> 00:09:59,020 would try to use the API routes and URLs to access my NAS device? Well, we tried that and it 126 00:09:59,020 --> 00:10:04,780 didn't work, so it's not that easy. However, since we tried it on our device, we opened TCP 127 00:10:04,780 --> 00:10:11,000 dump in the background and we noticed something weird. You see, the request was made to our 128 00:10:11,020 --> 00:10:16,620 device meaning we reached it and instead of being blocked by the cloud application we were 129 00:10:16,620 --> 00:10:23,360 blocked by the NAS meaning we actually reached one of its internal ports. Now this is quite 130 00:10:23,360 --> 00:10:29,280 crazy because my NAS sits at home. It is not internet exposed. It doesn't I didn't open any 131 00:10:29,280 --> 00:10:34,800 ports in the firewall and it doesn't have an external IP address meaning somehow through 132 00:10:34,800 --> 00:10:40,960 Western Digital servers I was able to access my home network my LAN home network and 133 00:10:40,960 --> 00:10:46,700 access one of the internal services that are running there in my NAS device. When we realized 134 00:10:46,700 --> 00:10:53,040 that our game plan was quite simple. I mean all we need to do is just know a device's grid which 135 00:10:53,040 --> 00:11:00,860 is 128 random bit grid find somehow some authentication bypasses and exploit some 136 00:11:00,860 --> 00:11:08,760 vulnerabilities to run code on our device. Yeah pretty easy. So let's try and understand what is 137 00:11:08,760 --> 00:11:10,820 the use case once again. You see these 138 00:11:10,960 --> 00:11:16,400 is the regular use case in the NAS architecture. It's a user trying to access their NAS from 139 00:11:16,400 --> 00:11:22,100 anywhere around the world. However Western Digital also thought about another use case. What 140 00:11:22,100 --> 00:11:27,180 happened when the user sits at home like so for example sitting on couch and wanting to access 141 00:11:27,180 --> 00:11:34,060 their spicy movies. Well if they were able to access if they needed to actually fetch the files 142 00:11:34,060 --> 00:11:40,140 over the cloud it means that there will be a lot of latency and bad user experience and that's not 143 00:11:40,140 --> 00:11:40,680 actually very. 144 00:11:40,680 --> 00:11:46,280 smart. So instead Western Digital implemented this procedure right here. Whenever a user 145 00:11:46,280 --> 00:11:52,120 sits at home they are redirected to their NAS device and then fetch files locally over the LAN 146 00:11:52,120 --> 00:11:59,580 access. However, somehow Western Digital had to make sure that the users were accessing a real, 147 00:11:59,600 --> 00:12:05,700 the real device and not let's say an attacker. How did they do that? Well, in order to do that 148 00:12:05,700 --> 00:12:11,620 Western Digital actually issued a unique certificate to each device and that way whenever I 149 00:12:11,620 --> 00:12:16,700 try to access it I am able to make sure and check that I am indeed accessing my real device. 150 00:12:17,260 --> 00:12:23,120 However, the keen-eyed in you probably noticed something weird. What is that? As you can see 151 00:12:23,120 --> 00:12:30,020 embedded in the certificate here it lies my device's GUID. This means that by simply fetching 152 00:12:30,020 --> 00:12:35,680 and accessing my device through the HTTPS services I am able to get the device to my device 153 00:12:35,700 --> 00:12:43,560 certificate and carve out the GUID through it. While this was pretty cool sadly our attack 154 00:12:43,560 --> 00:12:48,560 scenario involves not being able to access the device meaning we want to access it through the 155 00:12:48,560 --> 00:12:54,840 cloud so it's not pretty practical but maybe somehow we can improve it. Well, that's when we 156 00:12:54,840 --> 00:13:00,360 turn our heads and realized and try to realize how the hell does this redirect work? I mean how 157 00:13:00,360 --> 00:13:05,640 does this message happens? Well, you see Western Digital actually added a DNS name for 158 00:13:05,700 --> 00:13:11,700 each NAS device and that way whenever I'm in local network it tries to access this DSS name. 159 00:13:11,920 --> 00:13:18,980 And this DSS name actually maps to an internal IP address of my device. That- as you can see I can 160 00:13:18,980 --> 00:13:25,120 use NS lookup on my devices name and that way when the result I see the internal IP address of my 161 00:13:25,120 --> 00:13:31,580 device and that way I'm able to access it locally through the LAN interface. However, this meant 162 00:13:31,580 --> 00:13:35,680 that the DNS record was created and because it was created of course this message is not being contains. 163 00:13:35,700 --> 00:13:42,380 we can exploit it and that's why using passive DNS servers we were able to retrieve all the DNS 164 00:13:42,380 --> 00:13:48,500 queries. You see some DNS servers actually sell the metadata of user requests uh that are 165 00:13:48,500 --> 00:13:54,260 performed to their DNS servers to the highest bidder and sadly in the internet there are a lot 166 00:13:54,260 --> 00:14:00,420 of APIs and servers that allow users to search for all DNS queries user performed uh in order 167 00:14:00,420 --> 00:14:08,840 to basically get access to what kind of DNS queries user used and because we the GUID is in 168 00:14:08,840 --> 00:14:15,080 this DNS record we are able to retrieve it and as you can see it's not a one off we actually see 169 00:14:15,080 --> 00:14:21,360 tens of thousands of different DNS records meaning we now had access to tens of thousands uh 170 00:14:21,360 --> 00:14:28,020 uh GUIDs. Sadly when we tried accessing uh actually accessing these GUIDs through Western 171 00:14:28,020 --> 00:14:30,400 Digital's cloud most of them were already uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh 172 00:14:30,400 --> 00:14:34,980 already dead and not disconnected. That's because we don't know when the DNS record was 173 00:14:34,980 --> 00:14:40,600 created and there were no logins connected anyways. Uh this meant we no didn't actually have 174 00:14:40,600 --> 00:14:46,260 ten thousand records. However we had a good lead into actually proving the amount of the uh 175 00:14:46,260 --> 00:14:53,300 GUIDs we know of. That's when we realized that because the certificate is issued to every 176 00:14:53,300 --> 00:14:58,940 device every connected device and this certificate contains the device GUID maybe we can use 177 00:14:58,940 --> 00:15:00,380 what's called certificate hash. So let's say we have a certificate hash and we have a certificate hash 178 00:15:00,400 --> 00:15:05,300 harvesting. Similar to the passive DNS servers there are a lot of servers uh offering the 179 00:15:05,300 --> 00:15:11,900 ability of you to users to look for say certificates they encounter and look for patterns uh in 180 00:15:11,900 --> 00:15:16,600 the certificate name. For example we use census which boasts they have over six billion 181 00:15:16,600 --> 00:15:22,980 certificates in their databases allowing users to query and fetch these certificates. When we 182 00:15:22,980 --> 00:15:27,960 tried and grabbed for Western Digital pattern we realized something shocking. There was over 183 00:15:27,960 --> 00:15:30,380 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 184 00:15:30,380 --> 00:15:31,800 and each of the devices could can use access to Resources within the last three months. And now 185 00:15:31,800 --> 00:15:36,540 we had the knowledge of every one of these devices GUID. Meaning we were to access them through 186 00:15:36,540 --> 00:15:42,940 Western Digital eh uh cloud platforms. However sadly in the point on competition you have to do it 187 00:15:42,940 --> 00:15:48,760 live. Meaning we cannot ah know the GUID in advance. And our device is connected in real-time. 188 00:15:49,080 --> 00:15:55,580 This meant we had to somehow get access to GUID. And get knowledge of GUIDs in real-time. That's 189 00:15:55,580 --> 00:15:59,920 when we discovered something pretty cool which I wasn't aware of in the past which called- which like Ah 190 00:15:59,920 --> 00:16:00,360 which is called is written in old-school currencies. Er exit code and my Find Wades account ownership 191 00:16:00,360 --> 00:16:07,400 CTL, Certificate Transparency Log. You see, there was kind of a specification called CTL in the 192 00:16:07,400 --> 00:16:13,540 internet with the goal of improving security and visibility in the internet. What CTL means is 193 00:16:13,540 --> 00:16:19,540 that whenever a certificate authority, a CA, issues a new certificate, it sends the metadata 194 00:16:19,900 --> 00:16:25,780 about this certificate to a live public feed allowing users to simply subscribe to this feed 195 00:16:25,780 --> 00:16:31,640 and get knowledge of the certificate being issued, issued mainly the certificate CN and of 196 00:16:31,640 --> 00:16:38,060 course the validity date, etc. Luckily for us, there are many tools that enable us to 197 00:16:38,060 --> 00:16:43,620 subscribe to the CTL feed and using them we were able to subscribe to the CTL feed and grab for 198 00:16:43,620 --> 00:16:49,500 Western Digital Pattern and that way we were able to get devices, GUIDs, whenever they actually 199 00:16:49,500 --> 00:16:55,520 connected to the network in the first time. Meaning we had the ability to leak GUID and leak 200 00:16:55,780 --> 00:17:01,460 knowledge of the devices GUID in real time whenever it connected. And we simply did it for a few 201 00:17:01,460 --> 00:17:06,920 days and we actually got amazing results, getting us tens of thousands of different devices GUIDs 202 00:17:06,920 --> 00:17:12,520 which we were able to access through the loophole and through the exposed APIs in Western 203 00:17:12,520 --> 00:17:18,720 Digital's cloud services. Cool. That meant that instead of breaking a device's GUID, we simply 204 00:17:18,720 --> 00:17:24,980 leaked all of them and we now had the knowledge of every device GUID worldwide. The next thing we 205 00:17:24,980 --> 00:17:25,740 had to do is... 206 00:17:25,780 --> 00:17:32,820 find some kind of an old bypass. Well, since we are a community in our role, we simply asked 207 00:17:32,820 --> 00:17:38,220 someone, hey, can we ask, can we use your device? We promised not to break it and luckily we 208 00:17:38,220 --> 00:17:44,300 didn't, uh, so we didn't have to buy him a new one. Uh, so we tried basically accessing the 209 00:17:44,300 --> 00:17:50,020 device's GUID using our own authenticated account. So all we did was simply open up our web 210 00:17:50,020 --> 00:17:55,760 browser, connecting to our account and simply stop the request and ch- change the device's GUID 211 00:17:55,760 --> 00:18:02,600 from our own to the GUID we wanted to test our theories on. And that's when we realized that some 212 00:18:02,600 --> 00:18:09,900 API routes actually worked. As you can see here, we are fetching a file ID of a device we do not own 213 00:18:09,900 --> 00:18:15,580 and are not associated with. All we did was simply change the GUID and some API routes just 214 00:18:15,580 --> 00:18:21,240 worked. That's pretty crazy and pretty lucky. As it turns out, Western Digital only checked for 215 00:18:21,240 --> 00:18:25,740 authentication instead of authorization. Meaning as long as I have a valid user ID, I'm not going to 216 00:18:25,740 --> 00:18:32,660 use a session and is connected to my account, I can access anyone, NAS, through some API routes by 217 00:18:32,660 --> 00:18:39,100 simply changing the device's GUID. That meant we now had access to everyone's sensitive files. We 218 00:18:39,100 --> 00:18:44,220 could, for example, view them, change them, leak them, do whatever we want and that's pretty cool. 219 00:18:53,160 --> 00:18:55,720 Yeah, that's pretty lucky. However, there are a lot of things that we can do. Uh, one of the things 220 00:19:03,840 --> 00:19:09,740 is down for the team. Unfortunately, when they checked people's IP addresses in the 221 00:19:09,740 --> 00:19:17,700 which was pretty sad because it took, uh, many months of, uh, work down the drain and we just had to find 222 00:19:17,700 --> 00:19:24,380 some new vulnerabilities. That's when I said, oh, fuck. I'll have to do some overnight. And, yeah, 223 00:19:24,500 --> 00:19:25,280 let's go again. 224 00:19:26,100 --> 00:19:32,940 Well, since I exhausted the API routes lead I thought to myself yeah I need to go back to the 225 00:19:32,940 --> 00:19:38,780 source and look for the main binary handling cloud connection. In Western Digital case it 226 00:19:38,780 --> 00:19:44,660 was a binary called rest SDK. This binary actually binded on the device and connected to 227 00:19:44,660 --> 00:19:50,060 Western Digital proxy servers and handled most of the cloud functionality like fetching files, 228 00:19:50,060 --> 00:19:56,500 changing files, etc. Sadly this binary is written in Golang which I personally hate because 229 00:19:56,500 --> 00:20:01,120 it's huge. It has tons of different functions and tons of different layers of abstraction 230 00:20:01,600 --> 00:20:07,300 making reverse engineering pretty sad and boring. And of course since it's written in Golang 231 00:20:07,300 --> 00:20:12,820 there is less attack surface because the memory is managed by Golang itself. A lot of APIs are 232 00:20:12,820 --> 00:20:19,220 secured by default and there's less error place for developers to make mistakes. So, 233 00:20:20,420 --> 00:20:26,920 in order to avoid reverse engineering as much as possible all I had to do was simply create a 234 00:20:26,920 --> 00:20:31,940 meta middle setup between me and the device, between the device and the cloud. Meaning 235 00:20:31,940 --> 00:20:37,360 whenever the cloud tries to interact with my device or vice versa I will be able to view the 236 00:20:37,360 --> 00:20:43,040 traffic and see what's happening behind the scenes. We did it through many methods mainly 237 00:20:43,040 --> 00:20:49,400 adding a certificate authority CA that we control on the device locally and that way we could 238 00:20:49,400 --> 00:20:54,720 basically man in the middle HTPS requests just making the device trust RCA and issuing 239 00:20:54,720 --> 00:21:01,420 device certificates on the fly. However, that way we were able to view and see the requests in 240 00:21:01,420 --> 00:21:08,400 real time and see what's happening at any time whatsoever. And when we threw when we had this 241 00:21:08,400 --> 00:21:14,480 ability our first goal was simply understanding how the hell does the tunnel pre-proxy 242 00:21:14,480 --> 00:21:19,380 creation happens. How my device connects to the cloud and informs it, informs the device 243 00:21:19,380 --> 00:21:25,320 hey I'm this and that device please redirect users to me. And through the process of man in the 244 00:21:25,320 --> 00:21:30,580 middle and reverse engineering we reached this conclusion. The first thing happened that 245 00:21:30,580 --> 00:21:37,040 happens is my device connecting to Western Digital Proxy servers over TLS connection. The 246 00:21:37,040 --> 00:21:42,800 minute the device connects the cloud says hey cool I want to create a proxy connection and 247 00:21:42,800 --> 00:21:49,360 fetches in HTTP to an API route on my device. The API, my device connects to the cloud and 248 00:21:49,380 --> 00:21:55,220 then says yeah okay I'm ready to connect and simply hands over the device's GUID saying hey I'm 249 00:21:55,220 --> 00:22:03,960 GUID please connect me. Then the cloud says great let's connect and the tunnel is created. Now the 250 00:22:03,960 --> 00:22:09,780 minute we saw that we were like wait what the fuck? Where the hell are the secrets? I mean the 251 00:22:09,780 --> 00:22:16,500 end all the end any all the things that my device sent to the cloud was my device's GUID which 252 00:22:16,500 --> 00:22:18,800 like I've showcased to you before is goddamn. 253 00:22:19,380 --> 00:22:25,360 This is a public knowledge meaning it is actually exposed on my device's certificate. This meant 254 00:22:25,360 --> 00:22:31,320 that by simply knowing the device's GUID we could try and impersonate it and that is exactly what we 255 00:22:31,320 --> 00:22:37,620 did. Meaning we went to Western Digital Proxy servers and simply connected saying hey I'd like to 256 00:22:37,620 --> 00:22:43,760 connect I am this and that GUID. And the minute we did that the server actually trusted that and 257 00:22:43,760 --> 00:22:49,360 said yeah I'm ready to initiate the connection and disconnected the real device. So this is a 258 00:22:49,360 --> 00:22:49,460 орal VR- sustaining work mode so this is the interactive live office presentation and saying 259 00:22:49,460 --> 00:22:53,680 hand side of the device. Meaning that whenever a user tries to connect to it through the device 260 00:22:53,680 --> 00:23:00,560 now they would be redirected to us. That is pretty crazy because now we were able to impersonate 261 00:23:00,560 --> 00:23:08,080 the device and act as this. However what was even crazier was what happened next. You see the 262 00:23:08,080 --> 00:23:14,540 minute we authenticated and created a tunnel. This request reached us. As you can see this is an 263 00:23:14,540 --> 00:23:19,340 HTTP request from the client saying hey I wanted refresh the 와서 that I would like to try to give 264 00:23:19,340 --> 00:23:24,260 volumes on my NAS device. However what's crazy is that it actually contains the user 265 00:23:24,260 --> 00:23:30,160 authentication token. We didn't we were actually pretty stumped at first saying yeah we 266 00:23:30,160 --> 00:23:35,680 didn't make this request. However upon further investigation we realized that in order to make 267 00:23:35,680 --> 00:23:40,800 sure everything is up to date and uh users have good user experience Western Digital 268 00:23:40,800 --> 00:23:46,860 performs background app refresh meaning constantly in the background the API the client 269 00:23:46,860 --> 00:23:52,040 connects to the NAS and says hey please refresh the files and give me access to my newer 270 00:23:52,040 --> 00:23:57,820 files and because of that a new request is made every 10 seconds or so. This meant that 271 00:23:57,820 --> 00:24:03,720 whenever the minute we stole a device's tunnel uh we got a request from the user containing 272 00:24:03,720 --> 00:24:08,800 the user token and this actually meant that the minute we stole device's tunnel we have 273 00:24:08,800 --> 00:24:15,260 authenticated administrative tokens to that device. This meant that once again by 274 00:24:15,260 --> 00:24:16,780 impersonating the device we could 275 00:24:16,780 --> 00:24:22,400 access everyone's file around the world giving us full administrative access to every NAS 276 00:24:22,400 --> 00:24:32,900 device Western Digital employs. Yeah that we actually did it we actually got this 277 00:24:32,900 --> 00:24:39,640 access twice in two months which I think is a personal record for me. So after we gained 278 00:24:39,640 --> 00:24:44,960 administrative access the next step was simply finding an RCE which Sharon will present to you 279 00:24:44,960 --> 00:24:45,300 now. 280 00:24:47,320 --> 00:24:55,780 Great uh so just let let's reiterate real quick uh we were able to leak all the GUIDs all the device 281 00:24:55,780 --> 00:25:03,240 identifications from every Western Digital uh cloud connected device and we used it uh because of 282 00:25:03,240 --> 00:25:10,640 a flaw in their archi- cloud architecture we we used it uh to basically find a bypass to their 283 00:25:10,640 --> 00:25:16,760 authentication and reach the devices. So we first impersonated the device and then we used it to 284 00:25:16,780 --> 00:25:23,540 the devices. Once we impersonated the devices we got redirection and uh we got requests from real 285 00:25:23,540 --> 00:25:32,540 users with their tokens and we now were able to impersonate the users. So basically uh we had 286 00:25:32,540 --> 00:25:40,480 admin access in while impersonating users we had admin access to their devices uh because after we 287 00:25:40,480 --> 00:25:46,340 created the tunnel impersonating the real the devices we got the tokens and we disconnected our 288 00:25:46,340 --> 00:25:52,520 tunnel and we were able to connect to the the the real device tunnel. But sadly we wanted the 289 00:25:52,520 --> 00:25:59,120 remote code execution and admin access admin web access does not mean remote code execution. So we 290 00:25:59,120 --> 00:26:08,300 had to come up with new ways to leverage our admin access to remote code execution. So we turned 291 00:26:08,300 --> 00:26:16,100 out we turned to the REST SDK uh binary once again and we had a lot of new surface to research now. 292 00:26:16,340 --> 00:26:22,720 Because we were fully authenticated. Previously when we researched this binary we looked only on 293 00:26:22,720 --> 00:26:27,640 pre-authenticated routes and APIs and as Noah mentioned this was a go-lanx so it was very 294 00:26:27,640 --> 00:26:35,200 difficult and time consuming to to go over all the functions um. But we now had new uh new 295 00:26:35,200 --> 00:26:40,800 vector uh authenticated vector so it was very important for us to cover more APIs and more 296 00:26:40,800 --> 00:26:46,320 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 297 00:26:46,340 --> 00:26:51,900 the shares. Shares and mounts. So we're talking about a NAS device now. Obviously a NAS 298 00:26:51,900 --> 00:26:59,120 device uh main goal is to store your your files and make sure you have the ability to read those 299 00:26:59,120 --> 00:27:05,480 files and write those files. So basically when you open the the platform the web platform or 300 00:27:05,480 --> 00:27:11,620 the mobile application you see uh directories from your hard drives inside the NAS. And 301 00:27:11,620 --> 00:27:16,140 obviously the goal of the NAS again is to let you the ability to read and write files from 302 00:27:16,340 --> 00:27:22,920 these directories. What we discovered by reverse engineering these routes is behind the 303 00:27:22,920 --> 00:27:30,060 scene the NAS operating system has a sim links to directories inside the hard drives. So 304 00:27:30,060 --> 00:27:35,860 whenever you see for example public directory in the web interface or the mobile application 305 00:27:36,460 --> 00:27:44,580 basically shows you the content of slash HD slash HD whatever and then public. So we thought 306 00:27:44,580 --> 00:27:52,000 what happens if we had the capability to switch this sim link to for example slash. This means 307 00:27:52,000 --> 00:27:56,780 that we will see on the web interface which we have access to because we're now user 308 00:27:56,780 --> 00:28:05,380 authenticated we will see files from slash. And indeed we find a way undocumented way to modify 309 00:28:05,380 --> 00:28:13,200 change uh the routes the mounting points on the device simply by using the the file system API. 310 00:28:13,200 --> 00:28:20,560 We could now change directories change their their mounting points to different directories. 311 00:28:20,660 --> 00:28:26,920 And we actually tried it and it worked. So for example here we created a new share which is 312 00:28:26,920 --> 00:28:33,460 mapped to slash temp and we simply saw files and directories from slash temp on the device. 313 00:28:33,800 --> 00:28:39,320 Previously we could not do this because these files and directories uh were not allowed to be 314 00:28:39,320 --> 00:28:43,180 accessed from the mobile application. Uh obviously the uh the uh the uh the uh the uh the uh the uh the 315 00:28:43,180 --> 00:28:48,460 mobile application the web interface only wanted to show you files that you can interact with 316 00:28:48,460 --> 00:28:55,520 from your hard drive. So it was pretty crazy because we had write read and write primitive 317 00:28:55,890 --> 00:29:03,400 because we just had access to any directory we wanted on the device. The truth is we did not 318 00:29:03,400 --> 00:29:10,340 have unlimited read and write access uh because the file system had some restrictions to where 319 00:29:10,340 --> 00:29:16,580 files can be written. Uh some directories and some mounting points were read only. So for 320 00:29:16,580 --> 00:29:22,280 example we could not overwrite binaries on the device. Uh so we had to be very creative to think 321 00:29:22,280 --> 00:29:28,320 how can we leverage this primitive read and write primitive into a remote code execution. For 322 00:29:28,320 --> 00:29:33,400 example one of the things we thought of is maybe we could we could download the device 323 00:29:33,400 --> 00:29:40,140 configuration modify it for example to change uh where the device downloads the firmware from and then 324 00:29:40,340 --> 00:29:48,120 rewrite the configuration. However we found an easier way. One of the routes we also looked at 325 00:29:48,120 --> 00:29:55,620 is the do reboot. So users Western Digital users can go to their uh cloud platform and reboot their 326 00:29:55,620 --> 00:30:02,320 devices remotely. So since we had the user token we could do this on behalf of the user. So we 327 00:30:02,320 --> 00:30:09,200 could basically initiate uh a reboot process on the device. Now what we found out is the reboot 328 00:30:10,340 --> 00:30:15,400 is not that straightforward on the devices. So it's not just doing reboot. It's actually 329 00:30:15,400 --> 00:30:23,320 activating a specific binary called the do reboot. And as it turned out this binary does more 330 00:30:23,320 --> 00:30:30,520 things than just rebooting the device. For example it reads files from the slash temp directory 331 00:30:31,020 --> 00:30:38,140 and it parses them and uses the parsed data somehow. Western Digital did this because there are many 332 00:30:38,140 --> 00:30:40,320 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 333 00:31:01,520 --> 00:31:10,320 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 334 00:31:10,320 --> 00:31:17,620 injection point into a system command which will be, which will get executed. So now we have 335 00:31:17,620 --> 00:31:23,520 the ability to execute code on the device if we are authenticated which we were um and we had 336 00:31:23,520 --> 00:31:30,400 our chain complete. So I would like to go over uh the the full chain. Basically it starts with 337 00:31:30,400 --> 00:31:36,760 us licking goods of all the devices in the world uh and we can even do this real time as 338 00:31:36,760 --> 00:31:46,560 Noam mentioned by getting the CTL feed and we used it to impersonate real device and get user 339 00:31:46,560 --> 00:31:53,320 tokens whenever they auto reconnect to the tunnel. Then we're using the user token to connect 340 00:31:53,320 --> 00:31:59,860 to the real tunnel to the real device and we're creating new mounting points and then we're 341 00:31:59,860 --> 00:32:05,560 writing file to the slash stamp and getting uh and doing reboot and getting code execution. So 342 00:32:05,560 --> 00:32:06,560 let's see it uh. 343 00:32:06,760 --> 00:32:13,340 Full scale. Now the user first of all the real user is connected to the device and we as 344 00:32:13,340 --> 00:32:21,280 attackers want to get their uh device so we're impersonating the device by telling the cloud hey 345 00:32:21,280 --> 00:32:27,260 we're this device identification the good and at the moment we're doing this the cloud will 346 00:32:27,260 --> 00:32:34,780 disconnect the real tunnel and connect us. Whenever it happens the user auto reconnects 347 00:32:34,780 --> 00:32:42,200 using their tokens to our device to the our impersonate device and now we can impersonate the 348 00:32:42,200 --> 00:32:48,960 user. So we're cancelling the tunnel and waiting for the real device to issue new tunnel and we're 349 00:32:48,960 --> 00:32:56,180 using the token to actually connect to the real device. Next we're uh creating new mounting point 350 00:32:56,180 --> 00:33:02,340 to point at slash stamp and we are writing our file which will be parsed and be used in the reboot 351 00:33:02,340 --> 00:33:04,760 process. Finally giving us a real device to connect to the real device. And we're uh creating a new 352 00:33:04,760 --> 00:33:20,400 reverse shell. And and this is exactly what we did in Pongtuon so we got uh on top of the 353 00:33:20,400 --> 00:33:29,680 reverse shell we got also 40k so it was nice. Uh we we used it to hack a device in Pongtuon but 354 00:33:29,680 --> 00:33:36,120 basically we were not limited to just Pongtuon or or a single device. We could exploit any device 355 00:33:36,120 --> 00:33:42,580 that we know the it's device identification the GUID and we had thousands of of them maybe 356 00:33:42,580 --> 00:33:49,360 maybe millions. So it was a great power and with great power comes great responsibility. So 357 00:33:49,360 --> 00:33:54,180 uh obviously we reported this to Western Digital and we worked with them until everything was 358 00:33:54,180 --> 00:33:59,660 resolved. Now we uh we had a concept in our hands and we had a concept in our hands that we 359 00:33:59,680 --> 00:34:06,900 had. So basically uh we had the concept of impersonating an IOT device and using and 360 00:34:06,900 --> 00:34:11,560 leverage this impersonation to do something on behalf of the device. In this case in the 361 00:34:11,560 --> 00:34:17,000 Western Digital case it was impersonating a device and waiting to get the user token to use it. 362 00:34:17,200 --> 00:34:24,480 But since we competed in Pongtuon we wanted to leverage this for Synology as well. So let's go 363 00:34:24,480 --> 00:34:29,660 over in real quick uh what we did in Synology. So for Synology we wrote a code that was 364 00:34:29,680 --> 00:34:35,880 designed to research the DS920. Uh this is very similar device uh to the WD. Uh it's also 365 00:34:35,880 --> 00:34:44,400 Linux based with 86 architecture 64 bit. Uh and it had um a really fully featured web interface 366 00:34:44,860 --> 00:34:52,880 uh running CGI's written in C++. Um behind the scene the web server is Nginx and it has a 367 00:34:52,880 --> 00:34:59,620 very rich configuration that we could play with. Uh but we could not find any straightforward pre-authentication. 368 00:34:59,680 --> 00:35:01,680 Uh so without that we changed the code and we have a very dedicated remote code execution uh 369 00:35:01,680 --> 00:35:10,300 chains so we turned out to the cloud. Now similar to previous uh device West Synology has uh a 370 00:35:10,300 --> 00:35:16,040 fully featured cloud called quick connect. So basically if anyone wants to reach their device 371 00:35:16,040 --> 00:35:23,580 they'll go to quick connect dot 2 and will enter their device alias. How do you get to a device 372 00:35:23,580 --> 00:35:29,660 alias? You first need to authenticate on the device itself and associate the SS2 with the other device. 373 00:35:29,680 --> 00:35:36,520 the device with your Synology user. Whenever you do this uh in the web configuration on the 374 00:35:36,520 --> 00:35:43,200 device itself you uh basically exchange a couple of uh tokens and APIs on the device and now the 375 00:35:43,200 --> 00:35:50,980 device is capable to connect to the cloud uh and be associated with the alias you give it. So 376 00:35:51,460 --> 00:35:59,100 very simply how it works whenever a user go goes to quick connect um and wants to initiate uh 377 00:35:59,100 --> 00:36:05,840 connection to their device they will they will go to alias dot quick connect dot two and the 378 00:36:05,840 --> 00:36:13,780 cloud will relay uh the request to the device and basically will tell the device to open a VPN 379 00:36:13,780 --> 00:36:19,880 tunnel. So whenever the Synology quick connect cloud received the request it will initiate a 380 00:36:19,880 --> 00:36:27,600 tunnel open VPN tunnel with the device uh and now the user can reach their device through this uh 381 00:36:27,600 --> 00:36:29,080 relay point through the device. So uh if you have a connection to the device uh you can 382 00:36:29,100 --> 00:36:34,360 connect to the device inside the VPN tunnel. Now if you noticed uh we're also using here 383 00:36:34,360 --> 00:36:41,820 subdomains so we could also harvest all the aliases of all Synology devices in the world uh and 384 00:36:41,820 --> 00:36:46,780 yeah we did the same so we had a list of uh thousands of maybe millions of subdomains 385 00:36:46,780 --> 00:36:53,920 basically aliases of devices of Synology devices. But we wanted more obviously we wanted to 386 00:36:53,920 --> 00:36:59,080 understand how does the device what type of tokens or secrets does the device need to be 387 00:36:59,080 --> 00:37:07,260 used to connect to quick quick connect cloud platform and uh to initiate the VPN tunnel. So we 388 00:37:07,260 --> 00:37:15,480 researched this process for a very long time uh because it it is a long process um and if we 389 00:37:15,480 --> 00:37:20,720 summarize all the digital elements or the tokens or the secrets whatever you want to call it 390 00:37:20,720 --> 00:37:28,660 um we made a a quick list for this. So for example the device needs to know its MAC address serial 391 00:37:28,660 --> 00:37:36,380 number device module some tokens in order to connect to the quick connect cloud platform and start 392 00:37:36,380 --> 00:37:42,380 and initiate this tunnel. So if we wanted to impersonate the device we had to have these 393 00:37:42,940 --> 00:37:48,420 identifiers. And if you look at it some of the identifiers are quite straightforward for example 394 00:37:48,420 --> 00:37:58,580 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 395 00:37:58,660 --> 00:38:05,100 utility so whenever you buy a new device you can activate the discovery utility and search for devices 396 00:38:05,100 --> 00:38:12,260 around you on the local network. So we basically implemented this protocol to get the basic 397 00:38:12,260 --> 00:38:20,560 identifiers such as serial number module and MAC. So now we had the first uh elements that we needed 398 00:38:20,840 --> 00:38:28,640 uh for uh the first element that we needed to impersonate the device. By the way the DS token is a 399 00:38:28,660 --> 00:38:36,960 uh is some kind of uh deterministic um algorithm that based on the serial number so whenever we 400 00:38:36,960 --> 00:38:44,840 had the serial number we could now calculate this uh DS token. Um next we had to get the API key 401 00:38:44,840 --> 00:38:51,980 which is the device quick connect key. This token and also the authentication token are tokens that 402 00:38:51,980 --> 00:38:58,640 are being generated whenever the user associates their their Synology user on the device. So this is 403 00:38:58,660 --> 00:39:04,860 the device. So we thought it could be impossible to get those because it only happens once on the 404 00:39:04,860 --> 00:39:13,180 device and then they're not being exchanged anymore. But after researching a lot of different endpoints 405 00:39:13,180 --> 00:39:18,400 and routes on the cloud platform and also researching and reverse engineering different binaries 406 00:39:18,960 --> 00:39:28,520 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 407 00:39:28,520 --> 00:39:36,840 cloud platform. So apparently if we try we ask nicely the cloud to register for us a new API token 408 00:39:36,840 --> 00:39:44,300 and just giving it a serial number it will be enough to generate a new valid API token on behalf of the 409 00:39:44,300 --> 00:39:50,400 device. So just by knowing the serial number and the MAC address and also the mod model we could 410 00:39:50,400 --> 00:39:58,500 actually generate new API token for the device and use it. That was crazy. Next we needed uh uh uh uh 411 00:39:58,520 --> 00:40:05,240 authentication key uh which was very similar it it's another token uh but also a different uh a token 412 00:40:05,240 --> 00:40:11,160 that we needed to get access to. Uh and we thought we were very lucky in the first time so there is no 413 00:40:11,160 --> 00:40:17,960 way we were able to get this the second time but we were able to get this uh due to another bug in 414 00:40:17,960 --> 00:40:27,380 another feature uh of uh DNS uh DDN dynamic DNS feature of the devices. Uh so basically again they 415 00:40:27,380 --> 00:40:33,200 forgot to do some stronger authentication and again we were able to get this token that we 416 00:40:33,200 --> 00:40:39,960 needed to impersonate a device. Now that we had both tokens and all the basic identifiers we 417 00:40:39,960 --> 00:40:46,400 basically could receive any information we want on the device and we had our list completed. So we 418 00:40:46,400 --> 00:40:51,760 had all the information we need in order to impersonate any Synology device that we want. 419 00:40:52,060 --> 00:40:57,360 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 420 00:40:57,380 --> 00:41:05,040 now we're in the context of a real uh device. We impersonated a real device and we thought how 421 00:41:05,040 --> 00:41:12,260 can we leverage this into a remote code execution. So the first thing that we did was telling the 422 00:41:12,260 --> 00:41:21,860 cloud hey we're this real device for real. Please change the IP address that you think I'm at to 423 00:41:21,860 --> 00:41:27,180 a different one. Basically what we were trying to do is to make the cloud plot 424 00:41:27,180 --> 00:41:35,000 form to relay users instead of the real device to our CNC. And it worked because we fully 425 00:41:35,000 --> 00:41:39,980 impersonated the device and the cloud fully trusted us. We had all the secrets. We had the tokens, we 426 00:41:39,980 --> 00:41:43,920 had the serial number, we had the MAC address, we had everything that we need. And the server 427 00:41:43,920 --> 00:41:53,100 really relayed users to our CNC and again we got their tokens and we were able to access uh the real device. 428 00:41:59,560 --> 00:42:10,940 Thank you. Uh so just to sum up real quick. Users wants to connect to their devices. But because 429 00:42:10,940 --> 00:42:18,140 of a couple of flaws and vulnerabilities we uncovered in the cloud architecture we were able to 430 00:42:18,140 --> 00:42:26,860 redirect users to our impersonated device. Once we were getting the user tokens we used these tokens 431 00:42:27,180 --> 00:42:34,520 and impersonated the users so we basically connected on behalf of the users to their real device. 432 00:42:35,850 --> 00:42:41,880 Now to sum up. Cloud services focus on strong user authentication. It's very difficult these 433 00:42:41,880 --> 00:42:48,480 days to bypass user authentication. But we believe that device authentication is a bit 434 00:42:48,480 --> 00:42:57,160 overlooked. So in many cases we've seen IOT architectures using weak or public knowledge to 435 00:42:58,520 --> 00:43:04,580 authenticate devices. So obviously this needs to be changed and we already contacted a couple of 436 00:43:04,580 --> 00:43:11,180 big vendors uh that we found bugs in. So maybe we'll be here next week, next year. Uh and we 437 00:43:11,180 --> 00:43:17,900 really want to change this and emphasize that impersonated devices can be real danger. Thank 438 00:43:17,900 --> 00:43:27,160 you. So I'm not sure about questions. Should we do questions? I'm not sure about questions. 439 00:43:27,180 --> 00:43:37,020 Here? Okay. You're invited to follow us wherever you go. Thank you.