 The digital distributed online chaos will now present you no POC, no fix, sad story about Bluetooth security. So POC here stands for proof of concept and not people of color. It's about technology. It's just a broken meme copy in the Bluetooth stack and do we really need to fix that? So that's probably what the Bluetooth developer thought and Jan Ruege is talking about what he found, what he thought about it. So Jan, please. Hello, my name is Jan and I talk as no POC, no fix. And I want to present some additional IT security found in the Bluetooth stack that we found here in the Bluetooth stack. And I want to talk a little bit about the actual connections as well as about the methods that we had with those windows. So first of all, why do I do that at all? That's my motivation. In my time at the university there was a project where it was about the company of Broadcom WLAN controllers. And they built a whole framework for the patch. And we had access to the company. And that was then used to write corresponding exploits to use it. And there was a series of Broadporn and Quarkslabs in the last two years. If you do reverse engineering, reverse development, then it can be used by others, of course, to actually use exploits, so code that is used. Currently at Simo, there is work around the Bluetooth controller. And it's about debugging possibilities in the system to be built. We have the same problem that we're making a lot of knowledge about the controllers public. And we want to make sure that the invisible weak points are found before other exploits are built. Most of you already know it. It's a radio protocol that also works on 2.4GHz. It's used to communicate between devices, between phones and headsets, for example. And what some people might not know is that if you have a device with the Bluetooth archive, then you can already connect. There is an L2 ping and you can communicate about it. And you can interact with these devices without the owner getting anything from it. A series of protocols run in the company, that is, the actual phone doesn't get anything from it. And the documentation of it is often not public and of course also very wrong. We use a cypress platform, a developer board, if you say Cypress or Broadcom says that I always talk about the same company. Because Cypress bought Broadcom, bought the wireless part of Broadcom for a few years and accordingly I use both companies. And there is, for example, an developer board for Bluetooth Low Energy. So you can write code C and run it on the controller. And interestingly, there is no real separation between the application running on the controller and the actual company. So I prefer reading the RAM in different areas, the ROM and so on. The company has to somehow ensure that the code that you write yourself fits with the ROM. And so the development environment exports a whole series of information, such as the function global variable register. And so we can work a lot, a lot faster. A few of the protocols that are relevant are on the top. The actual device, the Bluetooth is used, the hardware is at the bottom. There is the L2CUP protocol that can be used to communicate between two devices. And that is packed into RCI, a protocol with which the host can go with the firmware and within the firmware we have a whole series of hardware registers for the serial interface. And the blue area, that is the multi-threaded firmware, which is implemented in different threads, the various protocols, the management protocol, the link manager, which processes the HCI messages and the link manager protocol. And that happens within the company and is not accessible from the host. And this link manager controls the so-called Bluetooth Core Scheduler, which is a kind of scheduler and this scheduler is involved for each clock. It controls what happens in each timeout cycle. And the Core Scheduler implements all the timeout critical tasks that are implemented within Bluetooth. So a little bit more background, the internal blue project, that you can use to debug the firmware. That was developed as the first one. So they didn't have symbols and they just didn't have symbols. And even though they were able to access the link manager and send the messages and send their own messages, I would like to talk in this lecture about Frankensteig, and this is also what was supposed to be possible with C. And why is this important? Why is it important? This is what a Bluetooth package looks like. At the beginning is the channel access code, an ID to distinguish between the devices. At the beginning is an identification of what kind of package it is. Then the so-called payload, where the actual data is inside. And at the end the payload has the actual data. And in the Core Scheduler you only have access to the actual payload. And you can send packages with your favorite data. And through the package header and the payload header, through the access, we can now create a lot more things. And we were able to trigger some very interesting bugs. So the main technique, as we did it, is called firmware king. We can execute C code on the controller and have an opportunity to implement to link us into existing functions, to complete the process, including the arguments that are used to use some text because we needed to modify the protocol behavior and transmit the user for fuzzing. And, yeah, we did pretty early in the process, we had the responsibility to copy the data between the controller and the hardware. And that means we can modify the data and, for example, through fuzzing, this is what we would like to modify. We have here this function, BCS-DMA-TX-Enable, EER, and this is the function, the Extended Inquiry Response, so extended response data copy. And if you scan your devices now, then these response packages will be closed through these functions and you can produce interesting behavior by giving back other data. And this is the actual fuzzing function. So the scan results are not as fast or not discarded. And here we are simply flipping bits and flash the code on the controller. We developed the software, we downloaded it on my laptop and immediately removed the Bluetooth controller on my old T430 laptop. The problem is that the T430 is very old. The firmware is about 2010. We tried the same technique against newer devices and newer is Nexus 5, so it's quite old. And there seems not to be affected. And newer devices are not affected. Gisgar said, look at it anyway. And I had no symbols for the firmware, so it was quite hard time to figure out what's going on. At one point I had a complete firmware image and it looks like that it was a heap corruption because it can look from where we come from and you can see it. You could see that a certain function was involved and this is quite problematic because in this specific implementation of the dynamic storage, a buffer overflow leads to the release of the data and it works first and when it should be added later, there will be a crash much later. So we had no luck with that and that's why we focused on the emulation in our research. The basic idea is the firmware is just an ARM code. We can maybe extract a well defined condition for the storage condition and then the registers might be executed. That's the code right that we tried with the XMIT state function that we executed as a hook. The storage has the registers in stack and stored in stack pointer at a specific storage point and then we call the XMIT memory function that activates all the interrupts. So we have no other code running in the meantime and then we send all these storage regions over to the host. It's important here that we don't use any functions, the threading for example, we have to use the hardware register to send the memory storage to the host and when we have the storage on the host, we can call the continue function and then we get our stack pointer back in the registers and we can continue with the execution and then we'll see how far we can get with it. But first let's see, we have the storage dam and the hardware register. We don't have them anymore. We have a few modifications to the firmware that we're going to do next time. And here you can see how we did it. We have a simple QEMU arm. We didn't want to implement or we didn't want to do any weird things with QEMU. So here we have the firmware that we're going to get our storage dams that we're going to connect to the object files. And then we have to do some changes. We want to write a C code. This C code speaks in the same storage space as the QEMU. We can compile that in an object file and then we have a full list of all the functions, all the global variables. What we can do now is to link our C code with the image that is stored on the chip. And then we can save the C code in the same storage space. We can pass the data structures, we can call the functions and so on. And at the end, and that everything is translated, we can bring it to a new ELF file and that is now, so to speak, the firmware. And then we have this extra side here with our C code and this code for some changes in the ROM and RAM and then it calls the continue function and the switches will be restored. And yes, first of all, we have some debate messages and then we have some questions and then first of all, we have some debate messages so that we can also follow the functions to understand what happens. And in the end, we were able to implement the threading behavior and we were able to extract HCI messages and we were able to extract wireless frames. And what we can do now is, as we can use HCI here, we can try to run the operating system and feed it on standard in to standard in through Reichen and then we can read wireless frames and then bring the firmware together with the operating system and see what happens. And that's what I want to show you in a demo. I hope it works. I have an Ubuntu system and as you can see, I have... Yes, that's better. Here we have the Bluetooth settings of Ubuntu open. There is currently no adapter and here we have... I can see what happened here on the HCI level and here you see the HCI config. There is no adapter at the moment and here on the top there is the magic happening. So this binary HCI attach is a complete firmware that we can run that automatically on the Bluetooth stack and we now have to add random data here, pipe and see how the system behaves and as soon as I do that, we can see that we get a lot of logs, a lot of activities, a lot of log output and we have a new adapter that is running now and sooner or later the firmware can actually start a question on the device and then we get valid results and the data that we get on the firmware will be interpreted as wireless frames and we can see here that a device was found and of course we also have a lot of log outputs and hopefully missed demo problem it doesn't work anyway I start it again scanning for devices so as we can see here there are a lot of log outputs but what I told you is that we can perform the firmware status in this case we also have a web frontend in which we can perform the firmware and then get results and here I have a complete firmware status that is executed until it reaches an idle state and as you can see we have information about the context switches storage instructions we can also have a look at the storage to see which storage regions have changed and also the symbols and in the end we have a activity map of the storage in which storage regions code is executed what is written and we also have symbol markings for the firmware sorry that the demo didn't work what happened here with the query there is actually a bug and here we have a heap corruption and there is a crash with this heap corruption detection report and this here is what you can see on the console and yes we added a heap sanitizer that is a program that has been observed correctly and yes, here it is that here had a storage allocation with Hex 109 bytes on this address and later we make a mem copy in this buffer with a length that is much bigger than the 6 4, 5 4, 5 Hex much longer than this 109 and this is then attached to the heap sanitizer and it locks what then everything happens and then we can actually this bug, the firmware actually the bugs and this was a actual CV that we reported and it is this heap corruption during the query we actually have the same bug as on the T430 so the problem here is we have a bug in a firmware that we can see in the firmware from 2010 and on a firmware that is from 2018 so it was at least 8 or 10 years in production of this bug and the interesting thing is the bug is actually to find the one is in the bluetooth scan scheduler and the other is in the link manager and if you look in the source code what happens there then we extract the package length from the payload header in which we throw the lower 3 bits and then mask the length field and in the link manager we allocate 264 bytes and then we do a mem copy in this buffer with the calculated length and what you might ask is why is this length check why is this length check missing? when we send packages that are longer than the expected 264 bytes and the answer is actually nothing happens because the maximum package time on the physical layer is limited and the bug here is that the bitmask is wrong here which is 13 bits long and not 10 bits as it should be that means the package length also includes a few fields that are reserved for future purposes normally set to 0 but as soon as you set a single bit in this field then you overwrite the allowed package length and then there is the bug someone asked can I make a mem copy with an overflow but I can't control the data that go in there what is the point of it but actually when you look at the firmware code we have a certain pattern for the payload that we can simply recognize again so down here you can see this blue part that is the actual package that we sent and for some reasons we have a part of the package that is duplicated so even though we only write 264 bytes we can get a controlled overflow that is pretty dangerous with the implementation if you have a block and that is how it should look it is simply the management of puffers with fixed pages and we have a free list a list of free puffers with links and if we have an overflow then we can overwrite and break and can simply link in a believable place so what you can do is you can use believable storage storage space as a buffer if you can alociate three buffers then we can overwrite believable data and when there are no external measures at all the complete storage of the system can be transferred and basically we can overwrite and then we get code instructions and if you think there is no address space randomization or something nothing so we have a full proof of concept for it and then we have it on Broadcom and then in April we have officially informed it after two weeks we asked for a status update what it is and they said they found this bug in February 2018 and they had a complete fix and then gave it to all their customers and everything is ok and that is a pretty poker face our ninth firmware was from January 2018 and they said and they said the bug of the eight years in the firmware was fixed after two weeks so we looked at it again we were pretty sure that we had this Samsung Galaxy A3 with a patch level that was after February 2018 and later we also tested the Samsung Galaxy S8 that had a patch level in March 2019 and actually we tested a few more devices and we couldn't find a single device that was not reliable so we asked what happened here and they asked we sent our customers the fixes and that is the thing of the customers themselves whether they want to fix it or not and as I said we couldn't find a device that was patched until jisgar bought the and found an scne and here is the relevant part of the code here is the mem copy and they have indeed a length check so they check whether the length is bigger than the expected 240 bytes then they truncate this firmware had a build date from April 2018 so they actually fixed it but in the end we had to escalate it to the manufacturer and we have Google and we contacted the Broadcom video chips Google, Samsung they also use Broadcom and Android had a fixed firmware image with this fix in august 2019 and also Apple fixed it to the available and also gave us public recognition and it was really we really had to actually send it to the manufacturer and here for this remote code execution a fix to be available that is not how it should be so now I want to talk a little bit about and I still want to talk about SCL or asynchronous so fuzzing SCL fuzzing is an interesting task because it is the most complex that you can test in this program because this also includes the link manager protocol implementation and we really expected a few bugs here and we also found a missing length check in our handle table and we actually tried a lot we did hard-covered fuzzing we did but this wasn't the SCL packages but that didn't do much because the SCL packages were directly to the BCL transport task and therefore they didn't go through the link manager we also tried for the request packages where we changed the packages before they were written and none of these approaches found any usable bug so we could not crash the firmware which was quite surprising for us except there was one crash that we could do on the Nexus 5 and that was during my final work but it wasn't on the scope because I wrote my work firmware analysis and the Android operating system wasn't on the scope I didn't have the time to bug it and also our images didn't have any symbols that was even more difficult we had a multi-threaded process and then I gave up and it's probably the fragmentation attack of Blueborn but later we tested it again so we could run against the SCN-E and we could actually see a crash I forgot about it and we see a crash and we crash in WAM copy but if you look up here this is the X2 maybe the length of the mem parameter looks like a negative number and the full address with a lot of zeros is a strong clue that we have a mem copy with a negative number at this reassembly and if you look at this distribution function you can see there is a mem copy that is a subtraction of the length and there is actually a case where it can be negative and interestingly it is solved by this IF request which is supposed to prevent a buffer overflow there are some crashes from which we can't explain why they appear it looks very strange because we have written it with a bit of raski but it is in a completely different place in code and we couldn't reproduce it so we might expect that there is something strange but first of all the relevant application here in code it is about the defragmentation of L2CUP packages a package that if you want to send a L2CUP message longer than the physical package then you have to distribute it and if you send the package if you want to send a package with 1000 bytes then the operating system will then allocate 1000 bytes and notice that the current package ends and if the next package arrives then the data will be copied in the end and before android 10 there was a very strange memcopy function there is for android 10 we can't create the same problem and when we started writing to write about it we looked again at the master branch of android and here the bookmark put on the android 9 branch and then I looked at the master branch and there was a commit that solves the problem and it explains wrong package length that leads to memory corruption and it was on April 18th 2019 and it was public visible for months but this bugwix was not used on any release branch then we built a proof concept and then it was public and about 60% of all android devices were affected and in November 2019 and the fix was on February 3rd exactly 90 days after the release on the finished fix to use the feature branches actually took 90 days every 90 days and there are a lot of devices that are not updated they are of course more accessible and we were contacted by a few automobile manufacturers that showed us how their patch cycle actually looks like and the problem is this chain of companies with short available where one company needs 90 days to continue the fix and the next company needs 90 days to continue their products and my conclusion these these exploits are very creative it would be really nice if you don't always provide remote code execution before these mistakes are lifted and although the bug was already known it was not fixed in the actual products and and there are always devices that are not fixed and it just takes too long until the fix is really coming to the manufacturers and we have published here even if it didn't work in the demo but in the repo is also to read how we analyzed the broadband and that was from my side and with that questions are we on the stream? which which heap sanitizer was used? that was our own and we took the heap ourselves to look at this test and you can easily put hooks into the functions that at this point check the heap and with that this analysis is also visible ASLR does not work on the ARM Cortex on these devices you can use it the so-called data execution protection you have to and and I'm not sure how you implemented that and Broadcom implemented certain checks but because of that you can understand the bug but it's not really a possibility in response to this bug um I don't understand the question sorry, I have to look into the patch that what? um so I I didn't hear the question that's why only the answer we didn't count it but there are 100 to 200 hooks that we use in a lot of debug and a whole series of functions most important functions are the ones that talk to the clock and we just replace them by the output directly in the emulator and there are some functions that don't make sense in the user space so interrupts switch on and off we just ignore and let me think then there are all the all the hardware relevant functions for example if you are reading or writing on a register and as long as I can write as long as the code can just write on a valid storage address it's already okay and for reading we have functions that deliver the default value um for which one for the Broadcom export I didn't hear the question so simon minus lab slash frankenstein the android proof of course the android the proof concept is not yet announced