 Speaker is Yiska. Yiska is attending this conference since ages, like a decade, even more. 22, 53. Long, long time. Sometimes she is also doing some talks here. The last one last year was about Bluetooth. There she was in depth. This time it will be a more general talk about wireless protocols, NFC, LTE, Wi-Fi and of course Bluetooth. So she will tell us what is broken and all those protocols. So have fun and enjoy the talk. All wireless communication stacks are equally broken by Yiska. So welcome to my talk. I thought it first to be a foundation talk, but it will also have new topics about everything that is kind of fundamentally broken in wireless communication. And it will cover anything in your smartphone. So like NFC, Bluetooth, Wi-Fi, LTE, you could order them like by communication range or by specification length or lines of code. But the thing is so the specification length and line of code also mean increased complexity. And if there is increased complexity, you might have issues with security in it in the variant. And then there is something that is even worse than LTE, which is vendor-specific editions. That would be when you open like five instances of IDA and like try to analyze where a wireless message is going and what it is doing. So most of this in this talk will be about wireless exploitation and the new stuff will be fuzzing techniques and a new escalation target, but everything else is more like a general view on wireless exploitation. So first to understand what the wireless exploit does is to separate it in different layers. So there is the lowest layer, which is some hardware chip, which runs a firmware, let's say a Bluetooth firmware, which is then attached to a driver. Then there's some privilege stuff. It depends a bit on what kind of system you're on. And in the end there will be applications. And no matter where you exploit is, on that layer that you're exploiting, some security measures become ineffective. So for example, if there is encryption and you have an exploit for that layer, it would become ineffective. And it depends. So the higher you are, the higher also the exploit prices get. So for the Wi-Fi RCE, you would be at 100K for a baseband RCE with local privilege escalation, it gets already 200K. And if it's just a messenger or something, then it's like really, really high in the price. So the question is like why is this wireless stuff a bit cheaper? So well, you need a certain distance. And so that's probably a thing. And then also maybe they are just too easy to find, I don't know. Like at least maybe for me, I don't know for normal people. Or maybe the market demand is not that high for them. Or they are not privileged enough, I don't know. But actually they need like only like none or less interaction. So yeah, still a thing, I would say. So within the group I am working at, we had a lot of wireless research and also tools that we released. And the first one I think that was running on a mobile phone is NFC gate, which is currently managed by Max. Then there is Nexmon, which is our largest project, which is patching of Broadcom Wi-Fi. And Matthias who did that reached his goal by just saying like I now have kind of a software-defined radio and in a commodity like Broadcom Wi-Fi chip. And so he was a bit bored and kicked off two new projects before he left, which he then handed over. The first one is Qualcomm LTE and the second one was Broadcom Bluetooth, which I ended up with. And then we have someone else who is Milan and he's doing stuff that comes more like from the application layer. So he implemented an open-source solution for Apple AirDrop that you can run on your Raspberry Pi. And while the hacker is going to hack, so this stuff has been used a lot for exploitation, not by us, but by others. So there were three groups using Nexmon for Wi-Fi exploitation, at least like what is publicly known and like the bigger ones. Maybe I forgot someone, but so there is a lot of exploitation going on there. Then internal blue has been used to demonstrate an attack against the key negation of Bluetooth just this August. And the open AirDrop implementation was used for some honeypots at Leckhead and AirDOS and like a lot of stuff is going on there. And then you might ask yourself like, yeah, so if everybody's using it for exploitation, why don't we just do it ourselves? And we actually did that and we even did that for this very first project, this NFC project, and the most important thing you need to know about NFC is that the near field is not really near field. So there's it's just communication, but it's not near field communication, which means, so if you are able to forward the communication, so for example, you have like your credit card and then a smartphone with NFC, you could forward it over the cloud or some server and then to another smartphone and then to the payment terminal. And usually there's no time constraint or distance bounding that would prevent this. So you can at least forward and relay messages and you might even be able to modify them on the way. And some students of us did like some testing in some systems of some third parties who then politely asked them to please stop the testing. So it was not really a cool thing overall, like not good to publish and so on. And the more happy I am about that there's other researchers who actually used some other tooling to look into NFC. So just this month there has been a talk at Blackhead, so not by us, but by others about the Visa credit cards and it's just all broken. And it's cool that some people like to did it anyway. Yeah, so this is more about, so the NFC stuff is more about forwarding and the actual specification, but something that is also cool is if you get code execution within a chip, and this is a very different text scenario. And for Bluetooth, I think it's especially bad because of how everything is designed. And the first design issue in Bluetooth is that the encryption key is stored in a way that the chip can always ask for an encryption key at the host, or it's even already on the chip and there is no kind of security there. So whenever you have code execution on the chip, it means you can get all the encryption keys, not off just the active connection, and then break everything that is kind of a trusted connection by this key, and that even breaks features like the Android SmartLog. And Android SmartLog is the thing you can unlock your Android smartphone if you have a trusted device, and if you like add this, you might do this for your car, because it's nice in your car when you have like your your audio and your navigation and everything without a locked smartphone. But the question is like how secure is the Bluetooth of your car? Would you trust that one to unlock your smartphone? I don't know. And the next thing is, so if you have code execution on a Bluetooth chip, it also means that you might be able to escalate into some other components so that you go up all the layers. Then next question is the exploit persistence. So let's say I have something that is running on the chip and I don't know extracting encryption keys or doing whatever. You might ask yourself, so how long will it be on the chip? I mean, it's just a Bluetooth chip, you switch Bluetooth off sometimes, and then the specification, so just at page like almost 1000, so that's like the first third of the specification. It says not the HCI reset command will not necessarily perform a hardware reset. This is implementation defined. Then I looked into the Cypress and Broadcom chips, and so yeah, so if you do HCI reset, it's obviously not a full hardware reset. It's just flushing some hues, connections, stuff here and there. So there is definitely memory areas where you could put your exploit and it would be persistent. So then you might say, yeah, okay, so what do I do? I don't know. I put my smartphone into flight mode for a hardware reset that usually doesn't work. You might also like reboot your phone. In most cases this works for some other coexistence stuff. I had the impression that sometimes so it's a bit strange. It might not necessarily like reset. Turning off for a while might hide reset the chip, I think, or you just put your smartphone in a blender and then yeah. So that might turn off the Bluetooth chip finally. Yeah, so the next issue is, so let's say we have an exploit running there, but we first need an exploit. So the very first step is still missing as a building block and after the talk last year, I did some stuff with unicorn and fuzzing on the chip and it was super slow and then suddenly Jan showed up and Jan said, hey, I want to build a fully emulated chip for super fast fuzzing and attach it to Linux and everything should like run as on a real system. Just the over-the-air input will be fast and I was like, you cannot build this for your master thesis. And then he was building that thing within three months and the remaining three months he was writing a thesis and emails to vendors. So here we go. What does Frankenstein do? So it's running on an evaluation board of that. Yeah, it's just a normal Bluetooth board that's connected to a Linux host of a UI and the modem over-the-air and then he would snapshot that thing and emulated and give it fast input, attach to the real host and that means that if you find some vulnerability, it might be within all the components, so it might also be on the Linux host or it might be something that is full stack. So you have something that starts on the chip, gets to the host, the host requests for the things and then it goes back to the chip so you could build like quite complex stuff and for this I have a short demo video. So the reason why I do this as a video is that it might happen that it finds C overflows otherwise and then also it's not super stable at the moment. So you can see it's scanning for e-devices and then via shark most of the time would get my phone packets but sometimes it would also get normal packets and like some mesh stuff, whatever. So this is Frankenstein running. Yeah, so what Jan focused on is early connection states. That means stuff where you don't need a pairing and then he found like heap overflows there in very basic packet types. So quite interesting and then the stuff was fixed I think or hope whatever. So at least like in very recent devices and then the iPhone 11 came out and in contrast to the specification over the air the iPhone 11 says hey, I'm blue to 5.1. I was like wow first consumer device blue to 5.1 and I was like I don't really mind my way of the exploitation as long as I can get code execution on the chip so if it is with user interaction and a pairing and whatever I don't care as long as I get code execution on it and then I was like okay, let's add some fast cases to to Frankenstein continue fuzzing and then I found that specific evaluation board that Jan was building this for has a problem with the heap configuration for certain packet types and So if you change that you would hide brick the device. I mean why I pricked two evaluation boards trying to fix stuff So yes, it's just pricked and So that means for me to continue fuzzing to write like to port something like 200 handwritten hooks to another evaluation board It's almost running. So it's that's just some stuff with thread switching that is not super smooth yet But like it's it's almost on an exploit And further plans are you to add more hardware? So we are also working on the Samsung Galaxy s10 and probably a Mac book to get it in there So then it would not just be linux, but at least Mac OS maybe Android. I don't know yet And another thing that would be cool and also we didn't build yet But it might be feasible with some usrp X310 over a piece I express and with fpj and all the fancy stuff to get real over the air input Which then would mean that you would have a full queue like from over the air real Bluetooth packets going all the way up and Then to a host and the way back and you could also use that just to test your new Modulation scheme or whatever you want to change. So not just security Yeah, so the next thing is so if you have code execution What do you do with it and the normal approach is to try to go all the layers up? but there might also be some chip level escalation and You might immediately see it on the next picture So this is from a Broadcom chip But that's something that you would also see in many other chips Which is that you have a shared antenna and you could also have two antennas But they are both on 2.4 gigahertz and it's in the very same smart phone super close next to each other And you would get interference. So usually it's just have the same antenna and do some coordination Like when it's Bluetooth sending when it's Wi-Fi sending so that they don't interfere and this feature is called coexistence and there's tons of coexistence interfaces, so this is just the one from Broadcom and When I saw it I was like Oh Francesco, let's look into this, you know all the Wi-Fi stuff. I know all the Bluetooth stuff Let's do something and he was like nice. It's just it's just a marketing feature so that they can like Sell one chip for the price of two chips or something and I was like no no no it must be an exploitation feature So and then to end this discussion I went to Italy for eating some ice cream and So reality somewhere in between it's more like it's high-coded blacklisting for very less channels and stuff It's traffic classes for different types of traffic for Bluetooth and Wi-Fi and you can look it up in tons of patterns And it's it's like super super proprietary And so we let's say we played a game Which was like I tried to steal his antenna and he tried to steal my antenna and so it turned out if you do that Yeah, you can turn off Wi-Fi via Bluetooth Bluetooth via Wi-Fi and then So like on most phones you need to reboot them and some of them even reboot them themselves So this is just like a speed accelerated thing Within Samsung Galaxy S8 that is not up to date For iPhones you would just immediately see a reboot without any interaction of things going off and on So Broadcom is still in the process of fixing it I don't know if they can fix it but they said they could fix it But something you should definitely fix is like the driver itself so that the smartphone reboots and so on so I don't know I thought it would be fixed actually in iOS 13 because it mentions Francesco and me but still on 13.3 I don't know it's still You can still crash the iPhone that way But it's just some resource blocking so it's like not a super Dangerous thing I would say and you still need Bluetooth RCE before you could do it and so on but still not cool that it's still not fixed Yeah, so what about the other stacks and the escalations so there is tons of different Bluetooth stacks, so it's really a mess and Obviously because of Frankenstein we had this first Linux Bluetooth stack attached and so on but yeah, so what has been there for Wireless 2017 this blue-born attacks you might have heard of them And they found escalations like on Android Windows Linux IOS whatever and then you might say like in security You often say so someone looked into it. It must be secure now And then there's so many features coming so there's all these IoT devices So everybody nowadays has wireless headphones and fitness trackers and put this always on and in the Apple ecosystem It's it's really a mess So if you have more than one Apple device you would have Bluetooth enabled all the time Otherwise you couldn't use a lot of features and then there is like stuff like web Bluetooth So Bluetooth LE support from within the browser So it's like a lot of new attack surfaces that arise since then So I think so that's more like my personal estimation is like 2020 might be more blue-born like attacks Yeah, so The saddest Bluetooth stack somehow is the Linux Bluetooth stack, so I don't want to blame the developers there I mean it's not their fault But it's like not enough people contributing to that project and if you would try to to analyze something that is going on in the Stack and you don't really know what is going on You would do like get blame whatever and you would always see the same guy as the committer So at least if you are like on a specific problem, then there's only one person Committing there and so the picture down there actually has like the same guy twice. So this is also a bit of a pun here intended We did some fuzzing in there. We still need to evaluate some of the results. So yeah, but I also feel like nobody is really Using it and it's kind of sad. I mean, there's some Linux users. I guess but yeah Then there is the weirdest stack I would say so there's the Apple Bluetooth stack and this one is actually three So there is there is a macOS Bluetooth stack There's an iOS Bluetooth stack. They are definitely different and then there's a third embedded one for example for the airports They are all Running different different things. So yeah, whatever And then they also have tons of proprietary protocols on top of their Bluetooth stuff that they're also very special And I had like at least two students just one porting it to iOS one to macOS And then we also have students working on on the other Protocols that are on top of Bluetooth and if you look into this, it's like what the hell So it's it's really hard to reverse engineer because you have like three different Implementations and then sometimes you're like, yeah, okay. Maybe it's also just bad code and in the end So from what I saw so far would say that it's kind of both Yeah, and then there is the stack that I played also a lot around with which is the Android Bluetooth stack And they did a lot for the security in the recent releases And it annoys me so much that when I want to get internal blue running on it It's just echo to the serial port instead. So I bypass everything that the operating system does And so something that Android cannot do which Apple does is so Apple has all the proprietary protocols And if something goes wrong they immediately cut the connection But Android doesn't because of compatibility and stuff So you could just send garbage for like two minutes and try and see what happens and it would continue listening and asking and confirming Yeah, but that's kind of an overall design issue. I think and Yeah, then there's windows and I couldn't find any students to work on windows So yeah, so if someone wants to do this that would be great Yeah, and so another stack so that's kind of missing here is LTE and I would call this like the long-term Exploitation plans, so it's not I think it's like long-term evolution evolution whatever but exploitation. I think it's the best thing for the Yeah, so we have like tons of Viola stuff where we are working on and I mean like even power PC and Then there's Qualcomm and they they have they have this Qualcomm hexagon DSP. I hate it so much So there's even source code leaks for their LTE stuff, but it's just such a pain to work on it So you might have noticed this that our chest is LTE project with Qualcomm, but it's it's just not fun But other people were doing a lot in in this area and they've already Presented here today and yesterday So the first thing is the SIM card in in the phone So the SIM card should be a thing like from from my perspective that should be secure because it protects your key material And then it runs tons of applications I don't know and then you can exploit them and get the victim's location dial premium numbers and launch a browser and then I didn't really understand like there's this this WIB set browser whatever and then there's Ah Launch browser, what is it and I think it even launches a browser than on the smartphone whatever It's just crazy and then I was like trying to call Deutsche telecom and I'm a business customer. So it's like just like three minutes for a call for me So giving a call there's Nice and then the first thing they told me is like you are secure We know you have three SIM cards and they are all up to date So I have to say one of them is more than 10 years old, but maybe it's up to date My answers like what exactly is running on my SIM card were of course not answered So yeah, something is running there. If you want to know more about SIM cards There has been a talk already yesterday evening and it's already online and Then there's also a lot of people looking into LTE and I think the most popular one is the work by young die Kim He did even some LTE fuzzing framework that he didn't release Publicly so far because of the findings. So it's like should you publish should you not publish? But so the findings are super interesting and he also had students here who just did a talk this morning Yeah, responsible disclosure. So that's the thing like yeah, when you when you find stuff, you need to respond to this closure and so I said Jan was writing a lot of emails and one of the first that he wrote was like To Thredyx because Thredyx is the operating system that runs on the Bluetooth Broadcom Bluetooth chip and So he said like your heap is a bit broken and does not have any checks You could implement the following checks which are pretty cheap and it should be cool And then I could not attack it anymore and then FedEx was answering Which was a bit unexpected That they already knew about this Exploitation technique and that it is up to the application to not be vulnerable to many memory correction So it would not to cause any memory corruption So it's the programmers fault if they do something and it's not the operating system that has to take care of the heap Okay Yeah, next issue So the binder thing and the testing if a vulnerability is still there So you might not always get feedback from all the vendors if they fixed it They may just fix it at a certain point in time And then you tell them all we tested the next release and it's still vulnerable And then they would say like for example Samsung said yeah We cannot send you patches in advance without an NDA because Broadcom blah blah blah and so on and so forth And then Broadcom offered to send us like patches in advance And I said yeah nice and I also sent them a device list because they already knew it from the previous process So if you tell them the following ten devices have an issue then you would already know that we can test those devices anyway And so and after I send them the list they said oh wait, but you need an NDA Okay, so no, I mean we are doing this for free anyway and then signing an NDA. I wouldn't do that Yeah, so overall also the Broadcom product security incident response team is a bit strange So they wouldn't hand out any CV ease and what I mean where I do is like I first get a CVE and then inform them and all their customers Because I also don't get any incident number or something. So if I wouldn't do this I wouldn't have any number to refer a vulnerability to and Well, at least they also not doing that much legal trouble, but it's just yeah Not really something happening there But some of your customers were nice at least to my students So they paid so one customer they don't want to be named here But they paid a flight to death con for one of my students and Samsung gave a bounty of $1,000 I mean still I mean we are in the range of way way more expensive exploits if it would be on the black market But for your students, it's definitely nice Yeah responsible disclosure timelines So this is something that I thought like maybe some of this responsibility disclosure timeline is just Because of how I communicate with the vendor and sometimes I'm writing emails like a five-year-old or something I don't know but actually So this is a timeline of of quark slept Who also found just this year vulnerabilities and brought on Wi-Fi chips And so they were also asked about NDA and then also their exploit timeline is a bit fun because They had similar Exploitation strategies as in the very first exploits that you could see by Google Project 0 And then yeah more disclosure timeline, whatever and in the end well So It's just taking time and again no CVE ID issued and so on and so forth. So it's the very same stuff for others Which is pretty sad And then so for Cypress, which is partially having source code of Broadcom and also Manufacturers chip it's also very slow for the Responsible disclosure and then I got told by other people like yeah If you would disclose something to Qualcomm it also takes very long and well luckily we didn't find something in an Intel CPU But yeah, there's so on the wireless market. There's still so many other vendors to become friends with so yeah So practical solutions to end my talk what could you do to defend yourself if you don't have a tinfoil hat other things I can recommend is The secure Wi-Fi setup so don't use antennas just use antenna cables We do that in our lab a lot so this is a setup by Felix and So when I was sending my slides to Francesco in advance, he just said like cool I have the same one right now at my desktop. So it's a very common setup Maybe not at your home, but for us it is Or you just go to the egg up device. So this is my power book one hundred seventy. That's a really great device Almost impossible to to get it online and it has rude and axle So ask all the questions Thank you very much to Yiska We still have several minutes left. You will find eight microphones in the room Please line up in behind the microphones to ask a question and the first question goes to the internet So hell Yuska The question is are the Bluetooth issues you were talking about also present in Bluetooth low energy IOT devices Yes, so I mean there is IOT devices I cannot tell the vendor, but there's also some popular devices that have like Cypress Broadcom chips and Then it's even worse because they don't have a separate stack But often they have an application running on the same arm core, and then you don't even need any escalation All right, we have another question at the microphone number one, please Thank you for the talk My question is Could you like did you actually when you first the the Bluetooth low energy chip? Did you when you managed to get code execution? Did you actually climb up the protocol? Did you like access Bluetooth profiles or something like this? So we for example for the thing with the linky extraction we were building some proof of concepts But so It depends on we don't currently have like a full exploit chain in terms of first on the chip and then on the host We have something that goes directly on some holes, but yeah, there's tons of things there to do Sorry, yeah, and when you first the how did you actually fuzz the chip itself? How did you extract the firmware from the chip? Ah, so there is so Broadcom and Cypress are very nice because they have a read RAM command So you don't need any secure bypass or something and for the evaluation kits. There is even symbols that we found in it so Symbols only means like function names and global variable names. That's it, but that's something to work with Thank you another question from the internet, please Would you like the return of physical switches for the network controller? Yeah, so that would be nice to like physically switch it off Actually, I don't know where Paul is but he's building some here. There's Paul. He's building such a device Yeah, when is your talk at 10 o'clock Paul is giving a talk about a device where you have a physical control to switch off your wireless stuff Okay, the next question is again microphone number one, please. Yeah, thank you We just bought a new car and by because connecting the Bluetooth of my phone to the cars System was very very hard and I had to reboot the radio several times And then I found a message that the radio must be directly connected to the canvas of the car So you have a blue stick Connected directly to a canvas. It was a very cheap car, but If you have an idea what this means then can you can you borrow me that car? It's a Toyota Igo you can have it everywhere Wow that shouldn't be All right, we have a question at microphone number eight, please. Hi. Thank you for your talk first of all Well, if I understood correctly you said that the vendors didn't mention if they fixed it or not or you don't know if they fixed it Yeah, so it depends or I know like so if you look into the Android security updates so for example August 5th has some Broadcom issue that was fixed and I know which one that was and so on and so forth but So then it also means like to get that one onto a Samsung device I would need so they wouldn't build it in the August update But only in the September update and then release it to Europe which is like Mid or end of September and then I could download it to my phone and test it over the air if it's like really fixed and so on and so forth so it's Um There is like The first thing is like that is listed publicly that it is fixed and then the next thing is that it is actually fixed and it's Really hard and for the communication with Apple. I don't know so sometimes they fix it silently without mentioning us And then there's this iOS 13 thing where they Mentioned us but didn't fix it. So yeah Were there any issues like that you found and you didn't know if they fixed it or not And you did and you did like petrifying or something like this Yeah, I did a lot of petrifying and I currently have a student who is doing nothing else than Developing the thing tools for the particular issues that I have And did you find that they fix it or not? So it's first of all so we are so first of all it's currently about speed and stuff and I gave him some Some iPhone stuff for the next task, but yes, it's work in progress. So most of the other stuff I did by hand So I also have a good idea about like what changed within each kind of chip generation Okay, thank you very much. All right. We had another question from the internet Yes, so from Macedon. How exactly was the snapshot of the Samsung Bluetooth stack extracted for the fuzzing process? the Samsung is so for Samsung we have snapshotting but for Samsung we don't have Did the rest of Frankenstein the other stuff is running on an evaluation board So the first part is mapping all the hardware registers So this is the first trip that runs and tries to find like all the memory regions and once that is done There is a snapshot it shutting hook that you set to the function So let's say you want to look into device scanning So you would set a function into device scanning and once that is called by the linux deck You would freeze the whole chip and disable like other interrupt stuff Whatever that would kill it otherwise and then copy everything that is in the registers So that is kind of the snapshotting and once you have a snapshot then you can try to find everything that Kills your emulation like interrupts again and threads switches and so on All right, we have one more question from microphone number one, please Okay, so Do you think that open source the driver or that open hardware design would improve the situation? So open source I think it would improve the situation But also one thing so I had a talk at MRM CD in September this year Another thing which is not about open source is that the patching capabilities of the Broadcom Bluetooth chips are very limited In terms of how much can be fixed So this so just open sourcing wouldn't have Broadcom for example like you mean the Like the firmware is burnt into the ship and and it's it's limited to be Yeah, so it's limited, right? Yeah, so it's in the ROM and then you have patreon slots and you have like 128 petrom slot and each petrom slot is a four byte override breakpoint thingy that branches then somebody else into rum And then rum is also limited so you couldn't like branch into large chunks of rum all the time Yeah, okay. Thank you All right, if they are not any more questions Internet internet. Oh more internet questions then please go ahead. Yes So Winfreak on Twitter asks what stack was tested when mentioning Android there's several and Google is convinced revising it every year is a good idea Yeah, so this stuff. That's like The standard state that runs on the Samsung phone for example So I think like for the main Android there's only one I know that there is like legacy stacks, but they switched to only one Yeah, so signal Angel do you have more for us? Yes What is your head made of my head? So it's Like aluminium foil and then there is the cyber Cyber thingy. So that's also important. Yeah So but as I said, it doesn't really help it would more help to put the smartphone in a blender for example All right. Thank you very much for this awesome talk. Give a huge round of applause to Yiska