BSidesBCN21 - Smart Home Devices: Assets or Liabilities? (Jonah Bellemans)

then out of my home but you know i would like to hear what you know is bringing to you to the table so stage is just jenna uh good luck with the presentation right thank you alejandro um welcome everybody today indeed i'm going to present my talk on smart home devices and we'll take a look at whether they're assets in your household or liabilities in your household or a bit of both first i would like to quickly introduce myself i am a consultant on the cyber strategy team of the consultancy company and viso located in brussels belgium where i use my technical background to solve more high level and strategic problems for clients i have a master's degree in

computer science but i'm complementing that one with another master's program in ict law so i can get a bit of both of those topics you have my contact details there as well the research i will be presenting for you today was actually conducted as my master thesis in computer science at the university of durban in collaboration with the labs division at the visa called invisalups so it was done in 2020 under the paper the state of the market a comparative study of iot device security implementations that paper should be publicly available on the libraries of kai11 so if you are interested after this talk to read the entire thing you can take a look on the reference

there and read it for today i will go over the context of the research that we performed i will quickly explain our methodology our results and then we'll end with a conclusion and some future prospects that we can expect on the smart home devices markets we already mentioned that this talk is about smart home devices but what's the big deal with smart home devices anyway well i think at this point in time the smart home environments markets has boomed uh greatly we see more and more households where at least one or two devices have become smart even those people who didn't really go out of their way to buy a smart device i have a smart

tv these days um and it's almost impossible to to ban these items from your household entirely if you look at the market forecasts of zion market research we see that over the coming years that market is still expected to grow even further and that's where we got a bit concerned just like alejandra already mentioned every week or if not every day we see news articles popping up on the internet on all kinds of newspapers where there are security or privacy concerns or both about these smart home devices with people who are afraid of being spied on or a hacker taking them over one of the trends that we've seen a while ago was not even very technical people going

around more fancy neighborhoods go to a house where the window is open and yell alexa open the front door and in some cases that would work so you would think that this market is quite heavily regulated but that is actually not the case at the moment there is of course the normal cybersecurity regulations and the regulations on cyber crime that are there but there is no specific law at this point that will say a smart home device of a certain kind needs to adhere to certain requirements for privacy that is a different story because of course we have quite some privacy regulations in place we have the fundamental charters which is the european convention of human

rights that outlines the right to privacy there's also the charter of fundamental rights of the european union that again confirms that right to privacy and then in the european union specifically we also have the gdpr the very well-known general data protection regulation as well as the e-privacy directive which is currently being reviewed for a newer version to be more in line with that gdpr so we have some regulation on privacy but not on security and that's what we were wondering do we need regulation on the security of these smart home devices so we decided to do some tests and to give you an idea what we tested well we bought a range of devices these devices they were chosen based on

a few selection criteria to be as objective as possible so we take different devices with different kinds of popularity the availability was very important on the european market of course we took devices from different price ranges and with differing levels of brand recognition so as you can see on the schematic on the right we had of all types of devices that smart device hubs light bulbs baby monitors door locks and so on quite a few different devices and if it was possible we would always try to get two of the same kind from a different price range from a different brands so that we could compare the two it's not that was no not always possible but it was

something that we had as a goal and then when we had our devices we needed to test them so how did we define our tests well there is no binding regulation that says how the security of these devices should be done but there are some guidelines available the european institute for network and information security or nisa they publish guidelines a guideline document for smart home iot devices in which they have some policy recommendations we took that document you see a small fragment of that document on the slide with some uh with some markings on it we took those policy recommendations and we would define a test case to comply with those policy recommendations so one example

test case from our set of tests was to verify that the encryption configurations that were used for the communications that they are adequate in that case we are talking about tls we wanted to make sure that our tests covered a very wide area of aspects of security so we made a deliberate choice not to go very in-depth do not dig deep into each device because we had in total 15 devices to test and a limited time to do so so instead we went for tests that were very repeatable that we could uh use automated tooling for and standardize procedures so that anyone else doing the same research with the same methodology would have the same

conclusion then we also allocated a fixed time for each test so that the testing could never take longer than an allocated time for each device and as i already mentioned we wanted to cover a very wide attack surface instead of a very specific narrow one that we went deeper into and that brings us to the methodology for security we had a test setup that looked a bit like this this is what we would call a typical household with smart devices in it so on the slide here we have the internet represented as a cloud and your home router is connected to the internet for you where you have your smart device in this case we chose a

