 hey everyone I'm audible right just a check raise your hand if I'm audible great so welcome to the smart lock talk where we're gonna talk about how we pwned or hacked a smart lock using python so before we dive into the lock and all the technical stuff let's get the boring stuff out of the way so hello can everyone hear me yeah so I'm Raghav I'm a computer science undergrad from SRM I'm basically interested in security and specialized in hardware security I also dabbled in reverse engineering and coding a little I'm Anirudh I'm a computer science undergrad at SRM 2 I'm in my third year right now so I generally do security stuff I'm interested in the embedded side of security so like you know routers and small devices and I also like dealing with the large-scale security like operational applied intelligence analysis and tradecraft techniques so before we you know get into the lock itself let's take a quick look at the IoT security scene in general today we we as humans have basically surrounded ourselves with a tons of IT devices ranging from routers set up boxes smart fridges smart TVs and whatnot but when it comes to security it's pretty bad right so the security measures that you see that are implemented in these devices are over 20 years old so you see stuff like you know executable stack segments which means binary exploitation is trivial you can just smash through the stack there's no canary there's no ASLR so binary exploitation becomes super trivial so you can you know there's no need for convoluted techniques like return oriented programming or return to libc attacks and you see unencrypted communications amongst these devices so you see you know locks and whatnot and you know communicating in plain text and then you find hard-coded credentials in firmware you see hard-coded tokens hard-coded passwords and the binaries that are used in these firmware images are generally you know it's a developer centric conference right so everyone knows how developers generally work you basically pull source code for existing you know stuff so people so in in firmware that you see today you see gnu core utils samples but most of it is stripped down by developers to you know make it smaller and you know compact for IoT specific applications so this tripping down process eventually leads to a ton of nasty bugs so before we dive into our specific lock we would like to establish a few points of what we expect from a smart lock in general so we expect a smart lock to have a capacity to lock in unlock web using fingerprint can be again use lock in unlock via bluetooth and also come with a companion app as a package so this companion app right so generally has a bunch of you know actions that you know the user can perform which is to configure configure users you know add and remove users add fingerprints to unlock the lock and it almost always requires you to sign up for an account with your service right so they all have like this big you know company that they build around this and you have to sign up for an account with their online platform or not so our specific log is called the fb50 we bought it off Amazon and we bought it for around 3000 bucks similar locks were sold by multiple vendors it was basically the same log but what told with different aims and the mobile companion app that came with the lock was called ok lock and this is how it looked this is what it looks like the front of the lock is the fingerprint sensor and the back it comes with the QR code that you can use to pair with the QR code was stuck by Raghav so if you're wondering why it's so terribly stuck it's him so so let's talk about our initial approach so when we are present at the lock it's a black box right so we don't really know what to do with it so we're gonna give you an idea of how we approach the lock from a hardware security research perspective so the first surface that we explored was the Bluetooth because as hardware researchers we tend to go to the easiest surface and initially we tried to get a dump of our Bluetooth communication between our mobile phones and the lock and replay the packets yeah so how we did this was using two primary methods so Android if you're aware has a HCI dump log which which you can grab by enabling it in developer options so that's what we did we turned on the dump and we grabbed these packets as the app and the lock communicated so we identified what packets caused an unlock or you know a cause and unlock from the phone to the lock and we attempted to replay those packets and that didn't really work so the next approach we tried was performing a man in the middle attack using a tool called Gattacker so Gattacker is essentially it's a tool that you can install on a say a Raspberry Pi and so the Gattacker basically makes the Raspberry Pi behave as a third party in between your phone and your lock so so here our Raspberry Pi acts as the lock to the phone and acts as the phone to the lock so if that makes sense but you know our luck was terrible and it really didn't work it crashed every time we tried connecting the lock to the Raspberry Pi but yeah so we moved on to reverse engineering the app itself so we use the textbook textbook method for Android reverse engineering right so you Google Android APK reverse engineering is what you're gonna find so there are three main tools that we used APK tool Dexter jar and JDGY so APK tool basically converts your binary APK package into into something called as DEX files so DEX files are compiled bytecode that runs on the Android Dalvik virtual machine but that's not it's intermediate code it's bytecode you can't read it so we convert it into a JAR jar which is a Java archive file using a tool called Dexter jar and we visualized it into you know a lot more readable code using JDGY which is your Java disassembler so most of it was upfuscated because well that's that it was and but we did find a couple of hard-coded keys and tokens and a couple of API endpoints but it didn't really make much sense then so we ditched it and moved on to the you know the next obvious approach which was a lot more easier so the next surface that we approach was those communications between the server and the mobile application and this actually worked we used a tool called burpsuite and we basically rerouted our mobile traffic through my laptop yeah so if anyone's done web security or bug bounty hunting everyone knows burpsuite it's like the go-to tool for intercepting HTTP traffic and messing around with input so when we were doing this we came across a lot of requests but we filtered down filtered all of it down to a couple of interesting ones but before we go into the request we also found some interesting data that was being sent in these requests one of them was one of them in particular is called it was a token that was being assigned by the server to a user when he logged in and this is this token essentially you know states that hey this user is authenticated and he can he's he can unlock this lock yeah he can bind or unbind the log basically unbind it with the log right so there are two basic you know pairing mechanisms the first one is obviously we have Bluetooth and while attempting to pair the mobile with the Bluetooth while the lock with the Bluetooth sorry yeah the app sent the mark address of the lock to the server and in response we got a huge jason file dump you yeah we got this we got this massive jason dump so not all of it is relevant but we've highlighted what is actually you know important so in what we you know use further on is the barcode which we got and then we got an ID which we figured out was the lock ID and then a lock key which we didn't know what it was then but it turns out it was the AES key and a lock password which was being used by the app internally while sending while pairing with the lock so if anyone's worked with Bluetooth before you know that you have to send a pairing code which was the you know six zeros and then the name of the lock itself which we set yeah we were very creative with the name and then by using the second method was pairing via barcode and again it sent the barcode in a post request and in response we got a similar jason dump only with a key key few differences one was the email ID and a user ID so just to be clear the user ID and the lock ID are two different IDs user ID is the accounts user ID and the lock ID is the locks ID so yeah that was the jason dump and so now there are two you know other features of the app that we're gonna put forth so we so every user can bind and unbind you know to the lock right so binding binding a lock was it basically says hey this user is tied to this lock and that user can add more you know other users to you know bind with the lock right so while sending the unbind request from the app we noticed that the lock ID and the user ID were being sent now both of these details we can we obtained from the previous you know two requests that we talked about and while binding we specify a name for the lock which is you know again new name creativity and the user ID and the MAC address now just to be clear we're talking from the attackers perspective here so the new name is being set by the attacker the user ID is the attackers user ID right so he wants to transfer ownership of the lock to his own account so the user ID which he specifies this is own user ID which you can obtain by you know logging in on the app and you know you can figure it out and the MAC address can be obtained from an attacker's perspective again by performing a simple Bluetooth scan and the vicinity of the lock okay so the bug that we finally exploited was tokens even though the tokens were being checked or verified the tokens were not being bound to a particular account that led us to like someone else's token use someone else's token to bind and unbind lock so basically allowing transfer transfer of ownership of the lock right so now the exploit it's simple so it's basically what the request that we talked about earlier I just gonna put it put it all in a couple of points so it was a simple four step process right so we initially get the barcode and the lock ID using the locks MAC address the first request and using the barcode we fetch the user ID of the legitimate user and using the lock ID and the user ID we unbind the current user you know the user who owns the lock from the lock and then we supply a new name name whatever you want a new user ID which is the attackers and the MAC address of the lock itself and we you know thereby bind our own user account to the lock so this effectively renders the lock completely inaccessible to the you know the legitimate owner and it completely disappears from their app as if it never existed so the core that we wrote was it's simple Python code using the requests library everyone knows I'm pretty sure everyone knows written by Kenneth reads so we just made those requests we chained them into an exploit made it all pretty using command line arguments and stuff and that's it we just made those requests using our own token because they never verified if the token and the user account actually match and that's it we own the lock was that simple now we're going to show you a proof of concept that we you know very expertly filmed so you can see two phones here one is the victim and one is the attacker the attacker doesn't have the lock on his app yet so we run the code we specify the ID and the MAC address and that's it it was that fast so now once you restart the apps you should see that the app the lock will disappear from the current owner's app and you should see it up here on the attacker see it says no locks it takes a while there we go the lock has been transferred so now you hit unlock just just for the sake of completion and the lock was unlocked it was it was pretty simple really yeah so so just to highlight a couple of other issues that we saw in the app during our you know entire research we found that there was an idar bug indirect object reference which allowed us to exfiltrate tons and tons of user data so that we actually found this one endpoint which served profile photos of a lot of users which is pretty scary to think of right so that there's an endpoint which just you know serves a lot of users personal photos and yeah so when we started brute forcing the user IDs right so we increase the user IDs one by one you were able to access the user data of every other user on the platform and we scripted this and we found there are about around 15,000 odd active locks in use we found locks called garage main door work and a bunch of others which is a pretty scary thought to think of you know people are there actually using this product without any you know knowledge of how insecure critical bugs that are you know the products are written with so we follow the textbook procedure for disclosure we follow the responsible disclosure so we sent a multiple emails to the manufacturer regarding the vulnerability that we found and waited for 30 days to response and they responded with marketing emails and asked if we wanted to buy more of these locks go figure well so the issue we issue was found on 26 June while we me and under oath were interning at secure layer 7 and on 27th we notify the vendor and on second we deserved our CVE ID and it is the first ever CV we both got so it's pretty special yeah the CV ID was 2019 1 13 143 this CV is basically registered registered under three names me on a road and Shubham Shubham was the third guy who worked with us at secure layer 7 on this research so shout out to him he wasn't able to make it here so yeah and on finally on 2nd August we made a public disclosure of this vulnerability so the everything is open so yeah so just if it's just a point I'd like to make so we're not going to publicize the URL of the source code of this exploit it can be trivially googled but we don't want to publicize it mainly because we feel it's you know unethical yeah unethical that you know people the exploit is still active right you can you know break others personal locks yeah and get others personal details yeah personal account details everything is still publicly out there but it's our job to publicize it so we did but you can look it up if you want to you know poke through the code but we're not going to show the URL here so yeah that's it I'd like to conclude by saying that you know smart devices you can't just trust them right so IoT vendors are going to sell their product they're not they're going to claim it's all secure and stuff but someone has to scrutinize it and you know point out these glaring holes that are there no one's doing it yet it's still IoT security research is really small so don't implicitly trust the smart devices right and they bring about a huge attack surface into existing threat models which and nobody even actually models in IoT as a part of their threat vector right so in enterprise security nobody thinks IoT is a part of the threat vector so people should update and factor in IoT and hardware as a potential attack surface as well and in another issue is privacy concerns so everyone voluntarily buys and installs wiretaps known as Google home and Alexa so Amazon is basically using this as you know a way to steal your data there's no better way to put it and in totalitarian governments like in China you see it being used for surveillance campaigns or it can be potentially used for survey surveillance campaigns I don't know eyes are everywhere and yeah I'd like to take this moment to you know call upon for more researchers in this space here because you know it's going unchecked right so the entire IoT space is growing rapidly and no one's really taking a quick you know closer look at the actual code or the actual security state that it is in so we need more researchers here and yeah that's it the slide everyone was waiting for I'm sure this is our online presence make sure to follow us yeah you know what to do smash like hit subscribe that's it so I think we have a lot of time for questions so if any please pass the mind everybody has questions