 So, as you may have guessed by now, this is real-time Bluetooth detection using Blue Hydra. It feels very real-time, doesn't it? We're going to go a little faster than we planned, so we're going to jump ahead here. Oh. Try to page up and down. Alright, I'm Granilox. I work at Pony Express. I've been there for about as long as Pony Express has existed, and I primarily focus on device detection, looking at different kinds of devices that we see in the environments that we're monitoring for people. That's how I got involved with this project, with this Mr. The Plague looking guy here. So we saw that we needed to see more Bluetooth devices because we were barely seeing anything that was out there in the world, and this is how this came about. Woo! I'm a very calm zero chaos. A lot of you might know me. I do wireless stuff, and please stop calling Wi-Fi wireless. Those are not the same things. I don't like anything that you're not touching because it's way cooler to hack things that you didn't touch. Wire is boring, and wireless stuff is fun, whether it's ham radio, or Bluetooth, or Wi-Fi, or whatever. So free plug for the wireless village. Come by SkyView 1, 26th floor of the other tower, and hang out with us and do some real wireless stuff. So what is Bluetooth? Bluetooth is cheap. It's meant to replace the cables that fail us horribly while we're trying to give our presentation at DEFCON. But that's really what it's for. It's not for high bandwidth applications. It's not intended for that originally. It's just intended to replace the cables so you don't have to plug in your keyboard or possibly your monitor or possibly, I don't know, I guess your cell phone. It's not meant for much, right? What it does is frequency hopping spread spectrum. It hops 800 times a second to try to get away from interference and to not interfere so much with other devices. So you're actually going to be hopping constantly all over the spectrum, which as you might imagine makes monitoring it a lot harder. And that's really why there's no monitor mode on these pieces of hardware is it's very difficult to monitor this in the first place. And the target price of Bluetooth radio is about five cents and none of its normal operation requires that kind of monitor mode, so why would you ever do that? Increasing component cost is just not something that's typically done for fun, so they didn't do it. So no monitor mode means sad facing. Now, Bluetooth is divided up into three basic classes. Class one is the 100 milliwatt, which is about 100 meters is what they expect the distance to be in Fantasyland. Those are high-powered devices, the synodongles that Pony Express likes to use. They're really nice to have. If you actually expect a class one to go 100 meters you might be on another planet, but class two is what you normally run into. It's your Bluetooth on your cell phone, your headset, your laptop. Those are 10 meters, which 30 feet away for something meant to connect your keyboard is pretty good. That's not really a problem for what you're doing from my pocket to my earpiece is only about 2.5 feet. Sicilian is the best we could do. It's a little farther for him, but still well within 30 feet. It's not really a big deal to have low-power Bluetooth. If you get a really bad one, that's called class three. That's one milliwatt, and that's why sometimes you buy the really cheap Bluetooth headset, or it was really expensive, but it was made really cheap from your pocket to your ears, not all that possible, because it's actually only going to go about a meter and you're basically matching it out if you're a six-foot-tall person. This is what Bluetooth looks like on a spectrum. We've got the really pretty 3D waterfall that honestly, if I could put this as a video, it looks so much cooler, but since I can't do a live demo I'll just go ahead and be happy that I've got this at all. This is a standard FastPrior Transform waterfall display. You can see all those little blips are Bluetooth. This was actually us rocking out in the wireless village setting stuff up last night. This is high-band with audio. This is very high-quality, as you can see, very little actual data is being sent. On a network where you would have a large Wi-Fi network possibly right in the middle of this, you'd actually see all the Bluetooth go below and above using what's called adaptive frequency hopping. It's basically just going to avoid interfering with the Wi-Fi and avoid being interfered with by the Wi-Fi. And that's really a function of just get out of the way because you're the lower bandwidth guy and it's easier. But again, that makes it a lot harder to sniff Bluetooth directly, and that's why those radios just don't have those kinds of functionalities. Bluetooth Classic, this is the stuff that you all know and love, you probably are using every day, headsets, things like that. The security for this stuff is really, really simple. It works on a process called discoverable or not discoverable. If it's not discoverable, that's the mode it's supposed to be in all the time. It's supposed to be just not visible to the outside world as it were. It's supposed to be already configured, already did the key exchange. People compare everything to Wi-Fi. I can't count the number of times I've walked in for Wi-Max recommendations or Bluetooth recommendations. And it was a set of Wi-Fi recommendations where they did a search and replace and changed Wi-Fi to Zigbee or something stupid like that. And it's like, no, no, no. That's not how this works. Bluetooth, when you disconnect, doesn't actually terminate the authentication. The key material is saved on both ends. Those are kept. You don't have to re-authenticate. This is why you don't have to type the pin in every time you use every piece of your Bluetooth hardware, right? The pairing is part of you turn into discoverable mode, you find the device, then you pair to it. And kind of like a marriage, you can let people know that you're married, but the pairing, you kind of should be doing in secret, right? You don't want people to be observing that key material because that's all of your security right there. For a really great primer on how that works, Mike Ryan gave a talk at ShmootCon a couple of years ago. I highly recommend it. It was called How Smart Is Bluetooth Smart, but it goes over how all the pairing and stuff works. And it's really eye-opening to know that if you're not pairing in a fair day cage, you probably should start. But Bluetooth Classic is all of the security is based around pairing in secret. And if you are not paired to a device, it's a lot harder to find it. And we'll get into how we do that, and it's fun. Bluetooth Low Energy, there's probably way too many of you that have this on in the room. All of you with a Fitbit or a Smart Watch or a salt card to authenticate to your cell phone for you. These Bluetooth Low Energy devices are the really popular stuff now. And that's kind of why we ended up writing this tool. The Bluetooth stuff has been exploding, and we couldn't see it. And that was really terrifying for us. And when we started building this and seeing just how much was out there, it became a much bigger priority to work on this because we thought it was cool. So Bluetooth Low Energy, unlike Bluetooth Classic, has three discoverability settings. General discoverability, limited discoverability, and nondiscoverable. What's funny is it really doesn't matter because the way this works is you send out an advertisement and you say, hey, I'm invisible. And you send it out about four times a second. Hey, I'm invisible, hey, I'm invisible, hey, I'm invisible, hey, I'm invisible, and the way the spec is written, you drop those packets. That's what you're supposed to do. I'm glad you all feel the same as me about how great that is. Some devices don't advertise. If you're wearing a Fitbit, you don't own one of them. If you're wearing pretty much any of the fitness bands, fitness trackers, most of them just don't do it. The more high-end devices, a lot of the smartwatches, they don't advertise unless you go to the settings menu and market discoverable and that kind of stuff. They're actually half-decent, but we still do see them quite a bit because sometimes it loses the connection to the phone, decides it needs to advertise the phone, can find it again, and things like that. So Bluetooth proliferation, there's a whole bunch of random IOT, IOT, IOT, IOT, IOT, IOT, IOT, IOT. Are you all drunk yet? Good. Okay, that's enough of that garbage. Wearable stuff all around you. Bluetooth low energy, which was also called Bluetooth smart. Although it is not actually lower power transmit and receive, it's designed to be lower power consumption. It's trying to do deep sleep cycles and things like that to avoid burning all that power. So all of the wearable devices, the smartwatches, the fitness trackers, they try to do that. So here's just a really quick, terrifying set of numbers. Fitbit last year sold 21 million devices. Xiaomi did 12 million. Apple did 11.6. I'm reading all three of those while I eyeball my cohort just so he knows that Apple's in third behind China. Anyway, point is, total 78.1 million wearable Bluetooth low energy pieces of unsecure garbage, mostly. It's terrifying, right? We have all of these devices with us all the time. I'm wearing three of them. Try to count them while I'm standing here. But seriously, we have so much of this and we're not looking for it. Interesting if nothing more than that, but you can get a lot of fun info from it. So I think it's even more interesting. Prior art, I'm going to gloss over pretty quick so I'd like to get more time to my cohort, but we looked at a bunch of Bluetooth tools that existed. Red Fang is a Bluetooth discovery that does brute forcing at MAC addresses. Hey, it's not discoverable. I'm going to ping every MAC address on the planet and try to find it. That's one way to do that. We went with a different way, but that's one way to do that. BT Crack and Crackle are pincrackers. Those are trying to break the authentication between the devices. And then Blue Snarfer is an older tool meant for dumping phone books and SMS messages off of phones. None of this was in our interest. What we were trying to do is discover the devices were in the area, fingerprint them, track them, see when they show up, when they leave, have the ability to find them physically and meet space. And that's really what was interesting to us. So like all this stuff existed, only Crackle really worked on Bluetooth Low Energy stuff and none of it was really all that interesting to us. Bluetooth Discovery, Blue Log is a great tool, but it was written back when there wasn't Bluetooth Low Energy, so it doesn't support Bluetooth Low Energy. So it spams out a bunch of really useful logs constantly at a terrifying rate and we didn't find it all that useful. BT Scanner was an absolutely beautiful app, kind of like Kismet, but for Bluetooth it worked really well unless you pressed any key and then it would crash. It's been unmaintained. It's not their fault. It's been unmaintained since about 2003 as far as I can tell. So no LE support on that either because there was no such thing as LE. And it had a really neat GUI and we really liked it and maybe if either of us could code in C we would have picked it up and started working on it, but as it turns out, I shouldn't program and he's better? Arguably. Arguably better. Useful stuff. As it turns out, if you're going to stand on the shoulders of giants and you're working on Bluetooth, the Blues team is probably a hardy good place to start. So Blues is the library for Linux that runs all the Bluetooth stack and they not only have a functional library and workable tools, they have documentation and examples and unit tests that work 60, 70% of the time. So it's really, really good stuff. I'd like to thank them for that and there's a thanks for it later but really thank you. So HCI Config is the main controller, brings the card up, down, resets it when it goes out to lunch which is pretty often because it's 5 cent hardware. I mean they charge you a lot more for it but that plastic got to be really expensive because the chip sure ain't. HCI Tool is going to discover your classic devices. HCI Tool scan, we'll look for classic devices in discover mode. HCI Tool less scan, LE scan as we were calling it internally, works but it's really hard to parse and when I told the Blues team what I was doing with them, they're like, oh my God, stop. Stop now, never do that again, you're an idiot. And I said, okay cool, but could you elaborate? They're like, oh, all those tools are completely out of date, un-maintained and probably will crash your kernel. Oh, thanks. So they told me about their test scripts and some of their documentation and we moved on to the test scripts which was Blues' test discovery which was a thing that they did in Python that shows how to use the D-Bus interface and a bunch of internal libraries to actually do proper detection that doesn't crash your system. The Bluetooth dongle still crashes relentlessly but the kernel doesn't and that's definitely an improvement for those of you who have never crashed your kernel while giving a presentation. So the problem is of course seeing that the Blues team writes the main libraries for Linux, it hides some LE devices, the non-discoverable ones, it just goes ahead and throws out the responses and things like that. But what it did for us is it helps us to talk to the Bluetooth card. It taught us how all of that works and we used all of their documentation and their API calls and took their huge bit of code and like ripped out the six lines we needed and said that we modified it. And that taught us how to see discoverable devices. But discoverable devices are only so much of the fun. I mean granted, LE stuff is noisy as sin but we wanted to see other stuff so we fell back to our good friends at the Ubertooth team and they have a lovely piece of hardware. I think it's about a hundred bucks, something like that. You can buy them basically everywhere but Great Scott Gadgets makes a product called the Ubertooth and this is a true Bluetooth basic rate sniffer. It sniffs basic rate and I kind of like to Bluetooth what 80211B is to Wi-Fi. There are faster speeds but somehow people always send stuff at slower speeds so you can see it. They can't sniff Bluetooth EDR which is Bluetooth 2.0 enhanced data rate with these but that hasn't actually been much of a problem for us because everything kind of sends packets at a slower speed at some point fast enough that we feel happy. So Ubertooth scan was the program we were using initially and what it does is it sniffs on one channel and it looks for any devices that are communicating. In Bluetooth you only transmit the lower address part of the master device when you are having a communication and who it's from and to is dependent on the time slot so it's from master to slave from slave to master back and forth and what this allows us to do is we can sniff the lower address part and then you grab some information from the header and you do some math after a couple of packets. You can figure out the upper address part which is enough to ping the device and that's just what Ubertooth scan did is it would then take your Bluetooth dongle and it would query it for a name and information and give you a bunch of information on the device back. Because we had all of the test discovery stuff already and it was working so well we wanted to not have it interrogate the Bluetooth device like that so we talked to the Ubertooth team about this thing on their minds which was Ubertooth-Rx-Z and they gave us that flag where it just does the sniffing part and it doesn't do anything else and then we parse it internally and my friend Grant will explain that right about now okay so I'm actually going to go through and talk about the tool that we made and how it functions we are open sourcing it as part of this and so I'm actually going to talk through the internals of the tool a little bit read through it and look through it and contribute back to it ideally would be great so the primary goal that we had was to create an aerodump-like interface where you can see a live view of Bluetooth devices around you at any given time we also wanted to support Bluetooth low energy because the existing tools that did something like this did none of that and that was a really important thing for us just given how much device proliferation we have been seeing on the low energy side of things and again the second point there that was really the goal but a bigger part of that was to find them as quickly as possible because a lot of the low energy devices are things like mobile or wearable devices that are on people that are moving around or on cars or vehicles or on trolleys with beacons and so they tend to move past you very quickly and if you don't pick them up when they're there you're going to miss them entirely we opted to have a database backend for the purposes of persistency we wanted to be able to turn this thing off and then bring it back up later to the correlate devices that we saw back to what we had previously seen and the database allowed us to do that and another goal going back to the standing on the shoulders of giants is to really minimize the amount of direct hardware interfacing we're actually doing this really let us move a lot faster on the development side of things and it allowed us to kind of keep things as simple as possible and use the tools that exist to reinvent the wheel and we're not at all focused on cracking or brute forcing or attacking Bluetooth tool at least at this time in terms of the design logic it's primarily written in Ruby it's 95% Ruby there's a little bit of bash and a little bit of Python the bash is mainly there to manage the interface and to shell out to run some of the third party tools that we're relying on what are you trying to say as we're sorry in advance and then the Python if you read it, good luck and I'm sorry but the Python side of things is just the test discovery script using the Pi Blues library that Rick mentioned so we built it on top of these existing tools as much as possible this helped us develop very rapidly and we modified the tools as we needed but again to minimize the use of hardware we entirely relied on them where we could so at a high level what we do is we have a number of discrete threads like Ruby threads running in the background which are doing each of our different tasks and then everything gets boiled down into a single data processing thread for the database we did use SQLite initially and SQLite but anyone's ever used it which I'm sure you have is kind of trash it worked for our purposes but one of the problems with it is it's extremely blocking and so if you try to access it from multiple threads you're going to end up with a ton of right lock contention and everything's going to fall over so we ended up boiling everything down into a single thread for processing the data which ultimately served us pretty well for reasons I'll probably explain if I have time before we get into the threads I think the tool that we need to talk about is BTmon it's also part of the Blues library and this is a tool which is the whole Blue Hydra suite is dependent upon and so there is no true monitor mode which is say like monitoring RF for Bluetooth like we might have with Wi-Fi but what it does is it monitors the interactions between the operating system and the adapter, the Bluetooth adapter so as commands get sent to the adapter or the adapter receives packets BTmon is able to summarize those messages into basically a long stream of whatever the heck's going through the adapter and we use that as our primary point of contact for getting data out of the interface it's reasonably parsable it is text output and so it's a little funky and I'll show you the output in a second here but it wasn't too bad to handle the parsing one of the things that's really powerful about using BTmon like this is we were able to throw all kinds of different commands such as what Rich Zero mentioned nice catch there you know we could run the HCI tool commands or the L2P commands and they are the test discovery as well and all of that would come streaming out of BTmon in one place it also supports multiple Bluetooth dongles and right now the actual service isn't supporting multiple devices but we plan to add that in a not too distant future so with BTmon you can see the output here this is a single message coming out of BTmon it's an LE advertising report so this is an LE device advertising its existence a single thread that executes and filters the messages coming out of BTmon and breaks them up we push them over to another thread that basically buffers them by device so we'll see same device, same device, same device different device when we get a new device we flush that out to get parsed and processed and we start buffering the new device that we're seeing data about alright so the next thread that's really significant and this is where a lot of the actual work is done is the main discovery thread which is responsible for running test discovery commands and it also feeds off a number of cues which different parts of the system feed into that tell it who it needs to gather information from who it needs to ping the L2 ping command is very useful for us because it allows us to test if devices are still present even if they've gone out of discoverable mode or even if we never saw them in discoverable mode such as with an uber tooth it's also responsible mainly for the info gathering and the test discovery script devices as well as the le advertisements nothing, none of the commands that get run in this thread we do anything with it's just all coming out of BTmon on the other side of things we do do error handling here so you'll see a lot of error handling if you start reading this code but that's just to make sure we do some error handling here and that's mainly where we're error handling so if something goes wrong with the card or any of the commands we'll catch it here and handle it here so the uber tooth thread also exists we have an uber tooth device plugged in and it is completely optional it does not replace having a conventional bluetooth dongle which you absolutely need to run the system, the system still relies on a traditional bluetooth dongle we recommend the Senna dongles that pony express ships and they're quite robust with the uber tooth thread it's running the uber tooth rx command on a slow loop and it bypasses BTmon entirely and ships that information straight into the processing queue so with the data processing thread we can see what we're doing and it's mainly excuse me, it's mainly responsible for updating and creating the records and sort of tracking what devices we've seen but it also operates as a feedback loop to the rest of the system populating the queues to say you need to test this device you need to see if this is still present and this allows the discovery thread to do what it needs to do to kind of see and gather the information as quickly as we can to gather info about devices before they pass out of our range so one of the problems we found here was the actual device correlation of bluetooth devices so we assumed initially and pretty naively that we'd just be able to see MAC addresses and say okay this is the same MAC address that we saw previously it's the same device that falls over pretty quickly initially it falls over with the uber tooth because the uber tooth will only see the upper and lower address part which is the last four octets of the MAC address so in the example here you can see a device with a physical address something beef cafe and have no sense of the vendor if you want to do an OUI look if you wouldn't be able to do it off this alone and we're never able to get the rest of that address the complete address with an uber tooth so we are able to however zero pad it or pad it with any arbitrary hex and send it back out and ping those devices and they will respond to their upper and lower the UAP LAP upper and lower address parts and the non-significant address part which is the first two octets is totally irrelevant except we're doing vendor lookups and we can see that device come into discoverable mode and we see its full address we're able to backfill and kind of fill in fill in the addresses that we didn't see which we initially saw with an uber tooth another type of device correlation we're able to do and here is iBeacons iBeacons are capable of rolling their MACs very aggressively they change their address quickly and they don't always do this but they can do this and so we're not able to consistently rely on looking it up by the address so we were able to carve out some information out of each one specifically the proximity ID and minor numbers which we were fairly consistently able to track iBeacons even as they rolled their MACs and moved around the space so the last thread that's kind of worth mentioning and this would be our demo although I don't know we're probably not going to have a demo because of this because of screenshots is the sui thread and it's the command line user interface which is to say it's the aerodump style output which shows you thank you which is really a live table of the devices that you're seeing around you at any given time so it's simple it's not curses or anything but it is sortable columns and you can kind of add and remove columns as you need to get the information that you care about for the devices so that's the main bulk of the internals of the tool and we were going to go I think next to a demo and we're going to do it live yeah let's do it dead yeah so I want to apologize because after going through six laptops we finally got something that works and I'm not unplugging it right now to see if we fixed the wire or all five laptops before this one didn't work we're going to after everything else so I'll switch back and forth and break it again so I'll show you the screenshots and if we're really lucky I'll switch to a live demo afterwards this is sui, what it is basically is as granola said it's roughly an aerodump style interface we've got the address the version what version including like 4.2 will actually show up here on the devices to tell us the rssi names manufacturer is an overloaded field so we grab a bunch of different information from different places in the bluetooth stack and we kind of put the best thing in that spot and then range is an ibeacon specific thing the ibeacons actually give you a calibrated effect the signal strength to be at a meter away so you can use that to magically estimate the distance very very reliably so as you can see these were all sitting on top of the bluetooth dongle when we tested this this interface is pretty simple and if I'm lucky I'll get to show you but you can see this little carrot right here this is indicating that this is sorting ascending it can also sort descending you can reverse the sort of thing as you can change which column it is sorting by you can also change which columns are available so this is the default view of columns manufacturer and range being the two interesting ones this is the ibeacon specific columns where we add in the proximity uid the major number and the minor number these are the things that make ibeacons unique so its proximity is basically the company and then major is like it's in this store number and then the minor is like this is in the fruit stand so that when you walk up to the fruit stand you've got the grocery store app on your phone and it says oh dollar off bruised apples or whatever it is this is the company display information I find that a lot of stuff has interesting things in the company and company data field and so we added that as a secondary display while debugging some stuff and left it in there because we thought it was useful so you can change the column sets you can change the sort you can change up or down on the sort as well and I think it's worth noting and we may or may not be able to show this given the functioning of the demo but this is a fraction of the data we're actually gathering about these devices there's a ton more information being stored in the database this is what we consider to be the most useful immediate information when you're looking at a live view but if you go back and pull data out of the database there's a massive amount of information about these devices so where do I get it on github pony express slash blue underscore hydra because go blue hydra hail blue hydra you can download it there's a list of depths in the read me and then you can run it straight from the get checkout and there's no problems with doing that because shocker that's how we developed it it does run on Cali because we developed it specifically to run on Cali Linux which is what the pony express sensors run that said they haven't packaged it yet so you just have to install the dependencies and all that stuff manually or especially if you're competing in the wireless catch the flag this weekend you can just download pens who's latest release and it's already on there and gosh I developed blue hydra I added it to my distro I wonder if there could possibly be any contest around needing it desperately could you track somebody with this tool that's a very good question sir shut up questions are later I mean yes yes thank you for your question sir so our conclusions were basically we found a lot of old bluetooth stuff because when bluetooth came out it was really cool to hack bluetooth and then apparently it wasn't cool anymore but somehow it became cool to have nine bluetooth low energy devices on your person at all times so we thought it would be cool to look at bluetooth again it was a really simple idea that had gave very mad at me for a very long time because it turns out it was hey there you go granolox it was harder to do than expected and so we both suck at programming but he sucks a little less than I did so a surprise is he just so many devices were out there I can't count the number of places I went like hacker conventions where I just saw hundreds of devices inside of one room and wonder why just why so I'd like to thank Defcon for telling me that the projector was VGA and then providing HDMI that doesn't work I'd like to thank the CFP selection crew you know who you are for letting us present we really do appreciate that because we think this is really cool and we really hope that you do too we'd like to thank Pony Express for paying us to build this and then letting us convince them to open source it and just open source it but put a BSD license on it coconut the card for helping us release this code as BSD our boss got a new hacker name and that's what it is so yeah if any of you ever see the VP of Engineering you can call on that and don't tell me don't blame me the over two team for being awesome not only did they implement a new feature for us but they told us how a bunch of stuff worked and helped us a lot and the Blues team for their very efficient German making fun of us which helped us to do what we needed to do that was really really great of them so Q&A will be in room the bar at the bottom of the escalators there are other people that will be taking over this place in about 8 minutes and that leaves me for yelled out question and answers while I try to get a cool demo running for those of you that prepped funny bluetooth device names don't feel like you got cheated