camera and you have maybe your home laptop that's also connected to that same router on the other hand you also have a phone tower cell phone tower that you connect to with your cell phone and again your cell phone is connected to the internet where you can also access your device that way for a test setup we changed very little about that we had the same type of setup except we added a raspberry pi in the middle of the connection between the device and the router to act as a man in the middle to intercept the data traffic going through that connection for those who are unfamiliar with the raspberry pi it's a device that looks

like this it's uh in essence a small computer you run software units that you use to impersonate an access point and then also to capture the data so as i already mentioned we wanted to take a look at network communications for network communications we used wireshark which is a very well known tool to do the traffic captures and there we took a look at the data that was going through in terms of quantity but also the protocols that were being used by the device itself and we wanted to know whether or not there was any encryption on that data applied or not of course we can also take a look at the device itself the device here it is sitting there in

the network running system and operating system and services where we wanted to do port scanning with nmop on the device we also did some service discovery with nmop and a vulnerability scan with nasa's to see what we could find on the software on top of that we have the mobile application that is often used to interact with these devices there we took a look at the android app for the device usually we took the android app just for the ease of use of our testing tool we used mob sf for the mobile security framework to do those testing and it was just much easier to get a hold of the package for an android app

than for an iphone app so that's why we went with android uh with mobizef we performed static analysis on the application so we took a look at the permissions that were requested by an application we took a look at the domains that could be found in the code of the application and also whether or not there were any trackers present on that device then last but not least there is the web interface of a device as well a web interface well we have actually two options for those either we have a local interface running on the device and then it's accessible over the local network so it will go from your laptop to the router to the device and would access it

directly or we would have a cloud interface where the internet was an intermediary and the device would be connected to the internet and then your laptop would also connect to the internet to configure it in the case of a local interface we had all freedom to do with it what we wanted in that case we ran a nicto and a burp suite active scan on it but on a cloud interface we didn't have that freedom that liberty to run those more aggressive scans often there was another bug bounty program available that we could use to test the cloud interface uh so in those cases we had to rely on quality ssl apps just to check the tls configuration of

that web interface and see if we could derive anything about the security of the interface from the configuration of tls on that platform if then take a look at the results you will see that when we start with looking at the network communications there were quite a few differences in the amount of data sent by each of these devices and sometimes that makes a lot of sense a voice assistant or a camera is a device that is constantly streaming data for the network to the cloud interface uh in those cases it makes a lot of sense that there's this amount of data going through but then again we also have um some less uh active devices i would

say are less data heavy devices like the doorbell uh that we're still consuming quite a lot of data especially here we see that the light bulbs and the doorbell have almost equal amounts of data quite high still on the list and that was rather surprising for us if we then look at the used protocols by the devices we see that the vast majority of traffic is raw tcp and raw udp that means that wireshark didn't recognize the protocol that was running on top of the raw tcp or udp that was being used by the device either because it was an unknown protocol or it was because the data was encrypted and it just didn't recognize it

but then again if we expect encrypted traffic we would think that even there they would use standardized protocol and that's then the runner-up in our analysis we see that tls was being used in a lot of cases as well most of the time that was tls version 1.2 but sometimes we also had some stragglers as devices with tls version one or a few devices that were ahead of the others with cls version 1.3 as i mentioned we wanted to know if the data was encrypted or not and since we only had the info raw tcp or raw udp to go on we did some extra analysis on those network communications in more specifically we took a box plot

of all of the data that went through it in terms of entropy of that data stream so if you have for each vertical box plot there is one device we took that data stream in its entirety and we would look at each stream's informational entropy a higher entropy meaning it's likely going to be encrypted or at least compressed in some way or another and lower scores indicating that it's likely very structured data indicating plain text or something very very structured something that repeats itself all the time if we then draw a line almost in the middle of this bar we see that on the tcp side the vast majority was on the encrypted side but for udp streams we see that

quite a lot of the data was unencrypted one explanation that we could think of for that is that a lot of the dns traffic sent by a device is largely unencrypted and would fall under the udp streams side of bins then i also mentioned that we would do a port scan and a vulnerability scan on each device with nmop uh on the left you can see the results of that uh and mob tried very hard to find out which services were running on the devices but most of the time they would come up uncertain or as unknown and on the right we see the results of our nessus come where the vast majority of the vulnerabilities that we found

