 All right everybody who wants to break and enter this is definitely the good place to do it Well, I mean try not to break too much We need it to run that would be great Our next speaker is all ready to go. This is Nick Deluskey he is the managing consultant and penetration tester with spirant and More importantly he got approved because this talk just sounded way too much fun Who here knew about the simply safe? SDR hacks last year ish Yeah, well, he's apparently got the whole thing just worked out in the funniest possible way So fail safe yet another simply safe attack vector because apparently it wasn't bad enough. So please welcome Nick. Thank you How's going everyone? Like to just start off with a thank you to the wireless village for giving me the opportunity to speak today. I have to say I'm a bit humbled to Be right in between two individuals who design software defined radios for a living so this Talk sort of takes a different tack toward the simply safe Vulnerabilities that were discovered before We'll get to a little bit of the history in a little bit a little bit about me My name is Nick Deluskey, you know for the last name. There's only one letter that you don't pronounce which is not bad for Polish name As I said, I'm managing consultant for sparring security labs my specialization is actually in network pentesting and I wanted to sort of do this talk to document a little bit about How I went about you know trying to broaden Horizons a little bit and go beyond just the network pen test But also taking a look at the general methodology I used and then sort of how I applied that same methodology to learning some new skills I have five plus years of pen testing experience prior to that. I have a little over six years of security analysis and Systems admin experience. So with that being said There's you know, obviously the obligatory meme slide here You know everybody at home who asks what I do, you know, my friends think that I'm You know from from hackers my family are convinced that I work for three letter agencies TV producers have a laughable Concept of what network penetration testers do just random people on the street think that You know absolutely everything that you see on mr. Robot is real Some days I think that you know all I'm doing is collecting shells But what I actually do is just drink way too much coffee and do my job So a little bit of fair warning in my experience as you could see I come from a systems administration background I was never a developer. I learned Python Through my experience with other scripting languages, I'm not going to be releasing full or or finalized code today for a couple of reasons I Will however be hitting the highlights of you know, some of the milestones that I had reached along the way talking about some of the libraries I used to create the scripts that I used and Talking about the process Finally, I'm a sys admin. It's ugly code anyway I'm sure that if there are developers in the room you could do it yourself and do it in a way cleaner way than I did So when we're talking about anything You know that has multiple components that interact with one another You know, you're still dealing with some form of a network system So the user still has to interact with the system the system components all still have to interact with one with one another Now the way the mechanisms for this not necessarily They don't look anything like what we're necessarily used to in the traditional client server model with You know laptops and enterprise applications However, we can still look at them mostly in the same way Now when I am trying to reverse engineer a system, I generally Start with the techniques that I'm most familiar with And that familiarity means that I know You know what those techniques are good at and also where the blind spots are and I kind of Start with the most familiar So that I know that I can get those out of the way early and then I can you know use my time wisely and learn More skills along the way and that's honestly my goal with every project or every you know research project that I do So when we are doing reverse engineering essentially we're performing You know experimentation over and over again We're taking stock of what we can infer based on what we know and we're also taking a look at what can we How can we apply that knowledge to? control the system and once we have a little bit of control we're gonna go in a constant loop to You know see what else we can learn with that control and You know reassess and reevaluate So There are a lot of different Organizations out there that I penetration testing frameworks. This is one that I kind of go by When I'm dealing with a specific system as I'm trying to develop an attack or an exploit I use some different ones when I'm actually You know dealing with full networks and things like that, but in general you've got four main Phases of it open-source intelligence passive recon active testing and then weaponizing So for open-source Intel, we do have a lot of previous research That's already been done on the simply safe system and I'm gonna talk a little bit about that in a few minutes I've also got obviously at the FCC filings on the device. We've got setup guides. We've got help forums With the passive recon Just in general terms. I like to think a passive recon is something that I can do that Doesn't directly interface or or interact or change the environment or at least not meant to So You set up the monitor and then you perform regular Non-malicious tasks just looking at seeing the activity and trying to tease out what you can For later analysis now when you're ready for active testing you're making controlled changes and looking for differences You're observing and comparing responses and then you're sort of building up Some automations to further that process Finally we're coming to weaponizing where we're going to collect and synthesize everything that we have done over the past three phases Then we're going to perform our tests where we're actually Testing out our hypotheses about how the system works We're extending those tests based on new information that comes in and then we are refining our knowledge and filling in the gaps that we have finally we're going to take the Tests and and the the exploits that we've already mostly Written we're going to automate it to save time and we're going to optimize it for whatever our attack scenario is the final bullet point there Deploy and exploit, you know, we would do that on a real-world penetration test Because this is more of a lab exercise Not so much of a big deal not so applicable. So I just like to mention it Sort of as a reference So take a look at the system components of a simply safe system. There are Three components that I classify as user interface components. That is the base station so this Road cone looking thing up here Is a key chain remote? Well the remnants of it are up here if anybody wants to see this after the talk Feel free to come up And then you have the sensors that will Hopefully send an alarm to the base station for processing so The previous research on this first Research that I found on it was done by Andrew Zannenberg. I believe it was with IO active sent in February 2016 using a Replay attack by interfacing the simply safe keypad with a microcontroller So sort of taking the the simply safe hardware just for the the radio circuits So that there didn't need to be any reverse engineering on that side of things and the way I understand it He was using the packets that were coming in from that radio hardware decoding them and then Replaying and manipulating as necessary a couple of days later Michael Osman who I believe is actually speaking after me and Love to get his take on on what was found here So he exploited the vulnerability by capturing decoding packets with SDR and yardstick one That way you didn't even have to use any simply safe hardware at all to perform the attacks so While that that that vulnerability and that information was as far as I have done my research Well received in the information security community You know if you take a look at some of the the user forums and some of the other feedback You know one of the criticisms Was that well these are these are people who are clearly experts in the field. They're on the cutting edge, you know would Would an attacker be able to exploit, you know these without advanced degrees in electrical engineering and You know just philosophically speaking. I think that We as security researchers kind of need to be on the cutting edge and letting manufacturers know, you know Hey, this is a problem so that way they can design their systems to withstand Conditions that you know will occur into the future so these days Kids are being taught in grade school basic programming skills and then those programming skills are being applied to things like microcontrollers SDR I'm seeing pop up in things like youth library programs people are learning about radio and You know, it's a great thing Technology is surrounding us and it's not going back the other way But the fact remains is that the threat landscape Has certainly changed a lot over the last ten years and will continue to change in the future So I don't agree with the assessment that hey just because it requires Advanced knowledge in the field to be able to turn off to exploit these attacks. It's not really a flaw I believe it absolutely is a flaw It needs to be fixed But what I'm going to do in today's talk is demonstrate the vulnerability which is Inherent to the security architecture without requiring either SDR or hardware modification I am going to take simply safe hardware and basically use it against them so One of the components of the system that wasn't Directly analyzed in the research that I found was the key chain remote now the key chain remote goes beyond what you would see for your car or Even, you know, some other home security systems. It actually has USB functionality built into it and What that USB functionality does is it basically presents a Virtual CD-ROM drive to the operating system and then there's an application and user interface on there that allows the user to Make changes to the system and then it synchronized back to the base station by this USB port up here at the top so That interface is programmed in shockwave flat Yeah Adobe shockwave and so I realized that it might have been a little bit faster to say use a Flash D compiler Go that route, but again Not really developer sis admin Going from things that are quick and easy Working my way down to things that I need to maybe do a little bit more work on so Like you would expect with the key chain remote it does have the the arm and disarm functionality so There there are a couple of risks when taking a look at this this little piece of hardware right here First thing that came to my mind is loss or theft. So what happens if somebody gets a hold of this? You know, it's got a full copy of the systems configuration on it so When I Went through and this is just a little quick screenshot of the the interface here When I went through some of my open-source recon I saw some Guidance originally that said oh well, you know, I lost my key chain remote and so What do I need to do to make sure I'm still secure? So originally the guidance was all you have to do is Just remove the remote from your system nobody will be able to arm or disarm your system It'll be okay. Just we'll send your replacement. It's all good, but you know that configuration being on the remote Really really didn't sit well with me. So I continued to extend and Take a look at that component specifically so I Went out and I bought a simply safe system I bought one of the basic packages it comes with base station key chain remote keypad For entry sensors and a motion sensor. So it's a good cross-section of Sensors, it's a reasonable system that you would expect people to be able to deploy in a small office home office environment or in a You know normal residential environment Doing my open-source recon. I did note some interesting things about the FCC filings themselves Namely that many of the FCC filings go all the way back to November of 2008. So as I said the threat landscape has changed significantly in the past 10 years as you would expect it to in In the defense of simply safe, you know, this this hardware is Quite quite a few years old You know, I think that the industry as a whole has done a lot of learning since then so Kind of following on From that a little bit, you know, I didn't really get too far into in-depth with the internal photos and looking at the hardware chips and You know looking up individual chips on the devices because again, not really my goal I wanted to see what we could do with the hardware this system as it was on modified So taking a look at tools that I would use to analyze any USB device. I kind of did a little bit of brainstorming here We've got Procmon, which is a former sysinternals tool before Microsoft bought sysinternals used useful for All kinds of operating system level Monitoring of inputs and outputs on the system wire shark has functionality through USB mon So that would let me see the traffic going from the web application interface back down to the physical device itself Python also always a pen testers friend Has a library Pi USB, which appears to be a C types wrapper for Lib USB also, you can't forget and I do have to credit Google and stack exchange for you know all of the Researches I did on there as I was trying to learn a little bit more about USB at a low level and how to interact with it with Pi USB I'd like to say that you can use your OS of choice here Just because I chose to do this research and development on a Linux box doesn't mean you couldn't use a Windows box doesn't mean you couldn't use a Mac OS device the USB keychain remote itself doesn't actually support Mac OS So I think that Windows was the the most convenient for that part of it. And so I kind of Went a hybrid route between Windows and Linux for it eBay again will become Useful for reasons apparent later on in the talk and of course a little bit of caffeine on a cold snowy afternoon So take a look with Procmon, which I would figure would be the best place to look for a file activity related to configuration changes You know actually Showed lots of activity, but it didn't show any rights at all It's not that surprising since there was a CD drive that was being presented by the USB remote as you Plug it into the system so in that regard that was a good way to confirm kind of what we're looking for but You know not really Useful to us for furthering our access After that what I decided to do is I decided to take a quick image of the drive as it was presented to the operating system using DCFL DD DCFL DD is basically a Forensic version of the basic DD imaging utility So I took it before Image and then I made a couple of changes in the configuration I took an after-image and then I diff those images Did not find any changes at all on them. So okay pretty confident nothing is happening with that presented CD drive So after that I go on to wire shark and USB mon So this is what a typical read access would look like and again, I apologize if the Text is a little bit small What it shows is a scuzzy read with an opcode in the parentheses there of 10 So again, it's well understood understood by wire shark. It's easily parsed Not likely to be anything too far out of the ordinary What I also found though as I was taking a look at the traffic was that there were some other op codes that wire shark couldn't decode and The one interesting one That I really keyed in on was the opcode f6 So as I was taking a look at these f6 op codes. I did see that the Packet lengths were changing a little bit. So going through and doing a little bit more Analysis here's another f6 opcode where a couple of packets down you see the urb bulk in The length was 576 on that as opposed to the previous one where the length stayed within the double digits Taking a look at that bigger packet. I start to see some interesting information Namely what I see is I see the ASCII serial numbers of some of the devices that are in my system so What I have is I have the whole configuration in that little five hundred and seventy seventy six byte packet Retrieved and saved in plain text As I was taking a look at the packet You could see that no authentication methods were used between the host computer in the key chain and the Authentication that occurs between the user in the key chain Where you would ordinarily have to put in your your master pin that you would previously defined Is easily bypassable because in order to check to see if the passcode if the pin you put in is correct The application which is running on the laptop needs a copy of the full configuration so The authentication there certainly set has some problems So Interestingly, I noted that all of the disarm codes for the system were in plain text and even better than in plain text They treated the hex The hexadecimal Nibbles as though they were a full character. So if you took a look at the hex of the packet You know a disarm code of 9 9 9 9 would actually show up as 9 9 9 9 It wasn't even encoded as an integer where you had to do some decoding or or it wasn't You know base 64 or anything like that. So it couldn't get any easier to see the codes I obtained the serial numbers of all devices on the system except for the base station and That's significant a significant for a couple of reasons that I'll get into a little bit later So the Next step is gonna is gonna be to break down the unknown parts of the configuration my goal here is to identify as much as I can about the device types the different modes and Options for those devices and also the global settings Another key observation is that the configuration is always a constant size no matter how long the Strings are for that that you put into the UI for the Serial numbers as you're adding new sensors the configuration is always constant 512 bytes and That makes diffing a lot easier for us We know that we're going one-to-one. We don't have to account for Changes in address space if I make a change It's gonna change a finite number of bytes in the configuration And so I can tell exactly which bytes were affected immediately It also brings up the prospect of possible buffer overflow in other parts of the system Although that wasn't really what I wanted to go for today. So I didn't test for it. Maybe another day So this is where we start our analysis and are making our control changes go through and we make our control changes in the UI We compare our data to what we previously saw and then we just wash rinse repeat as much as as much as we can as fast as we can so in order to automate that process a little bit because you know even in a small system like this there are quite a bit of Quite a few variables in terms of the sensors and the actual global settings themselves You know, I turned to pie USB Python again being a fairly robust language. There's usually libraries out there to do The bulk of what you want to do So I wrote a little script to go through and Get all the information that pie USB can off of a device so The device itself is fairly basic and In order to start off you need to know which device you're actually going to query Simplest way to do that on a Unix command line You know, you're going to do an LS the USB I just happened to redirect that into a file called USB one you plug in the physical key chain remote Pipe that output to USB to and then a simple diff USB one USB two leaves me with the string right there So this is just a quick pie USB script that'll go through it will Detect if there is a simply safe key chain remote that is Attached to the system and it's going to print everything that it knows about that device if it doesn't find the device It'll print a little sad face so All right, we know that we can interface with the device as it is on on You know the typical Unix Linux machine As noted before one of the previous slides, it's a simple device and only has one configuration and when you're talking USB you kind of have a Hierarchy where at the top level you have the device down below that you have the device configuration Below that you have interfaces and on an interface. You could have a couple of different endpoints. So There is only one configuration There's one interface and I believe two different endpoints Couldn't get much simpler than that Interestingly enough if you just start querying some of the other devices that are on your That are on your system or any other random USB gadget you have It's you can find some pretty interesting stuff out about you know your your hardware you just have sitting around with very little effort So here's how we start out. We actually use Pi USB to Connect to the endpoints on the USB drive So EPO is the output endpoint So that lambda function there will basically just Help Pi USB go through and query for the first one available I believe that you can actually hard code those endpoint Numbers as well. I just happen to use this and again, this is Code that was borrowed from Stack Exchange. So You know it is what it is So this one here contains really what's important for the analysis that we're going to be doing for The sake of speed and for the sake of being easy. I decided to go the replay attack route instead of trying to go through and Decode those those custom op codes. I didn't want to risk bricking the device Because that would get expensive eventually And also, you know, if you know something works when you're early in the analysis period Get what you need to out of it first and then maybe you can afford to be a little bit more exotic with your attacks So I did take the bites from the Commands to get the configuration from the USB remote. I also took the Bites from the request to set the data right it back to the remote And also there appears to be a reset packet that gets sent in order to make sure that You know multiple rights and multiple reads are handled by that interface application So I also captured those bites as well Never did get the reset packet to work, which is part of the reason why I'm not releasing any code So one of those things that I can work on another day. So you put the blob into the replay and You set with the EPO dot write routine there Send the request to get the data then you have to read the data in from the buffer What I found is that the timings were sometimes a little bit inconsistent when I was trying to Access it through Pi USB. So I did write a little Try block there, which will somewhat handle the the timeout operations and What you get back is you get that back to raw config data as a Python list So Now we're just going through and we're mapping GUI elements to configuration addresses For the globals what I found is that they put the global configs in the first part of The packet and then you've got the pins Which by the way against all the pins plus the the duress pin as well If somebody were looking to play a really cruel joke You know they could switch the duress pin with the Master pin and bad things would happen again, that's something that that Really emphasizes the need to lock down all these just different interfaces You know, it's not just a trivial trivial thing and actually sort of you kind of wonder why the Functionality was built into the remote in the first place Given that somebody's going to carry this around everywhere could you could easily lose it? personally, I think that this information would have been better handled by providing an application that Generates the configuration puts it on a USB stick and that way, you know, you know that configuration is on that USB stick You can lock it away. You can keep it wherever you want You don't need to carry it around all the time in order to use why the device was Was built which is as a remote control So after going through all of the different configuration settings in the GUI which include things like Alarm volume whether or not there are any lights that are activated at any point the alarm Signal duration so that's the amount of time that you have to get to the keypad and put in the pin before the alarm goes off It also includes things like whether the voice chime is on whether the chime functionality is on which dings when You know now a sensor is activated. So all that stuff is now mapped out in addition The different sensors have an option block which do different things depending on the sensor as well So for an entry sensor, you could have a configuration where the sensor is only active when the Alarm is armed in a way mode which for those not familiar with home alarm systems Generally, they can be armed in home away or home at home that way you're not You're disabling certain sensors while you're still in your house So that way you're not tripping your your system every time you want to go down to the basement or every time You know your dog runs by the the motion sensor so a Little while later after I go through with you know some automation some scripting to identify the addresses what goes where We have a little bit of a better idea of What serial numbers are matched to which device I spat out the data as a some ASCII config just kind of for reference and and to You know give a little bit of Scale on how big that that configuration actually is as you can see I was able to easily parse out the volume whether the door chime was active and You know all the different pins broken out by number and function So now that we have a significant amount of information about how the system actually works We're gonna ask ourselves. What in total do we know about the system at this point? So we know that adding sensors to the system only requires a serial number based on what we've seen from the GUI In addition, we know that communications are susceptible to replay attacks from the previous work that was done by Andrew Zonenberg and Michael Ostman. So what's our hypothesis here? It's a sensor doesn't likely authenticate the base station because it's just broadcasting Simple packets out to anybody who will listen so the sensor types and numbers are contained in the configuration data and a sensor is configurable in a in a separate base station Hypothesis here rather is that the sensor can be configured in a separate base station based on a config that's stolen from a USB stick Also, it's noted in the documentation that the sensor range is about a hundred feet from the base station and Given that sensors are often placed on the perimeter of a protected area on the windows the doors It's pretty likely that there's going to be over penetration out to Public areas or areas that you're not really able to physically control so much so taking our Three sub-hypothesis The hypothetical attack that we're going to work on is that a stock base station can be configured with sensor values from a stolen configuration And then an arbitrary malicious base station can receive and interpret those sensor signals What's the next step? It's going to be a source another base station and test out our hypothesis So for that I turned to eBay. I didn't feel like dropping another Couple hundred dollars on another full system from retail I found that you were actually I was actually able to obtain a separate base station with keychain remote From eBay for about 70 bucks. I think So forgive the electrical tape here. This is so I don't actually confuse which one was the victim and which one was the malicious base station so Once I obtained that second system I was able to configure both systems so that Alternately so that they would chime when one of the entry sensors was trapped. I started off with The sensor configured just in one not the other Set the chime confirmed. Yeah, I heard the tone then I configured it in both And I set off the sensor and Confirmed that I heard the chime out of both base stations So yes that confirms our hypothesis the sensors are just doing a very basic broadcast out and any base station In the area can listen to that sensor and interpret it Integrate it into its own operations So now we're going to take that hypothesis we're going to extend it and we're going to refine it even more So what else do we know about the system? We know that the base station Can be configured to read Data from arbitrary sensors now that we've done that test We also know from the documentation that online monitoring is an optional add-on so What we're going to do now is We're going to test to see if a physically planted device has usable remote connectivity To pretty much anywhere in the world via the base stations built-in 2g connection We also know that the system will send monitoring alerts and so We should be able to build up a pretty robust picture of how that system is used over time so Being a pen tester. This is something that we do when there when there is a Physical aspect to our engagements. I'm not going to go through the details of how I would go through and You know what I'd be looking for trends in terms of building usage and things of those nature and things of that nature But you know if someone were so inclined or if this were a penetration test engagement, you know We absolutely could do a lot of analysis and trending and things like that To determine when for example The house or the protected area would be most likely unoccupied or or other attack scenarios So our next step is to provision online monitoring for the malicious base station to receive these alerts when the sensors are triggered so I Set up I had access to a friendly multi-tenant multi-tenant office I'm sorry an office in a multi-tenant office building So I was able to set up the original retail bought simply safe system as it would be deployed in a normal small office sort of environment as I did that I also put the malicious base station down in my vehicle in the parking lot and what I found was that I Was able to receive alerts that were delivered to me by email About the comings and goings in that office even though the base station itself was on a different physical level It was on the is on a parking lot that was Outside of the building. It wasn't even right next to the the actual office So it was a significant distance away. I didn't get all of the sensors which one would expect One would hope that you know the sensor wouldn't penetrate all the way out that way, but certainly enough to Give me an idea of when the office was occupied so Now that we know that we have a hypothetical attack that works What are we going to do to? Automate that that attack and really make it Usable in a real-world scenario So one thing you can do to automate the attack is to run The data capture script as a service in the background on your machine. So that way really the only Limiting factor in the time it takes to do the attack is the time to undo the cap on the remote and plug it into USB port mere seconds you can either save that configuration off to a file You can Bluetooth it off to another location you know any means of exfiltration at that point is is completely valid and What else can we do to optimize it for a particular attack scenario? So? When you are thinking about these these USB keys, there are a couple of different scenarios that pop to mind Lost and stolen is obviously one aspect of it, but It doesn't even necessarily have to be fully lost. I was Going for a run at the gym one day And I just happened to see one of these sitting on the little key hanger things that are outside the front of the building Why someone would would put their keys on one of those in the first place being a security professional Again is is is beyond me, but there are people that do it and so It got me thinking, you know well People do actually give their keys to people for short periods of time whether it's a valet or a Mechanic or again on one of those little boards a lot of times people leave their keys in the break room at work And they might not even necessarily know that somebody was able to pick up their keys I know a number of years ago. There was I guess an interesting talk about somebody who managed to replicate a physical key with a 3d printer Just by taking a picture of it. So this would kind of be the equivalent of that You know, you can actually run the script easily very very easily on Raspberry pi zero and again for those that might not be familiar with the pi zero It is a very very small board, which is actually about the same size as the key chain itself You can wire that up to you know a very inexpensive USB power supply You know, you can oftentimes get them as swag at You know conventions or you know, they're given out for free just for promotional materials So, you know for the cost of five bucks for a pi zero You know an extra flash card you have sitting around USB OTG cable You know, you can have an easily concealable method of actually collecting this data So I did actually reach out to simply safe When I found out found this vulnerability to do some coordinated disclosure. So they had actually Been in been in contact with me for a couple of months and they had released a security advisory today It's available as a blog post on the SimplySafe's website there Just provided for anybody who wants to check that out now Obviously, you know, I think that you know their recommendations You know and in my recommendations can disagree a little bit reasonable minds can disagree so I'm told there's actually going to be a utility that they came out with that's going to help mitigate this problem as well Where customers can actually wipe the configuration off of their key chain remote while they're not making changes So it would work like this basically you would make chain you would want to make changes to your system You take a key chain remote you'd plug it into the base station. It would write the configuration data To the key chain You'd plug it into the system to the laptop make your changes And then you'd re-sync it to the base station and then you'd run this utility on the laptop again That would reset the the data wiped off the key chain You know absolutely for having a hardware that was first envisioned and deployed almost 10 years ago I think that that's a novel way of mitigating the risk Personally, I think that a lot of users Might not want to go through that trouble. I think that a lot of users might forget to do that I Think that having something out there and acknowledging that hey, yeah, there is a configuration on here and you do need to Take into consideration more than just your your base station is a good step Simply safe also did modify some of their their guidance to say hey if you lose a remote, you know You should reset your pins just in case I recommend not using the us being able to remote just in case you forget to wipe it Also, I would recommend If the US being able to remote is lost, you know, obviously you can change the pins immediately But really there's no known remedy to reinitialize the compromise sensor serial numbers. So that kind of makes you Think about whether or not You know the that you have to think about your own risk profile Basically a small business is going to be a different risk profile to somebody who's using this to protect their home So it might be a good idea to supplement additional security measures things like Web cameras that you utilize different technologies say Wi-Fi or wired connections Or additional locks that might also have notification Capabilities as well. So again, you know, yeah, we're pointing out a vulnerability It's going to be up to the individual to determine whether or not This vulnerability really affects their use case Finally, I'd just like to mention it's a good idea always to restrict physical access to the base station It's one of the things where You know, if you do a little bit of googling about simply safe There are some other YouTube attacks out attacks out there that you can find on YouTube I haven't tested them myself. I'm not going to vouch for whether or not they actually are real But just to be on the safe side It is a good idea to just sort of keep this In a physically safe spot if you can if you're going to continue to use the system so what I've found about the system is that the vulnerabilities that Are inherent to the architecture of the system are exploitable in three different ways You can use hardware hacking you can use SDR and signals analysis or you can use the native device and Abuse of the features that are already built into the system when you have a secure product and when You are going through and you're inspecting your designs. You're doing risk analysis It doesn't really matter What the tools are used to attack it? It's a strong architecture Saying that you know, well, it's not really a valid attack because they they used one skill or they used one Particular tool becomes an irrelevant point because you're actually getting to me to the problem. You're fixing the root cause so Is the system still useful and effective and as I said before that really depends on the individual So an individual who? You know is looking at high risk human threat actors so somebody that Has a reason to have home security system And it's an unfortunate reality that that people out there You know have stalkers they have PFA's against people They know that there are threats that have been made things of that nature I'm not sure that I would recommend this system to somebody who knows that there is a High risk of something happening Needing to alert the police quickly Low and medium risk human threat actors. I'd say that depends on You know more the use case of you know, are you looking to protect property? Are you looking to supplement additional controls? It might still be effective on defending against a normal smash-and-grab type burglaries it might be still useful in deterring There being an incident in the first place However, it's kind of hard to measure a negative. How do you how do you measure something that doesn't happen? And then there also is the environmental monitoring piece the environmental threat actors. There's no intelligence There's no active circumvention of carbon monoxide detector You know smoke detectors And water detectors That's not really my area of expertise. I would leave it to somebody like under writer's labs to test those components You know, they know really What's what what the key variables are and making sure that those those systems are effective So on a high level what I would say the the Most apparent vulnerability in the architecture itself is a lack of Two-way authentication So when you have a sensor that is broadcasting out to anybody who will listen And you have a system that will accept that data Without Proving integrity or or identity You know, that's really a system that that's not able to do Some very key things many information security perspective. You don't have confidentiality. You don't have a data integrity And you don't have data authenticity When you're building a system like this, you would expect it to have some confidentiality You'd expect it to have integrity checks. You'd expect it to have authentication checks So two-way authentication I think would be The goal for for manufacturers of alarm systems making sure that you can't just do simple replay replays simple spoofs Things of that nature to to get around and cause problems whether it be false positives or false negatives Does anybody have any questions? All right. Well, thank you very much for coming to the talk today If you're interested in reaching out there's a couple of different ways you can get a hold of me I am on LinkedIn. I'm not on Twitter. Although my company is So you can go to Twitter handle at spiron security You can reach out to me directly We're at Nick Nick doc to leskey at spiron comm you can reach out to the whole group at security labs at spiron comm and for anything that's more, you know of a Enthusiast enthusiast or or other sort of email you can reach out to me Believe it or not. This actually is a valid email address down there So did I see a hand over here and by the way, we do have a couple of shirts So if you have some questions, feel free to come up and grab a shirt, too Can you speak into the microphone? Yeah, did you find any attributes in your configuration that were specific to that particular setup So so a lot of the attributes that I found were pretty common among the other Home security systems. I've looked at You know, it was a pretty bare bones configuration But it is a fairly straightforward Embedded system. It's not no no, I mean were they most the parameters very generic or were they Particularly to that particular set up to recognize each other the sensor vice. Oh, they're there. They were fairly generic everything was was Easily set up with just entering the serial number in the config. So you didn't really have to have a whole lot of Customization Were you were you referring to the testing setup or the actual alarm setup the actual alarm setup the actual alarm setup now? Everything is fairly generic. Oh, yeah You know, what I would say is that it wouldn't be interoperable with other systems, but it's not really a complex system. Okay other questions So I gave a torque on talk in 2015 where I used an MC catcher to basically analyze the communication between the base station and the actual like remote monitoring side, okay, and it just sends unencrypted UDP packets and then on their back end it's using the base station serial number and the Keypad or sensor serial number to actually trigger those alerts. So did you find anything that would let you Get the base station serial number from the USB keypad or anything else. No, I did not and I think that that would be a key differentiator I and Again, the base station serial number would have been a Completely different story if you could find that on the on the device No, it is not on the device configuration Other questions. All right. Thank you very much everybody. I appreciate your time You