 Okey, jadi... Selamat pagi, Defcon Terima kasih banyak untuk mengambil masa untuk berada di sini dan saya harap anda akan berjalan dari bintang ini telah belajar sesuatu yang menarik dan baru dan jika anda ada, tolong beritahu saya tentangnya Jadi, apa yang bintang ini tentang? Dengan pembinaan berkumpul dan berjalan di populariti di seluruh dunia Saya telah melihat pembina-pembina sepanjang tempat yang selalu digunakan oleh orang-orang yang mempunyai sesuatu untuk menggunakan mereka Ini membuat saya memandangkan bagaimana sistem lock berkumpul dan bagaimana kebebasan saya Apakah ia mungkin untuk menggantikan lock dan mempunyai tawaran? Ia tidak terlalu banyak untuk menggantikan pembinaan berkumpul tetapi apakah ia tidak menarik untuk menggantikan lock? Saya Vincent Saya dari Sani Singapore currently a security consultant at MWR dan mempunyai mobile dan wireless In this talk, I'll first give a quick overview of the bike sharing economy and the locks used on shared bicycles I'll do a quick recap of BLE for those of you who are unfamiliar Then I'll move on to walking you through how I analyze communications between my iOS device and the BLE lock what worked, what didn't and how a key can be built from what I've learned and a small demo of an app I've built to get rights for free So I'm sure by now we all know that smart locks are rubbish The state of security now is terrible because and I could be wrong companies only care about features and getting the market as soon as possible They don't care about designing a scale lock and they aren't performing any test to validate the security of their solution Take for example, tap lock the latest smart lock to be hacked It talks about having all these incredible security features such as encrypted fingerprint reader AES 128-bit encryption anti-taff alarm but ultimately it got hacked in 2 seconds So what is the situation with these guys? These are the 3 largest bike sharing companies in Singapore O4 and MoBike being companies from China and O-Bike a local Singapore startup which unfortunately has just failed for bankruptcy not too long ago These guys have operations all over the world and have pretty high valuations Across all companies the cost of renting a bike is $0.50 per half hour which roughly equates to $0.37 USD So before all the juicy bits a quick refresher on what Bluetooth Low Energy aka BLE is There are 2 key things to know to navigate your way around The first is GAP or Generic Access Profile This basically defines what the device is Devices are split into 2 categories A peripheral device and a central device A peripheral device is a low powered device It could be a bicycle lock or a pacemaker and the central device is your high powered device such as your mobile phone or your laptop Then comes the Generic Attribute Profile or GAP This defines the way that 2 Bluetooth Low Energy devices communicate with each other Each BLE device will have 1 or more services and within each service it will have 1 or more characteristics Services are groups of characteristics and characteristic is a data point both of which are identified by a 16-bit or 128-bit UUID In the case of a treadmill for example a data point can be the step-climber data speed, inclination, or heart rate and in the case of a Bluetooth lock the data could be the battery life or the unlock mechanism So let me give you an example an idea of what the bicycle lock is and how it looks like and how it operates How do you pick a lock when you don't actually own the lock? My first hurdle came when it was time to figure out properly how a bike lock would work Since I have pretty much zero experience in Bluetooth or lock mechanisms I decided I should go buy one instead Quick search on China's beloved shopping site Taobao quickly came upon this I could have my own smart bike lock appears to operate the same way and apparently the company also OEMs the entire solution to bike sharing companies maybe one of my targets would use it In essence, this is how the entire process of renting a bike works you download one of the apps O4, mobile bike, whatever you enable Bluetooth find your account scan the QR code on the bike and the bike will automatically unlock These bikes have a small solar panel to charge the battery in the lock and most of the locks do not come with built-in GPS GPS data is provided by your phone Wherever you cycle to and finally lock the bike the app will record it and send it off to the cloud via HTTPS There are of course more expensive locks which do have inbuilt GPS So the first thing I did like any good hacker does is to tear apart upon receiving it This is a tear down The lock with the QR code on the left and the 4 cell battery inside This lock charges via USB This is the logic controller with Bluetooth radio and the moto that releases the lock So it's a spring loaded lock and the lock is held in place with a pin in the notch When the unlock command is received the moto will then engage to release the lock So it's time to actually look at how the lock and app were communicating Again, I had no idea where to begin how Bluetooth worked Etc I turned to a great presentation by Slo Amir Jayzik Sorry if I mispronounce your name where it was effectively man in the milling the Bluetooth connection thus allowing demodification of packets Unfortunately, I wasn't able to get the setup working for that Then I found another fantastic presentation by Anthony Rose and Ben Ramsey from Defcon24 where they used an ubertoof 1 to sniff BLE packets and then used the wireshark to figure out what was going on but for the life of me I couldn't figure out what was happening So this is an example capture that I took This shows a capture from the ubertoof 1 and the BLE write request and response Again, didn't understand what was going on but after this packet was sent the lock opened So I basically replayed the bytes from this packet with no result Again, I have no idea what's going on So back to drawing board I figured I needed two things to be able to help me figure out what was going on First, I needed to figure out how the app communicated with the lock What were the endpoints that it communicated with What were the services and characteristics that the app communicated with And second, how I could intercept the BLE traffic to understand what was going on For the first problem I needed a way to figure out and understand how the app communicated with the lock in the ubertoof After doing a little more googling You may know Evil Socket BLEH You may know Evil Socket as the author of the more famous Better Cap Toolkit So what BLEH does is that it essentially enyumates the services and characteristics of any BLE device This allows one to see in a practical manner what services there are on a device and what characteristics can be written or read from You can see at the bottom the different characteristics that can be read from or written to For my second problem Since I have the app and I have the lock it all comes down to understanding the process of what BLE messages are sent to unlock the lock I turned the Frida and the Frida Trace Tool which would allow me to view in real time what the app was processing We can use Frida before It is a wonderful tool to allow instrumentation of applications across various platforms In particular, the Frida Tool used on the iOS platform allows users in essence to log in relatively real time on objective C classes and methods and C functions which are accessed and executed by the application Since we can use Frida to hook a way to We now need to find which one to hook In iOS the core Bluetooth framework is used to perform Bluetooth communications The CB peripheral and CB peripheral delegate classes are the most interesting and the read value write value and set notify value are methods of interest It is quite obvious what these methods do read value, read to value characteristic write value And another interesting property of BLE is that it is possible to get a peripheral in this case, a lock to push messages to the application This is done through the notify property of the characteristic and it can be enabled by the set notify value We can then capture the push by tracing the update methods of the CB peripheral delegate class So, after a lot of reversing of the app boxing of traffic and recording of BLE reads and writes I've come up with the following process to unlock the bicycle lock that I bought from China Obviously, scan the QR code The app will then get a lock key for the server that makes the server respond to the lock key The app makes a request to the lock for an encrypted token by sending the right request Lock responds with the encrypted token through the notify property The app decrypts the token with the key from the server sends a right request and it unlocks So, this is a challenge and a response process where the lock provide the token and if you have the corresponding key you'll be able to decrypt the token and send the result back to the lock By the way, if it isn't already clear the security of the lock is horrible I can retrieve any key for any lock by just incrementing the lock ID for this company and they make a whole bunch of locks So, let's try this against the real world Now, we've seen how such a lock could work to understand how it works what methods the hook, and what kind of operations the app and the lock may perform How does it compare to an actual lock used by O-Bike For the most part, the hardware looks pretty much the same Someone did a YouTube video tear down of the lock As you can see here, we have a single cell battery the lock hardware and a Texas Instruments CC2541 SoC chip Now, let's find the service and characteristics UUIDs that could be of interest Again, with Blair we know what could be of interest but we don't know how they are used To figure this out I trace the entire flow of the app to identify which characteristics was most used and as it turns out communications went to the FFF6 characteristic To guide you through the next couple of slides I've laid out the flow here to show you the process in unlocking the lock First, you scan the QR code The app checks the lock status with the server and also sends it your coordinates The server responds with the lock status and if okay the app will then proceed to request an unlock token from the lock Within the app and HDB request the server this is known as the key source so the app responds with the key source sorry, the lock responds with the key source the app then uses the key source to request an unlock key from the server so it replies with an unlock key for the lock and the app uses it to unlock the lock So, similar to the lock that I bought off Taobao it appears to use some sort of challenge and response mechanism or that in a little bit more detail Scanning the QR code provides the app with the ID number of the lock and as seen in point 1 the QR code is essentially the URL with the bike ID at the end Assuming you have used the old bike app to scan the QR code a request is made to the server with the lock ID and the current coordinates of where the lock was scanned The server responds to the status check with whether the lock is faulty or not based on reports from other users and if it's not, the app will proceed to the next step Here, the app request for a key source from the lock This can be a little bit confusing so let me explain As I mentioned earlier it is possible for a peripheral device to send push notifications also known as notify in BLE back to the app the app is setting the notify flag in the FFF6 characteristic Next, the app sends a request for the key source to the lock by performing a BLE write In this case, a dump of the BLE write at the memory location shows that the write command is in the form of the following bytes 67, 74, 0, 0, 81, 81 and that it is being sent to the same FFF6 So, the app now waits if the command send was correct and accepted by the lock the lock will respond with the token or the key source This is a response Here, we can see the response through the trace of the update value for characteristic method and within the response the app picks out the key source as shown What the data means I have no idea but I don't need to know because every time this transaction happens the key source is always located in the same location It is always taken from the 9th to the 12th bytes The key source is then sent to the server through the unlock pass API and assuming there are no errors the server responds with a pair of keys So now we've got the keys how are they used The unlock message is constructed and sent to the FFF6 characteristic in two parts As you can see, the two write value messages and below is the dump of how the actual message is or what the actual message is This looks roughly like the message that I tried replaying earlier from the wireshark capture which didn't work So, I dug a little deeper into how the unlock message was constructed and what the different values meant After looking at numerous unlock messages I found the following In the first message the first two bytes are static throughout all messages sent from the app to the lock whether it's an unlock message or any other form of message these two bytes are used The next byte is the length of the message which is static for the unlock algorithm Next byte could be a command byte to unlock the lock together with the key index then the subsequent six bytes are static and the final five bytes of the message are the date time stamp Message 2 contains the key from the server However, this has been truncated to 12 bytes and the last byte is a checksum This is done by performing an XOR of each byte across both messages Now, I had to jump through a couple of hoops along my journey The first was trying to understand what was sent from the app to the server and as you can see here the messages looked to be encrypted Why the programmers would encrypt the messages and just send to the server is beyond me and they're just wasting their time and my time We're freedah hooking the right messages couldn't be easier I found that the messages were encrypted using AES with a combination of a static string and a version number of the application provided in the HTTP header as seen here For those of you who have noticed there is a string text to the back of the message sent to the server What the heck is that? Again, the developers implemented some form of integrity check for some unknown reason to waste time with further assistance from freedah that string I found was a shawan sum of the following values the data to be processed by the server a static string and the application version now you must be wondering how users get charged after the bike is unlocked the app sends lock status to the server informing it, it has been unlocked and to start a timer once you're done riding the app will then send the lock status again to the server Lastly, you're built for the amount of time that has been used So, if I actually ride my own app to perform the unlock and halt all further communications with the server after unlocking the bike I get free rides after jumping through the hoops and understanding how how the BLE communication works and how the unlock command is built I built my own key sorry the video is a little bit dark but here I am entering the lock ID into my app waiting for the server that's the unlock sound so if you've no doubt noticed opening the lock depends on the connection to the server how can you then unlock it offline Since old bike has recently gone bankrupt someone dismantled the lock from the bike retrieve the chip and sent it over to me My solution was to try and get the dump of the firmware to figure out how the unlock algorithm works offline Unfortunately, the readout fuse was set on the TI chip and it was not possible for me to dump the firmware if anyone of you knows how to get around this ok It was relatively easy to unlock the lock from one bike sharing company should be relatively easy to do it for another no I tested this process against more bike same thing we start off by finding the services and characteristic UUIDs that could be of interest looks to be a lot simpler here only two characteristics and it is obvious which we need to write to to unlock the bike moving on for more bike the process in unlocking the lock is much simpler same as before you scan the QR code you get a bike ID send the lock status to the server also send your coordinates so we respond to the lock status however this time the lock is good the server will also send along the unlock key immediately the app then uses the key to unlock the lock so no challenge as a response mechanism it's just a direct unlock as before let's go through all of that in a little bit more detail similar to a bike after the bike is unlocked lock status send to the server timer starts when you're finished user account is charged again if we cut off the messages after the unlock similarly I encountered various crazy integrity checks implemented by the developers in this the HTTP messages for the obike app there's a sign parameter and there's an EP data how are these formed in this case it's just RSA encryption to encrypt a user ID string together with the current date time and the output of that is used in messages sent to the server the sign parameter is then an MD5 hash of the data that's sent to the server after going through all of that again the process starts out the same user scans the QR code QR code contains a URL with the bike ID at the end assuming you've used the mobike app it's made to the server with the lock ID and the current coordinates of where the lock is scanned however here's the difference the application server will respond with the faulty message if the lock has been reported faulty by a number of users or it will immediately respond with an unlock key if the lock is in good condition this differs from obike in that it doesn't require so what happens with the key from the server first according to the trace the app tells the lock to set it a notification by setting the set notify value to 1 seen here for the FE0 and FE1 UUIDs then the app breaks up the key into 3 9 byte pieces appends a 2 byte header to each and writes it to the lock via bluetooth and it unlocks to make it clearer the key response from the server is broken into 3 9 byte pieces and an incremental header is then added and return to the lock and it unlocks straight forward and simple in testing however i face one problem it seems that the lock was able to keep track of time because every key received so the server for the same lock is always different additionally if there was a delay in sending a key to the lock it would not work so after all that trouble i modified my app and this time around i only program this specific byte id so it would save me time in trouble let's play that again okay so there were 2 types of lock schemes across the 3 locks that i faced the first was a challenge response scheme where a challenge was requested from the lock this data was then sent to the server to process or data was processed on the client side output from this processing was then send to unlock the lock the other type was a direct unlock of the lock based on a key provided by the server so when i started this journey i had no idea how BLE worked and how one would begin looking at BLE devices there was no process or one that i was aware of when i started on how to look at BLE stuff i hope given the following repeatable process anyone who has wanted to start breaking BLE devices would have an easier time as we have any project our attack surface and i found this to be done easily with BLE as shown previously we can use BLE to innovate the services and characteristics of any BLE device and understand what we communicate with then we find out if the device does send notifications to the app and if so we enable notifications by setting the set notify value and we hook into the appropriate read and write methods to figure out what messages are being read from and written to the BLE device and we also hope the did update methods to find out what notifications if any the peripheral devices send to the central device so i didn't make use of any special hardware such as the uber tooth one or develop any special app to innovate a BLE device i use my iphone to help run the app and Frida to help with understanding the communications between the app and the lock that's all from me thank you for listening