were not vulnerabilities at all they just were informational findings and in a very very small amount of cases we actually found some medium severity vulnerabilities and we pondered some time on what this could mean for us but in fact we came to the conclusion that it means that we can't really trust these tools to begin with it doesn't mean that these vulnerabilities are not there it just means an automated tool is likely not going to be very useful to determine what kind of vulnerabilities are present on a device just because it's using unknown protocols custom protocols that are not recognized by these tools so if you want to have a very good view on vulnerabilities there you would have to

do a manual search and dentist for them next in the line we see mobile applications my mobile applications as i already mentioned we took a look at trackers present in the device and the vast majority there would be google firebase analytics or google crashlytics these are often used to analyze how an app is used and to make the experience better or to find out why a crash occurred and then try to book fix it but then very closely followed by those two leaders we have the very well-known advertising trackers that are also still present in these applications that was rather surprising to us that we would find this many trackers in them considering that if you buy a smart

device you already paid for it once and then again you seem to be paying with your data nevertheless when you install the application on your phone these applications also get access to quite a lot of infrastructure or functionality of your device um in a lot of the cases it will have to ask the user for a permission to do so so in the android case we have two types of permissions that we define we have dangerous permissions and normal permissions as indicated on the slides when a permission is marked as dangerous according to androids it's any type of permission that could have an impact on the data of the user leak the data of the user or send it

over to the internet and sometimes it doesn't mean that the application permission even if it's smart as dangerous is not asked for a legitimate reason for example internet access would be qualified as a dangerous permission even though obviously all of these apps needed to function properly but in some cases we still found that there were quite some surprising amount of application permissions requested by these apps most notably we see that the smart device hubs and the voice assistants they score very high on that and in those cases it might be defensible that they need access to your microphone your camera or your location to provide certain functionality but then if we look a bit lower on the list

we also see that an application for light bulbs requested those permissions as well a very high amount more notably one light bulb asked for microphone permissions or camera permissions and that's something that we didn't really expect to see on an application for that type of products then when we take a look at the web interfaces for the local ones we found some interesting results there we saw that on the local web interfaces that we could access with burp suites we either had very severe vulnerabilities or again nothing at all most of the vulnerabilities that came out of this were the clear text submission of passwords or just unencrypted communications in general and that was the case on quite a few of

these devices also on the other side of them uh that's pendulum we see that uh even if there are some very severe vulnerabilities found all the other findings were largely informational and we couldn't really derive anything from those either so for their uh for those web interfaces we think or we believe that it's likely that the manufacturer didn't feel like they needed to implement encryption or tls on the local interface because most of the time it's only used within the local network but again we would say that that's not always the case we see so many devices just exposed on the internet over for example web engines like showdown where we think that there is really no excuse not to be

using https on those devices even if it's a local interface then we arrive at the privacy and there we tested two main things the first one is under the gdpr data subject access requests or very simply put your right as a consumer to ask the manufacturer of a device who is processing your data to have a copy of that data and also to remove it and then on the other hand we tested the privacy policy for each of these devices so for a data subject access request we would send a very simple request to ask all of our data and we would ask some additional questions on top of that about the data processing we would then check how easy it was to

file that subject access requests how complete the answer from the manufacturer was and how complete the returned data of that manufacturer was when we took a look at the privacy policy there we took a look at the accessibility of the policy how easy it was to find it we took a look at the up-to-dateness of that policy the last time it was updated to see if the the data in that policy was still accurate and also to see if it was complete under the gdpr there are a few articles that very concretely specify which information should be in a privacy policy or otherwise communicated to the data subject and we would check those policies to see if all the information

was present then if we take a look at the results on the privacy front we see that it was quite often very difficult to find the compact details of a manufacturer in a lot of the cases we saw that there was a privacy policy quite easily accessible on the website but then it was for the wrong region or it was completely outdated and they referred to a new one that was much more difficult to find in some other cases they only had the scope of their website in the privacy policy and their product was not in scope of it so it turned out to be quite difficult to find a definitive policy and then even if we did find the policy

