 All right, we are here with our next QA session with Jiska and Francesco for the Spectra new wireless escalation targets talk. Do you guys wanna give yourself a little bit of an intro? Jiska, you wanna start? Yeah, okay, then I start. I'm a postdoc at Teodunksted in Germany at the Secure Mobile Networking Lab. And I've been, yeah, recently working a lot with Bluetooth before I've been working also a bit on Wi-Fi and IoT devices and all sorts of wireless communication. Hi, I'm Francesco Gringoli at I'm a system professor at the University of Brescia and have been playing with wireless technologies in the last 15 years. That's great. Thank you both. So, I mean, I'm gonna start off with some little bit simpler questions. So you talked a lot about this new vulnerability that's between the two cores. Is this something that can be patched? It's hard to say. So there are parts that definitely are not patchable because they are for the performance improvements. So the stuff that goes like between the U-code that Francesco modified and the communication with the serial interface on the Bluetooth side. This is something that you need, at least if you don't want to lose performance. And this is also all in hardware, I guess. So this is something like in a future chip it might be changed in a way that you can infer less information but it's probably not patchable in that sense or not easily patchable. The shared RAM is something that they should remove but I didn't see them remove it yet and I don't know if they can actually unmap it in the generation of chips or if this also needs a new generation of chips. I didn't see the shared RAM actually being used anywhere. So that's the weird thing, right? The shared RAM exists. Yeah, so it exists but it's really not being used for anything or at least for nothing that I could see. So this is the thing that they should remove because it's the most dangerous part. So we got a question from Cooper Q and this was actually something that I was interested in as well. You mentioned LTE is on some of the same frequencies and I know that there are some all-in-one chips that include LTE is in addition to their Bluetooth and wireless stacks. Have you tried going through the LTE baseband or use the Bluetooth interface to get at the LTE radio? Not yet. So what we tried is we tried to see if this connection exists at all and I can tell that in the Cypress Bluetooth symbols there's definitely like symbols that are called LTE or MWS something. And then I also took some logs on an iPhone and like iPhone 7 and newer. And on those devices, what you can see is that there are HCI commands. So that's from the operating system Bluetooth daemon to the chip that include MWS which is the configuration for the LTE coexistence. So they are definitely using it. I just didn't try to exploit it yet. Cool, fair enough. This one's one I'm going to, I'm gonna have to read verbatim because it's a little out of context. I don't know what it was. In the talk you mentioned Frankenstein. Can you talk a little bit about it? Yeah, so that's another paper. So actually the main work of this is from Jan who is not here, but that's one of my former students. And he made some snapshotting for Bluetooth chips of Broadcom and then also emulation. And the interesting part about this emulation is that it includes a thread switches and a virtual modem so that you can attach it to your Linux host and you actually can start scanning for devices and get back random devices. So you have like a full stack emulation in that sense. And this is something that we are going to present next week at Usenix security. The paper's already public. And also the software is on GitHub since a while. Could you send me links for that information? You can do it after the Q and A. I just want to be able to drop it in track one for anyone that's interested in following up with that information. So anyone that's paying attention and if you want the extra information, the links to the paper and everything else will be in the track one room as soon as this is over. Okay, on to the next question. So regarding the CVE 2019-15063 denial of service, Bluetooth Wi-Fi exploit. Is that the specific one that you guys were working on? I don't remember CVE numbers off the top of my head. Anyways, the question is, how are you manipulating the register of results and crashes? Are you physically accessing the chipset or can this be done remotely? So yeah, that's, so it's kind of two stages, right? So you first need some remote code execution either on Wi-Fi or on Bluetooth and then you could write to the register. And what we do for debugging is actually, so for Bluetooth when we modify Bluetooth, then we have internal blue, which is a framework that supports the vendor specific commands from Broadcom to manipulate the Bluetooth part. And for Wi-Fi, there's another thing next month. I think Francesco can tell a bit more about next month. Yeah, it's a project that allows people to do binary patching of the wireless driver so that you can modify and then add functionalities. But of course, this is not the remote execution, it's just for modifying the binary image without having access to the source code, which is a proprietary. And this allows to modify both the ARM core and also the U-code part that is the lowest part accessible in the hardware. Yeah, that's really cool. Is that a tool that is gonna get released like it's upcoming? Is that part of the usenix talk or? No, next one is, I just pasted it also in our private chat so you can copy it later. Next one is something, since when is it public? I don't know, 2016, 17? Yeah. And the interesting part about next month, so next month was just built to actually modify the Wi-Fi firmware without the intention to really hack it. So like more for sending arbitrary signals, turning your smartphone into an SDR. And the interesting part here is that back then in 2017, actually, Google Project Zero and Netai Alpenstein used this knowledge to dig a bit further into the Broadcom chips. So like Broadpwn and stuff like this was also not only but also based on next month and also later work, they always use next month. So that's a very interesting thing about this. And then for the Bluetooth stuff, it said like, okay, then if others use it for exportation, we can also do exportation on our own. How do you guys go about researching phones? Since for the most part, everything seems to be closed source. So we're asking to talk about like the research process, like if you were going to try and exploit a new phone. Ah, yeah. So that's the thing. So the first part is, I mean, if you don't have already have a working over-the-air exploit, which is hard to get, especially if you don't have the rum of a device and so on, even if you had an exploit, like getting it working on a new device would be hard. So usually we start with a rooted smartphone or a jailbreak or, I mean, also MacBooks have Broadcom chips. So, and there you are already root. So it depends a bit. And then we would dump the rum and the rum, I mean, for Wi-Fi and for Bluetooth, it's pretty much the same. And for Wi-Fi, the rum also contains the U-code and the U-code is the thing that runs in the D11 core. So what Francesco modifies, and for me, it's more the Bluetooth firmware. And then it's very annoying because like the stuff is still without any symbols and especially Bluetooth also doesn't have any debug strings. The U-code doesn't have any debug strings. The Wi-Fi firmware has a few debug strings. And since this is like, so even the memory layout is somewhat unknown and you need to guess it and so on. And because of this, it really horribly loads into IDA. So it really looks ugly. Yeah, fair. And I think Francesco, for you, it's even the case that you get new instructions, right? Yes, for the U-code, there is no actually correspondence between the U-code and the any known CPU. So we had to do this reverse engineering for understanding the meaning of this instruction set and then adding instructions because Broadcom during the years added new instructions. And yeah, the reason this was very difficult because it's not ARM that you, the compiler disassembled but you have to develop your own tool chain with this. Which, so what happened is that Broadcom didn't change much the platform since they introduced it 15 years ago. So they are additionally adding instructions and also what helps is that the U-code is very short is less than 64 kilobytes. Have you, either of you looked into any of the newer like mesh Bluetooth protocols? Bluetooth mesh, so a colleague of mine did that last and he looked into the friendship together with a few other people in our team. So it's, so yeah, we did that in our team but the mesh is not really interesting. I mean, it's just using Bluetooth LE advertisements. So from a, at least from a lower level perspective, it's nothing special. I mean, of course, implementations on top are interesting then, but I mean, I do a lot of lower layer stuff. He just showed that the encryption and so on in the friendship of groups is broken and Bluetooth SIG send funny responses. Of course it is. Someone else is shouting out that a lot of your and related work on VLE is also available as preprints from YSEC 2020. And then they also threw a link in there so I'm sorry to shout that out. Francesco also has done stuff with Bluetooth sniffing, right? You built a Bluetooth sniffer. Yeah, this real time sneaker using a software for radio for capturing all the channels at the same time and GPU for the coding and brute forcing lowest address, part address and low energy session ID. Yeah, I know that there's a lot of kind of a wide range of like capabilities of SDR stuff. Is there like a minimum requirements for the SDR hardware to do that level of sniffing and for Bluetooth? Well, if you have SDR that can sniff 80 mega, it's better. But for sniffing Bluetooth classic, we demonstrated that it's enough to capture only 16 channels out of 80. Then you can also use one of these cheap SDR like Hacker F or Blader F. So you do not need to buy a very expensive 1000 of euro 80 mega, but you can buy one of these for 100 bucks. Yeah, that's awesome. It should work. Yeah, accessible hacking, it's nice. Got one person asking, do you think Broadcom is relying a little bit too much on security through obscurity with some of these chips? I mean, so what you can actually see and that's an interesting development. So the first bug that Jan discovered with Frankenstein is one in the Enhancing Viral Response. And when he submitted that one, they said, we already know the bug and we just didn't find it anywhere. And then I got like the newest Samsung Galaxy S10e and extracted the ROM and this one actually had a patch and it had a compile date of April 2018. And that also means like they cannot change the ROM so they cannot tell us lies about the ROM and we reported it afterwards. So that actually means they knew it before, but and now that's the interesting part of the story. They didn't patch it backwards in the older devices because it wasn't publicly known as a bug and we could easily unroll the patches. Now the thing is they definitely increased the security I would say after the bugs in 2017 were public. So I mean, it took them a year probably to do some pen testing and so on, but you can see like 2017, the first public incidents happened. 2018, the first kind of secret patches make it into the firmware. And also they started using like, I don't know, stuff like secondaries. They didn't have it before. So this is things that now are going into the firmware. It's still not like super perfect and everything. It's still of course close source, but I mean most firmware in wireless chips is close source. Yeah, so at least they are trying to work on it. And I think they are aware on that like security by obscurity doesn't really work. So someone's asking if anywhere people can find the source code for that Bluetooth sniffer. Francesca, I think that's fine. Yeah, I can send you a link. If you send me a link, I will post that with everything else one. Yeah. And another one, do you think a Bluetooth or Wi-Fi based worm is feasible in the wild or is interoperability between implementations too difficult to bridge? So I think for Wi-Fi it's hard because for most stuff you need to actually join an access point or something like this, but for Bluetooth you have this master slave mode. So you can actually have a device like a smartphone that's usually capable of being master and slave. Some like cheap devices, cheap IoT devices sometimes are only in slave mode and cannot do master. But if you can be slave and master, then you can be part of this, let's say, war network and like distribute the malware. And I think there is, let's say, a sufficient fraction of popular devices. So it depends if it's in the operating system, then it would have to be like compatible iPhones or something and then I mean if you just, there is not much diversity in the iPhone. So if you just take like the top selling iPhones or something that also would work on the chip base. On Android you have more diversity, but still if you would say you just pick the top Samsung and Galaxy and maybe the pixels or something. Yeah, that could work. So yeah, actually uncovered vulnerability in the Android Bluetooth Demon and that one would have been warmable and it was fixed in February. I mean still, yeah, so you couldn't in fact like 100% of devices, but considering that you have the Bluetooth on and walk around and so on, that would be a threat still. So the reason why I think people wouldn't build it is how do you control it? Because then you need to have some communication over the internet or something. How do you do like a command and control server for Bluetooth warm in a way that is like stealthy and really, I don't know. So I think it's really more, the bigger threat is stealthily taking over nearby devices or like hacking someone or like going next to an office train station, somewhere where you know like interesting people are and taking over their devices. But I think even if it's warmable, I think this is nothing that people would build. But I mean, maybe someone builds it someday so I won't build it because well, I wouldn't, but I mean, maybe someone is crazy enough to do this, right? It's just true. I mean, you could potentially just do it without a financial motivation just to see if it works or something. Yeah. So switching gears just a little bit. Did you guys report this to vendors? Like how was, how did that communication like turn out, was it positive? Was it negative? Was it talking? Yeah, so the very first report about this denial of service was in August last year. So that's like a year ago. And I think they didn't really take it serious because it was just denial of service, right? And even if you have denial of service with an operating system reboot, it's like nothing that you could really control, right? So like writing FF21 register, it reboots okay by two cares because you need RCD first. It's hard to control. And interestingly in September that year, the iOS 13 update came out and it actually mentioned Yan, Francesco and me. So Yan was working mainly on Frankenstein. I also worked a bit on Frankenstein and the coexistence was what I did with Francesco. So I was like, okay, if they also mentioned Francesco and me, they should have fixed it, but they didn't. So I was a bit confused that all the names were mentioned there in the iOS 13 update and also a month is a bit too short. And everything that they patched but silently already before was the enhanced inquiry response issue. And then like I poked them from time to time that you already patched, why didn't you patch it and so on. And at 363 on stage, I also showed that this is still unpatched and so on. And they still didn't patch it. And back then I already had in mind, so that was when I already called Francesco and said, like in January, we are going to build speculative transmission. So I was like, please get things in that direction of a text fixed. But yeah, and then end of January, I actually knew that this is probably unpatchable. And that was when I sent Apple that email, you know why Broadcom didn't send you a fix because it's unpatchable. And we're like, what, how are you telling us? And yeah, so at least, so that means like Broadcom and also like some of their customers got like some, some notice already in January about those things like that they are broken. And I mean, also like the ones before just about denial of service. And then I was building a few more pox beginning of March because I was very busy in between, but that were like the final proof of concepts like that there's even this rum sharing and it is exploitable and stuff like this, which I mean, Broadcom should have known it already. And they already introduced this one patch that you no longer can write to the Bluetooth rum after drive initialization that one was already pushed to devices somewhere around March. So this is like the thing that they did against it and that they could easily do because they were like informed quite a long time before. And then in March, when all the proof of concepts were also like easy to run running and so on, then I also started informing the other vendors who I found to have a coexistence in the data she's mentioned. So it's probably not everyone who uses it, but at least people I know that they use it. So this is something that like if other people were gonna go look at other chip sets, the coexistence is what they'd be looking for for a similar style of vulnerability. It might be something, yeah. So I'm not sure how it is with all the other devices, but it's definitely existing in a couple of devices and all proprietary. And that coexistence is controlled by that one. Was it CC10 chip? I forget the name of the chip. It was the microcode portion that's... Ah, the D11, you mean? Yes, that's the D11. Yes, it's controlled by this low level stuff because it must be real time. So it's an arbitration between the Bluetooth and the wireless and the wireless need to run this into the lowest part of the stack that is directly on this microcontroller. Could you, is there anything else about that microcontroller that you wanna talk about or share with the people that are watching right now? Well, I think that it's very interesting if you can have the ability to hack this because it's the part that can decide what to transmit and whether to receive a frame should be pushed to the host. So it's very interesting because you can also develop a very small stack over there and the behavior of this stack would be completely not detectable by the host. So there is no way for the host to understand what the U-code might do. So if you find a way for changing the U-code over the air then wow, that's amazing what you can do, but. So is it something that could like proactively drop packets with like a magic value or something like that? Yeah, yeah, yeah. For this test that we were doing with the coexistence we were sending common to the wireless interface over the app and the U-code is the D11 core is receiving them, then dropping them and changing the configuration of the wireless interface. This is totally a notice to buy the host. That's awesome. What are the next areas that you guys are looking into for like future research? Do you have anything already lined up? Anything you can talk about? Probably they can talk about this the part, right? I mean, obviously like wireless security, but yeah. So there will be stuff coming up. So I will definitely do further research. And I mean, Francesca has been doing this for so many years. Probably nobody else is like questioning what he's going to do in the future when he has doing it for the last 15 years. Well, fair enough. Yeah, I'm running out of questions. We do have a couple more people that are typing now. So I mean, we've got a few moments. Is there anything that you guys want to talk about proactively that we haven't already covered? I mean, so something that is kind of interesting is that like people currently like also if you look into the first YouTube comments of the talk, it's like they are like, you are just publishing this because I don't know there is this exporter notifications for Corona and stuff like this. But actually we have been working on this. I mean, since much longer time than this. So it's nothing that's like connected to Corona or something in that sense. And also I think like for average people who just keep their system up to date and just use it, I don't think that it's like a big threat in that sense. I mean, of course, like if you go on DevCon where a lot of hackers are around you, you might want to disable Bluetooth and Wi-Fi but like disabling Wi-Fi also has been a well-known practice in the past. So, yeah, it's... In your experience... You need to be a device? In your experience, does disabling like Bluetooth and Wi-Fi in the device actually turn off the full radio? It doesn't turn off the chip but it disables the whole stack usually in a way that you cannot establish active connections anymore. It depends a bit. But so, yeah, I mean, of course, like switching off your device if you don't want it to be hacked, this good practice is probably even taking out the battery. It really depends on your level of paranoia, of course, but so, yeah, so those people who are afraid because they have like... I don't know, if you have something on your smartphone that's like worth 100,000 bucks or something then maybe consider being hacked because this is like the range where the exploits for those devices start, right? So, yeah, so that's probably the threat model here and I don't think that like... I mean, until someone writes that Bluetooth form, who knows? But I don't think that until then like Bluetooth would be the preferred way to hack people. What I still don't like about like... Or how all this stuff like goes is that still Wi-Fi and Bluetooth are like... I mean, they have been exploited back in 2017, very publicly, and they are still very insecure and that's the part here. Like they have been insecure for years and there's... I mean, some things are happening, but really vendors and so on, they really need like some motivation to fix stuff even further. And so I wouldn't really say like, we are making it more insecure. It's really like kicking them somewhere and saying like, please, please fix it. Please make it better. Like we have seen like at least some improvements within the Broadcom film where it's still not super secure but it's secure after the things that happened in 2017. And yeah, so I hope to move it a bit more in this direction. Do you have a general feeling for like, if there's any particular chips that are seen more secure than others like the better coding practices or anything like that? Or are they all kind of roughly the same? There are at least some that are more obscure than others. I mean, Qualcomm has their own hexagon DSP which you can emulate, but there are, I think there's a disassembler plugin for Gitra which partially works and then there is two for IDA but they also don't support like all commands. Then you just have this assembler and now the compiler. Gitra, you would also have the compiler. So it's really bad quality of those tools for Qualcomm. And then still last year at DevCon, there has been a talk about Qualcomm Wi-Fi having a bug and they saw after the talk, I just went to them I was like, how did you find it? I said, just like static reverse engineering. I was like, the hexagon, right? But yeah, so not sure if Qualcomm is more obscure or really more secure. At least they have more people on security conferences. And but yeah, it's hard to tell. So I think in general, if you have newer hardware, then you have more security measures in it and like newer chips. So if you buy like the most expensive Google or iPhone or whatever, it's probably more secure than if you buy some very cheap smartphone with cheap chips that didn't have so much money for development but it's still no guarantee. So it just, it could have the budget to make it secure if they wanted to make it secure. It's no guarantee, right? Fair. And this is the last question that I think that we can take and this one's not directly about your presentation. So I want to know how you displayed your hand behind your presentation in the actual recorded video. So that's actually a method that I stole from Daniel so the guy who did the spectra. So for his lectures, he's using OBS and he has a white wall. I mean, I also have the white wall behind me, right? And then I point with my hand and this is the part that I'm filming. And so this part would be like behind the slide and in the slide I said white as an opaque color and then I put my hand off so behind it. So then I have the layers and I can do the pointing. So this would be the pointing. Nice. I'm sure some other presenters will appreciate that touch. Okay. Well, that's all the time that we have for you. Thank you both for joining us for the QA session. Thank you both for getting content into the virtual DEF CON and yeah, have a nice day. Thank you too. Take care. Thank you too.