 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 Brzezinov 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 PLC's HMI's and of course like I'm gonna show you this 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 And of course, we'd like to make huge tanks to the other team-added to researchers that helped us in this research Uri cuts and veraments huge tanks to you and your guys rock So let's talk about what we're gonna showcase to you today You see I have a nas at home where I stole 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 way that's why when point one competition in Toronto last year Decided to do the nas category. Well, the goal was to hack and exploit a remote code execution Vulnerabilities on these nas devices that which one of which I actually own I said, yeah Let's do it and let's go all in and let's spawn both of these devices You see we try to look at kind of isoteric features because both of these nas devices Were quite old and looked at by different researcher groups over the years So we try to look to 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 realize that actually both of These nas platforms have a cloud platforms allowing users to actually access and use their nas remotely through the cloud in the case of Western Digital it is what my cloud OS 5 and in the case of psychology. It is we connect and Cloud services now I asked myself. What's the use case here? Why should I enable my cloud and my device to connect the cloud and actually? That's the reason you see my nas sits at home where I save all my seven important stuff to it And I am out and about I could be at work. I could be an invocation, etc 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 and 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 gained in the months leading to Ponto on 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 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 Ponto on competition netting us 40k Dollars 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 any cloud connected device giving us access to billion 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 is 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 you intrigued you But let's do dive and see how we uncovered all of these vulnerabilities and what kind of abilities we actually managed to achieve So let's start with Western digital in the Ponto on competition. We looked at Western digital PR for 1 double 0 This is the the Qt 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 exists like fs and b FTP and of course accessing the files over the HTTP requests Well, the first thing I did was order the device However, I am a very impatient man meaning I could not wait for the postal service to get my device to me That's why I went to Western digital's website and looked for a firmware download in the summer When trying to emulate my device and getting access to it even before it arrives Usually when we work with filmers, there are two options either the firm is encrypted Meaning everything is encrypted somehow and the device decrypts it 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 their firmware Meaning we add access to all of the different files file system binaries configurations, etc That are running inside our NAS device Sadly, this room 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 its 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 rebuild 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 where are the configuration files What binaries are actually being executed and even more important. I had a playground that I couldn't break I tend to break devices that I look at and my boss has to reorder once and he gets mad at me Especially when they are super expensive So now 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 researchers 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 Ponto on competition In order to remedy that Western Digital had a genius idea of just wrapping it all up in a Golang binary That actually authenticates and authorizes all 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 quest had to be authenticated It was not that useful in the Ponto on competition because every quest every exploit should be authenticated This meant that we had to scrap this entire lead and look for new lead 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 they 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 exp use your 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 realize that we thought ourselves how the hell does this magic happens? How am I navigated and routed to my nas device? 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 seeds Since somehow they route my request to my corresponding nas device and this tunnel is created However, we thought to ourselves what would happen if some attacker knew my device is good 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 open 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 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's 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 devices GUID which is 128 random bit A GUID find somehow some authentication by bypasses and exploit some vulnerabilities to run hold on our device Yeah, pretty easy So let's try and understand what is the use case once again You see this is the regular use case in the nas architecture as 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 ask 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 notice something weird. What is that? As you can see embedded in the certificate here it lies my devices GUID This means that by simply fetching and accessing my device through the HTTPS services I am able to get the device's certificate and carve out the GUID through through it Well, 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 an slookup on my device's 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 a DNS record was created and because it was created of course 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 that are performed to your 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 in order to basically get access to what kind of DNS queries you used and Because we did good 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 add access to tens of thousands Guids Sadly when we tried accessing Actually accessing these goods through Western Digital's cloud most of them were already dead and not disconnected That's because we don't know when the read DNS record was created and there were no login connected anyways This meant we know didn't actually have 10,000 records However, we had a good lead into actually improving the amount of the goods we know off That's when we realized that because the certificate is issued to every device every connected device and This certificate contains the device good. Maybe we can use what's called certificate harvesting similar to the passive DNS Celvels that a lot of Celvels offering the ability of you to users to look for Certificates they encounter and look for patterns in the certificate name For example, we use census which both they have over six billion certificates in their databases allowing users to query and fetch these certificates When we tried and grep for Western Digital pattern, we realized something shocking There was over 1.5 million devices just in the last three months And now we had the knowledge of every one of these devices good meaning we were able to access them through Western Digital's Cloud platforms However, sadly in the point-to-one competition you have to do it live meaning we cannot Know the good in advance and our device is connected in real time This meant we had to somehow get access to good and get knowledge of goods in real time That's when we discovered something pretty cool Which I wasn't the word in the past which code which is called 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 issues Missed 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 grep for Western Digital pattern And that way we were able to get a devices GUIDs whenever they actually connected to the Network in the first time Meaning we had the ability to leak GUID and leak the 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 devices 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 out-bypass Well, since we are a community in Oroak, we simply asked someone. Hey, can we can we use your device? We promised not to break it and luckily we didn't so we didn't have to buy a new one And so we tried basically accessing the devices 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 change the devices GUID from our own to the GUID we wanted to test our theories on and That's when we realized the some API routes actually worked as you can see here We are fetching at 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 work 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 session and is connected to my account I can access anyone NAS through some API routes by simply changing the devices 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 Sadly around two months two weeks before the competitions. I tried my scripts which worked perfectly. I swear And they stopped working Something change in Western Digital backends and the authorization checked was added Which was pretty sad because it took many months of 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 overnights 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 cells and handle more of 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 really in better 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 the generic as much as possible All I had to do was simply create a metamany the 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 many in the middle HTTPS 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 through when we had this ability our first goal was simply understanding how the hell does the tunnel Proxy creation Happens how my device connects to the cloud and inform is it hey I'm this and that device please redirect users to me and through the process of manning the middle and reverse engineering Re-reach 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 AP my device then says yeah, okay I'm ready to connect and simply hands over the device as good saying hey, I'm good. 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 any all the things that my device sent to the cloud was my device is good Which like I've showcased to you before is goddamn public knowledge meaning it is actually exposed on my devices Certificates this meant that by simply knowing devices good 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 decent that good and the minute we did that The server actually trusted that and say yeah I'm ready to initiate the connection and this connected the real device Meaning that whenever a user tries to connect to a to their device now, they would be redirected to us That is pretty crazy because now we were able to impersonate the device and act as it 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 want to refresh the volumes on my nas device However, what's crazy is that it actually contains the user authentication token We didn't we were actually pre-stomped at first saying yeah, we didn't make this request however, upon first investigation we realized that in order to make sure everything is up to date and Users have been good user experience Western digital performs background up 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 devices tunnel We got a request from the user containing the user token and this actually meant that the minute we stole devices tunnel We have a 10 to admit 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 implodes Yeah, that we actually did it. We actually got this access twice in two months, which I think is the 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 so Just let let's reiterate real quick We were able to leak all the goods all the device Identifications from every Western digital cloud connected device and we used it Because of a flaw in their arcade cloud architecture. We we used it to basically find a bypass to their authentication and reach the devices so we first Impersonated the devices once we're in person at the devices we got to redirection and We got requests from real users with their tokens and we now were able to impersonate the users so basically we had admin access in While impersonating users we had admin access to their devices Because after we created the tunnel impersonate the real the devices We got the tokens and we disconnected our tunnel and we were able to connect to the real device tunnel But sadly we wanted 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 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 API's and as Noah mentioned This was a go long so it was very difficult and the time-consuming to go over all the functions But we now had new new vector Authenticated vector. So it was very important for us to cover more API's and more routes The first one of the first routes we looked at was the shares shares and mounts So we're talking about a NAS device now, obviously a NAS device 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 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 pub public directory in the web interface or the mobile application basically shows you the content of hd 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 The routes the mounting points on the device simply by using the the file system API we could now change directories change start via 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 that these files and directories were not allowed to be accessed from the mobile application Obviously 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 Right 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 because the file system had some restrictions to where files can be written Some directories and some mounting points were read only so for example, we could not override Bineries on the device 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 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 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 a Reboot process on the device now what we found out is the reboot process is not that straightforward on the devices So it's not just doing reboot it 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 parse data somehow Western Digital did this because there are many ways or many Many times you'll the device will want to do reboot based on different states For example, it wants to initiate how to reboot whenever there is a firmware upgrade So it needs to read these states from somewhere and they decided that to use files on slash temp so what we did is we investigated these Code path in the binary and we found that we can write a file to slash temp in a way that will Give us some injection point into a system command which will be which will get executed So now we had the ability to execute code on the device if we are authenticated which we were And we had our chain complete. So I would like to go over the full chain Basically, it starts with us licking goods of all the devices in the world And we can even do this real time as not 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 temp and getting and doing reboot and getting code execution So let's see it full scale now the user first of all the real user is connected to the device and We as attackers want to get their device So we're impersonating the device by telling the cloud. Hey, we're at 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 either using their tokens to our device to the our impersonated device And now we can impersonate the user. So we're Canceling 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 creating new mounting point to point at slash temp And we are writing our file which will be parsed and be used in the reboot process Finally giving us a reverse shell And and this is exactly what we did in punk to own so we got On top of the reverse shell we got also 40k so it was nice We we used it to hack a device in phone to on but basically We were not limited to just put on or a single device We could exploit any device that we know the its device identification the good and we had Thousands of of them may be maybe million so it was a great power and with great power comes great responsibility So obviously we reported this to Western Digital and we worked with them until everything was resolved now we We had a concept in our hands. So basically 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 impersonated advice and waiting to get the user token to use it But since we competed in punk to own we wanted to leverage this for Synology as well. So let's go over in real quick. What we did is Synology So for Synology we researched the DS 920. This is very similar device to the but WD It's also Linux based with 86 architecture 64 bit and it had a Really fully featured web interface Running CGI is written in C++ Behind us in the web server is angonix and it has a very rich Configuration that we could play with but we could not find any straightforward pre-authenticated remote code execution Chains so we turned out to the cloud now similar to previous device with Synology has a fully featured cloud called quick connect So basically if anyone wants to reach their device, they'll go to quick connect to that too and Will enter their device alias. How do you get your device alias? You first need to authenticate on the device itself and associate the device with your Synology user whatever you do this in the web configuration on the device itself you Basically exchange a couple of tokens and APIs on the device and now the device is capable to connect to the cloud And be associated with the alias. You give it So very simply how it works whenever a user go goes to quick connect and Wants to initiate Connection to their device. They will they will go to alias dot quick connect dot two and the cloud will relay The request to the device and basically will tell the device to open a VPN tunnel So whenever the Synology quick connect cloud receive the request it will initiate a tunnel open VPN tunnel with the device And now the user can reach their device through this relay point Inside the VPN tunnel now if you noticed or we're also using here sub domains So we could also harvest all of the aliases of all Synology devices in the world And yeah, we did the same so we had the list of Thousands of maybe millions of sub domains 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 use to connect to quick quick connect cloud platform and To initiate the VPN tunnel so we researched this process for a very long time because it it is a long process and If we summarize all the digital elements or the tokens or the secrets, whatever you want to call it We made 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 Apparently Synology this 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 a serial number module and MAC. So now we had the first elements that we needed for The first elements that we needed to impersonate the device By the way, the DS token is some kind of a deterministic Algorithm that based on the serial number. So whenever we had the serial number, we could now calculate this DS token 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 Thayer use Synology user on the device. So We thought it could be impossible to get those because it only happens once on the device and then there are 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 other endpoints on the device itself We figured there is a bug 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 model We could actually generate new API token for the device and use it. That was crazy Next we needed the Authentication key which was very similar. It's another token, but also a different a token that we needed to get access to And we thought we were very lacking the first time So there is no way we were able to get this the second time, but We were able to get this due to another bug in another feature of DNS The dynamic DNS feature of the devices So basically again, they forgot to do some stronger authentication And again, we were able to get this token that we needed to impersonate the 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 now were in the context of a real 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 platform 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 the real device Thank you 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 the 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 and dating fires to authenticate devices So obviously this needs to be changed and we already contacted a couple of big vendors that we found bugs in so maybe we'll be here next week next year 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 here? Okay, you're invited to follow us wherever you go. Thank you