it didn't always have the contact details so we needed to know how to file our access request of course and then we would email either their privacy department or their dpo in some cases we couldn't find these details at all and then we just emailed to their info address on the website but in most of the cases after some finding we then ended up having a contact person if we then look at how many of these manufacturers replied to our requests we see that about one third of these manufacturers even though they had plenty of time multiple months to reply to our request they never replied to us and then even if we look at the ones

that did reply we see that in most of the cases they would not give a very complete answer to questions or not even at all some of these manufacturers would just dump all the data on top of you in a csv format and not answer your questions anymore others would try to answer your questions or just refer to the privacy policy but in almost none of the cases they were satisfactory or fully complete in their reply only in a very small amount of cases did we get a full email with replies i already mentioned that most of the time they would just dump a csv file on you with all of your data but even if we look at the completeness

of that data we see that in most of the cases it was very very dissatisfactory most of these companies would just give you back the data that you give them in the first place which is a good first step but of course you also expect them to give you all the data that they derived from you that they gathered on you over the time frame that you've been using their device and that was quite often either very underrepresented or just not present in the data that they gave you back even if we would ask for it specifically uh either we would not get a reply anymore or they would just say that they didn't have it um which we obviously

obviously cannot prove that they don't have it but we can suspect that they do if we take a look at the privacy policies i already mentioned that it was often quite difficult to find the policy in the first place uh but on top of that when we did find one we checked those articles in gdpr for each of these requirements to see what was present in the policy or not if you want to read this table so we have every device we come here and then we have the requirements listed up here so for alarm one we can see that quite a lot of the requirements were met some of them were not and the tilde sign in orange here means

that it was either implied or it was probably not necessary and some of these are conditional so if we think it wasn't necessary to list that requirement on the policy we would either mark it as a tilde or because it was implied but not specifically mentioned there are two things that we can get out of this table the first one is that for alarm 2 there was nothing at all in the policy that should have been there and for the voice assistant almost all of the elements that need to be covered were present in the policy so we see a large gap in maturity between these two some of them scored very well and others scored very poorly and there

was not really a middle ground it was either one or the other of course we can also check on which of these requirements scored the best and which of these requirements scored the worst and if we take a look at which of the gdpr requirements were largely not present in policies even though we thought they should have been we see that for article 13 1 gdpr there's the requirements uh there i have d where the processing is based on point f of article six the legitimate interest pursued by the controller or by a third party need to be present in the privacy policy so what that means is that if your controller your data controller says they process your data

based on their own legitimate interests they need to tell you what these legitimate interests are and quite quite often we saw that manufacturing would just say reprocess your data based on legitimate interest but they wouldn't list which legitimate interest that that would be or they would stay very very vague and then we would disqualify it as a good answer then if we take a look at article 13 2 gdpr we also have two other requirements more likely here e and f the requirement e is whether the provision of personal data is a statutory or contractual requirement in other words if it's required to give your personal data to them um either to uh to do so

under law or under contact that you have with them and also if it is necessary to enter into that contract with them that was something that was quite often implied they would just imply that yes you need to give them your data if you want to use their products but it was never explicitly in the policy just in one case then we also have article 132 paragraph f of gdpr where the existence of automated decision making needs to be told to you including profiling if they do it and there many of them never mentioned automated decision making at all they didn't say whether or not they did it it was just not present in the

policy whatsoever so what can we learn from all of this well for security we have three conclusions the first one is that it's quite a hit or miss with these devices we see that a very few security measures are taken on some of these devices as opposed to others who have a very solid security implementation and that there's really no middle grounds usually when security is considered for a device it's considered across the board and otherwise it's also just not a concern for a manufacturer then you will see no security anywhere on the device as a second point we had a lot of assessment difficulties as i already mentioned a lot of these devices use non-standard technologies

they use non-conventional cryptography and there's quite often no proper documentation about them on the internet or at least not publicly available so it's very difficult to find out how to assess the security on one of these devices quite often they used security by obscurity and that's something that we would always be against as the only security especially in this case we don't have a good way of finding out which devices are secure and which ones are not so what can you as a consumer look out for when you're in the store wanting to buy a device nobody would recommend to go for a known brand that has a reputation to defend and we see two types of devices on the

market we have devices that don't have a very well-known brand that move on to a new technology really quickly that maybe today is making smart ip cameras and tomorrow they'll be making smart doorbells and in a few months later they'll be making baby monitors and there they they really don't care about the security of their past products because their name is just not attached to it if you go for a known brand that has that reputation to work for you at least know that if a security vulnerability a high profile one is found in that device they will work on fixing it towards the future as a second point we recommend that you look at the transparency about security

before your purchase if you can find on their website notice about security or even the entire manual and it has a sectional security of the device outlined that's already a very good sign because it shows that at least security was given some thought when they were making the device and that means that you as a consumer also have some options to improve the security of the device then as a last point we see that automatic updates are very important not just in general but especially for these devices because many people buy a smart camera a smart tv and so on and they put it on the network and as long as it keeps working they never update it if

the device is not going to ask about updating it then you will just as a user let it sit there until it breaks and that means that if you buy a device even if it's secure today that in two years likely a vulnerability will have been found and it's not secure anymore so if you can get automatic updates on those devices it's one less thing on your to-do list and it's one more thing that the device is keeping itself secure when we take a look at privacy we actually see that same gap in maturity arise again we see that some of these manufacturers were at least putting in an effort to be gdpr compliant not

always successful granted but at least they would try and some others were not gdpr compliant at all that gap was mostly notable for countries that were outside of the european union and had less affinity with european legal framework where it was really much of a this is too far from me story and they just didn't know that they were in the scope of gdpr or they didn't care about it then we also see a shift in mentality i added a reference on the bottom of the slide here for some very interesting research by uh historically from car 11 as well that actually did a very similar test about data subject access rights in the time before gdpr went into force to see

what they would get as a reply from companies and they were really met in their paper they described being met with very mean replies some of these manufacturers would say please stop bothering us this is exactly why we didn't incorporate in the eu or we just don't have time for this or they would just get yelled at or they didn't get a reply at all and that really changed all of our replies that we received were very friendly towards us even though they were not always useful they would still at least try to be useful so that's a very big shift in mentality that we've spotted uh compared to before gdpr and last but not least we think that as

i already mentioned there's that gap in maturity there is a need for enforcement on the gdpr front at the moment there's too little transparency about legal sanctions for companies that are not compliant with gdpr so even if they get fined not enough people know about it not enough other companies know about it and it just doesn't have enough visibility on top of that we see that there's not sufficient funding for dpas to adequately investigate all of the leaks that they get and most of the time they might be flooded with reports but they have to choose which ones they can handle and which ones they don't have time for and on top of that we see that that

leads to no meaningful enforcement of gdpr outside of the european economic area if they already have their hands full with just going after the companies in the european union that are not compliant and companies outside of it are usually getting off pretty easily and that means that they also don't really have a very big incentive to be gpr compliant and that brings us to the conclusion of regulation that's what we wanted to answer today we wanted to know if regulation for the security of those devices is needed specifically for them we see that we feel a need for a baseline of binding rules we feel that there should be certification to verify the minimum security requirements are fulfilled on

these devices and to keep that workable to keep that verifiable we think that it should be based on standardized hardened baseline components and you cannot verify the security of each and every device before it goes to markets but we feel like we can get a good baseline going by having standardized components that we know are secure and making sure that manufacturers use those to build their products on top of that we feel like a deep dive is also possible in the form of iot labels an iot label could be an additional indicator for consumer that a device went the extra mile for security but it could also be a competition point for manufacturers who want to stand out

from their competition and that's also not a strange concept those labels have existed in many sectors now so we don't see a reason why it wouldn't be available for iot devices as well so if we look at the future where do we go from here with this conclusion well in fact with the new well it's not very new anymore but the recently passed eu cyber security acts um it gives anissa a new mandate to provide standardization frameworks and certification frameworks for cyber security some time ago they released just one of those the eucc as a candidate scheme for that certification and in that candidate scheme they make a reference to a demo label that you can see here on the

slides that you could put on ict products um to to recognize it in the european union as a secure device so this is also something that we applaud of course and last but not least we see an eva an evolution in the landscape in the regulatory landscape where usually the regulatory landscape was very focused on critical infrastructure on uh too big to fail infrastructure and i.t we see now that there are more and more regulations also applying to the smaller companies the smaller products such as the smart home devices as i mentioned this research was done quite some time ago so we might think if it's still relevant today and for that i have a slide over

of a very recent news article here in belgium uh i'll translate the title for you it says watch out for cheap smart devices they are as leaky as a sieve and that is an article that was aired after research from k11 and from a very large consumer organization where they did very similar research they also took those smart devices a list of 16 of them tested the security and they came to very very similar conclusions this is an article from a few weeks ago so it learns us or it teaches us that nothing really has changed so far so i would like to leave you with low and last slide in this case a quote from

stefan napo at the internet of things devoid of comprehensive security management stantomans to the internet of threats and that's what i believe as well after doing this research if you want to get these smart devices get them by all means but make sure that you secure them as well otherwise you're just inviting nefarious people to break into your household thank you

that was an incredible presentation you got me thinking right from there so i really like the way that you test privacy you know the devices right the way you were testing you know the data cycle right so kudos that was an incredible job uh we're going to enjoy you know your presentation thank you so paulo i'm not sure if you've got any questions if not for one we don't have yet any questions from the norm for those likes from normal here in the in the zone but you can go on i also have a couple of questions myself because i also found really interesting stuff when you were talking about the doorbell right so you got me curious there

do you know the reasons why the dope was sending so much traffic to the internet um the doorbell it had one excuse although uh it's not a very solid one so it was a it was a video doorbell and it would activate on movement so there might have been some movement in the room that we used to test it although we tested it over 24 hour idle periods so it was sitting in the corner of a room nothing was moving there unless it somehow would trigger the motion sensor anyway there was really no reason why that device would be sending video footage um so it's uh it's a good question i don't know exactly why it was

sending that much data um but it's something that we did observe now okay i want to ask like a couple of questions one is like uh did you did you talk about the auto updates of the devices did you test how many of them were actually updating themselves and providing security patches you have them some yeah that's a good question we didn't formally test it so i don't have any numbers on that um but i did i did keep it in mind when i was testing the devices of course and i looked into it and the vast majority that we tested did not have automatic updates um mostly the voice assistants they would have automatic updates um the smart lock

would also automatically update um and then it would basically be either triggered via the mobile app so it was not automatic you would have to do it manually or in the even worse cases you would have to push firmware as a binary to the web interface via uploads um so those are the the really the the most difficult ones to update you would at first have to go to the website to download the binary and manually push it to the device yeah so totally manual updates yeah and the other the other thing is like do you have any advice like i guess like to do to do one on like it's all like these these devices

are secure a bit like if you you're not so sure so it really depends on your internet environment at home and how tech savvy you are um if you if you have the knowledge on your network to set up a dmz for these devices at the militarized zone we would recommend putting them in there especially if you don't trust the device we would also um recommend never to connect it to the internet as tempting as it might be um well let's let me put that a different way not to expose it to the internet so not let it accept outwards or incoming connections from the outside um that's already something that you can do that that really captures a lot of the

the threat and sometimes it's very very tempting to do that because for example the ip camera it's really convenient if you can consult it from outside of the house um but at the same time if you can consult it from outside of the house then somebody can probably find it on showdown and then log into it as well so that's really a trade-off and functionality versus security there that you could have to make of course there are cameras as well that connect via a cloud interface and and communicate with a very secure channel so it's not impossible to consult from outside of the house but be careful how you do it okay thanks a lot uh

it was really interesting presentation i'm gonna find out final question the were you when you were selecting the uh the devices for your test were you looking for specific vendors right because you were saying right you know the uh we're talking about the gdpr that depending on the value that the european vendor versus you know a vendor outside of the european union maybe you know those the um specific data requirements you know might be taking you know in in a different way from one to another so i wonder you know how did you select you know your pool of vendors you know for basis um most of the time we wanted to know uh to have a

device of a very recognized brand uh so one of the major vendors that you can imagine when i say smart home to you and then we also took one from a lesser known vendor maybe sometimes even from a white brand that just didn't put a brand name on the device to see if there was a notable difference between the two and that's also where our recommendation came from to go for the more known brands not to say that any device without a brand on it is insecure that's not true there might be secure ones out there as well but the vast majority of the ones that we tested didn't really pay a lot of attention to security

of the device and if you have a vendor that really cares about their reputation that is a lot different that's interesting you know yeah [Music] cool so thank you so much you know for your presentation that was great