Hello. I am Grant Bugher I'm giving my talk on detecting Bluetooth surveillance systems.
First, start off a bit about myself. I do work in security. But I don't work in anything
that has anything to do with blue tooth surveillance system or traffic control or anything
of the sort. So, this is my own research and has nothing to do with my employer or their
opinions. This is really a little project that came about from reading a news story, it
was -- I saw something mentioned little white boxes by the sides of the highway and people
wondering what they were. Someone pointed out, they're Bluetooth sensors. Well, that's
an interesting idea, why would there be Bluetooth sensors on the highway? I think why this is
in why in DC101 this is a story of how do you go from I read something interesting in the
news to, well let's just build something and find out what it's doing. Just put something
together and see what happens. So what I did at first was just start, look around, look at the
literature see what is out there about why would there be Bluetooth sensors on the
highways? And well, here are a couple of slides from the federal highway administration,
this is from the Wisconsin DOT, showing a Department of Transportation Bluetooth sensor.
You got a field device with a Bluetooth scanner, it's a standard commodity Bluetooth,
not anything special. It's hooked up -- hooked up to a database server then it detects
the Bluetooth enabled devices in your car, whether that's your cell phone, the hands-free
function of your car, Bluetooth headset you're carrying with you, whatever else. And it
relays that back to the database server. As you see in that second slide over there, the
purpose of this is you detect Bluetooth at one known location you detect the same hack again
at another location now you know the speed of traffic between those locations because you know
how far apart they are you know the time delay between the mac addresses. That's why the DOT
started putting these out there. And they're everywhere. Here we have example of a little white
box being installed alongside the interstate, you'll see a lot of -- the white box with the
solar panel on top is probably the most common one you'll see but it's far from the only one
you'll see. These are all commercially available highway Bluetooth scanners. And some of
them are remarkably commercial. If you go to like traffic casts sites there are pamphlets, buy
our Bluetooth scanners and put them on your highway and they're advertising to government
departments of transportation. I looked around for some of the research on this and as research
note from the Washington state Department of Transportation. And couple of choice clips from
that is, the key advantages are the cost of the Bluetooth reader and the Mac address collection
device scans multiple lanes, over license plate riders in addition Bluetooth based data
time are easy to install, goes on to also talk about users not wishing to disclose their
location can simply turn off the broadcast function on their Mac devices. We also have the state
installing down at the joint base, Lewis-McChord, which is an Army base, a military base south
of Seattle installing these sensors in place. So, why would they use Bluetooth of all
things? It turns out there are variety of reasons. There are a lot of things they can use to
monitor traffic, the most basic is the loop, you see them in front of every traffic light.
There's a little circle on the ground, and it detects from impedance when your car goes
over it, the engine block changes the magnetic field. We also saw in a presentation by
Cesar Cerudo a few days ago, they also use magnetometers. It's the same idea. but they
only tell you traffic volume. They also use radar, which can tell you traffic volume and
speed. But Bluetooth is one better because it provides route choice. I can be for an
intersection, put a Bluetooth scanner there, and when someone drives by it I gather their mac.
I know which way they went since by having other sensors in the intersection. That is why the
DOT likes Bluetooth scanners. The only other thing that will give them that are automated
license plate readers, which are comparatively more expensive and honestly have even more privacy
implications than the Bluetooth scanner does. The Bluetooth scanners are less expensive, two
to five thousand dollars each at and honestly the manufacturers are making a fortune at those
prices. They are commodity hardware. They have a cellular modem, solar power with a
battery backup, or some of them get power over Ethernet. They only get a 3-6% sample rate.
Which on one hand, obviously, not everyone has Bluetooth. But that honestly seems a little low
and we'll get in to why they're not getting most of the sample, is that go by. Another thing the
vendors point out that trucks are going to be over sampled because trucks have lot more --
much higher percentage of trucks have Bluetooth devices in them than the percentage of cars
does. You have to adjust for that if you're a DOT and tracking people, need to know
that if I see X number of cars and my road gets a lot of trucks, I don't really have as
many cars as I do if I'm on a road that isn't a trucking route. They do that adjustment.
Another advantage they point out a lot is fewer privacy concerns. So, Bluetooth is a weird
protocol. And it's a weird protocol because as a frequency-hopping
spread-spectrum pattern based on the Mac address of devices communicating -- so it's
actually pretty hard to sniff traditional Bluetooth one and two. VTLE is very different and
really easy to sniff it. You need to know the addresses so the devices communicating.
Bluetooth address is 48 bits like normal Mac address but divided in to parts. There's a
non-significant address part which is manufacturer I.D., the upper address part which is
eight bits. And the lower address part is 24 bits. You get LA in every single bit of
traffic it's easy to get that. If you want UAP you have to capture a lot of packets and
calculate it. It's not hard. But it takes a lot of packets. And any device can also send an
inquiry, a special packet that always comes from a Mac address called the generic inquire
access code. That is 98B3316 no idea why they picked that, that is Mac address that says this
isn't really my address but I'm asking, is anyone willing to beacon with me? Once you get a
response to a beacon you can make a connection attempt. The connection attempt will give you
the device name, the device class, the service list, the clock offset, the rest of the
stuff you need to actually form a connection and negotiate encryption and pair with the
device. Turns out the highway scanners don't really care about much of any of that stuff. All
they really want is LAP: they want an address, a unique I.D. think don't care what data is
being sent -- they completely ignore the data. As a result they can sniff data in a few
different ways. One is inquiry-based tracking. Which is . . . they set up a scanner to
just spam inquiries all the time. They tell every device, hey, I want to pair with you.
Any device that is in discoverable mode will respond that will give them their --
their LAP. Another method connection-based tracking. This is the scanner, it keeps paging
for asynchronous connection link and logical link and adaptation protocol connections. This is
really good if you already know somebody's Mac, this is the scanner would you use if you
want to track company cars around or track individuals through your building that are
your employees. But it's not very useful for general surveillance. Finally there is
passive sniffing where you just sweep the Bluetooth frequency range, you suck up packets and
you don't ever try to respond to any of them. The problem with passive sniffing it requires
non-standard hardware, you can't do it with commodity Bluetooth dongle or your laptop. That may
be a disadvantage for the DOTs. Here we have couple more slides, this is from University of
Washington Star lab. They are a traffic research area. And they installed on highway 520's
bridge in Seattle, an automated license plate reader as well as couple of Bluetooth scanners to
compare the efficacy of the systems. We have over here a graph, they monitored the
Bluetooth devices and they got certain percentage, Nokia, SG, but we also have Tom-Tom and
those are not phones, they are equipment in people's cars. It's their hands free headsets and
that sort of thing. So, what about those privacy concerns that came up a little earlier
that they said are minimized? Here is an article from "Traffic Technology International", yes,
that is actually a magazine. I imagine it's not very interesting to most of us but
somebody subscribes to "Traffic Technology International" and they talk about -- they have
seen -- gains and matches 50% over other methods with patent pending methods which allow for
far more robust analysis capability including potentially differentiating transit
vehicles. They say, we have the capability to make the Mac address data collected anonymous
before transmitting from the field which we can do without any reduction in the fidelity of
the data. But isn't it anonymity a major feature of Bluetooth? Mac addresses are not linked to
a user, why the extra process? They sound really good here. If there is even a very small
chance that a hacker could sniff the communications pathway from field to host, there should be
procedures and protocols in place to minimize the threat. Okay, so they kind of care about
privacy. Here we have from a Star Lab paper, and they have an illustration there gathering
couple of Macs from sensors, calculating travel time, strip the macs, filter the results.
What they talk about up here is the Macs are kept for unspecified period, typically 60
minutes, that's what they say in their document. Now this was from the experiment on 520
affordable license reader, that sort of thing. Most of the commercial sensors I've looked
at actually say they only keep the data 20 minutes. Although it is user serviceable -- because
once again they're going after route choice. If you really wanted to put the sensors 50
miles apart, you could do that then you would need to keep your Mac addresses for a longer
period of time to be able to get the route choice down. So, it's configurable. But the Macs are
anonymous they throw them away after a short time -- clearly there are no privacy concerns.
[Laughter.] Or so, that's what they say. For instance, we shouldn't care that they're
putting these on the Canadian border at all of the border crossings to monitor things. I
bet they have them on other borders, too. Canada just happens to be heck of a lot
closer to where I live. This is what I was able to find out. Again, these are from UW Star
Lab. There are the three privacy mitigations. One is they're capturing LAP only, they are not
getting your entire Bluetooth address, not cracking your code, they are not pulling your data.
They don't compare that, they don't make any is attempt to sense that. With Bluetooth being
frequency hopping spread spectrum, with only passive sniffing they are only getting
one packet in 64 anyway without cracking your UAP -- not really cracking, guessing the UAP and
pairing with you or making connection attempts they can't follow your communication. They
can't get most of the packets without doing a lot of stuff that the DOT has no reason to
do. LAP is 24 bits, it is not globally unique. There are many Bluetooth devices with the same
LAP, there are only 16.7 million possible LAPs. Next thing, they anonymize it. Remember that
little article in Traffic Technology International, they say that LAP is anonymized while
preserving the fidelity of the data. So, the anonymous LAP matches one to one with a
non-anonymous LAP. They hash it before storing, and if they wanted to they could use salt
hash 256. They can use good hashing practices. Then finally their last mitigation is limited
retention. And star lab said, 60 minutes commercial reader, say 20 minutes default time --
that's usually plenty because they will put it before an intersection, after an
intersection, so be it. That is all they need. Let's take a look at each of those privacy
mitigations. Remember this? That little illustration of the manufacturers? Well, the
manufacturers comes from NAP not from LAP so LAP does not permit manufacturer identification. So
clearly at least in their experimental reader deployment they might have a little more
than LAP captioned. And -- not globally unique, one in 16.7 million is pretty unique for me
in Seattle. There's one of me, there's maybe 2.5 million in the Seattle metro area. There is
only a 1 in 8 chance I match anybody. I have more than one Bluetooth device. At that point
you've got a pretty unique signature of yourself. Now once again they're right that there
is no -- there is no central registry of Bluetooth Mac addresses, at least not that we
know of. And you can't necessarily get at somebody's Bluetooth Mac look at DMV
database see where they are. On the other hand what it does mean is the state would be useful for
targeting tracking of a person if you know there was a person you can't to track around town
you do some research in other ways, you get -- brought a shot of liquor -- [Applause] Just a
moment! (Speaking off-mic). [ laughter ] All right. (Speaking off-mic). >> Some love for the
new speaker! [Applause] All right. Back to tracking people or not tracking them. So. All
right! [laughter ] (Speaking off-mic). So, yes, one in 16.7 million pretty unique in most
areas, there is no central registry. But if you're already suspecting someone, say you are
the FBI or something of that accord -- you can probably subpoena their cell phone
provider, and get their INEI and the phone manufacturer knows the serial number that goes with
that INEI. The phone manufacturer knows the Bluetooth Mac that was put in by default
on that phone. So if you are really tracking one person as a targeted attack, LAP is good
enough. If you are trying to do dragnet surveillance, LAP is kind of useless. So anybody
remember this? This is an interesting story. It's kind of unrelated but not really. They
talk about anonymizing your LAP. This is from 2004. This is the source code for the
deck-shuffling algorithm on PartyPoker.com. They put this out to show how secure their
deck shuffling algorithm is. On the surface, it looks very fair. You are taking each card in the
entire deck, and you are randomly swapping it with another card. And you go through
the entire deck this way. That gives you 52 factorial possible combinations. Full deck shuffle,
225 bits of entropy. But wait they're using the random function in Pascal, and random
generates a 32-bit number. So, there is only 32 bits of entropy going in to their 225 bits of
entropy. They ceded it by calling it randomized. Randomized, it's the number of
milliseconds since midnight, but that is only a 26 bit number. So really 26 bits of entropy. So
even though they're shuffling the deck perfectly there are only 68 million possible decks
this algorithm can output. Somebody made a card shuffling rainbow table where they
generated all 68 million possible decks. They get dealt their own cards say this was the
first and second card out of the deck, how many of those 68 million start with these two
cards. The plot comes out, how many have those halls cards 9, 10, 11, then they are down to
one deck and predict the rest of the deck. So, the moral of the story is, you cannot anonymize a
24-bit number. You can't take a 24 bit number and turn it into 256 bit salted hash. Someone can
try all those 24 bit number numbers. They'll hit it. It's trivial to force a brute number
that size on modern computing hardware. So that leaves us with one last bit of protection. That
is, well, they throw the data away, they only keep it for 20 minutes. The DOT collects it,
they collect the data, to see route choice, speed, and traffic volume. They don't care who you
are, they're not trying to track you. And then they get rid of the data. They're not sharing it
with intelligence agencies and public institutions and so on. They really have no reason to,
they don't want this other data. So anybody remember this? This is Edward Snowden's slide,
you'll note the smiley face by SSL added in here of the muscular project where in the
data is encrypted to Google's front end but then moving from datacenter to datacenter it's in
clear text, and the NSA just tapped their lines. And we have the same thing. The DOT may be
throwing your data away after twenty minutes. is everybody throwing your data away after 20
minutes? We can't really know if this data is stored with or without the cooperation of the
DOT. Once again, it is mitigation, I'm glad they're throwing the data away after 20
minutes, it's nice of them. But all of these are a bit limited in terms of how well they
actually protect your privacy. It is creating a nearly nationwide tracking system. Now
I will give them one thing, the alternative to this is usually automated license plate readers,
and those are much worse. They get way better than three to six percent car identification. And
your license plate does map one to one to you and it clearly available database that any
police agency can access. So if the choice is Bluetooth scanners or putting ALPRs everywhere?
Okay, yeah, they're right. There's no privacy concerns at least relatively speaking. On
the other hand ALPRs cost five times as much. Thus, they are less inclined to put them
everywhere. Bluetooth scanners are pretty cheap. They're easy for them to deploy, so they're
quite widely deployed. So this is what I could find out from reading literature but it turns
out you can't just Google, "where are the Bluetooth scanners in my city?" So that
data is not really made public. So I thought, well, why don't I make a Bluetooth detector
detector? And so I went on to making my own. And with Bluetooth scanning, first you
have to get some equipment. Bluetooth transceivers, the typical dongle that you can buy
anywhere can send and receive, but can only send beacons or send when they're paired. They
don't have basically packet like you call on Wi-Fi cards. Class one 100 meter range don't see a
lot of those. Class two and three are ten and one meter. Also commercial Bluetooth
sniffers. These things are $10,000 plus. They will grab all channels, they will receive one,
they don't transmit. They are still single or dual or sweep, they won't grab all 64 channels
they just swap between them. Until you tell them, "I am interested in this Bluetooth
device" -- then they will lock on and frequency hop with it. But I didn't want to spend
$10,000 own commercial Bluetooth sniffer. Luckily there is this lovely thing that you can buy
these down in the vendor area. This is the uber tooth one it's a non-commercial Bluetooth
scanner. It has all the capabilities I or Department of Transportation would need to
sniff up at least Bluetooth Macs. 2.4 gigahertz, transmit and receive, transmit power and
receive sensitivity comparable to class one Bluetooth, those things have a 100 meter range.
Comes with a nice 9DVI antenna on it. All I needed was a bit of hardware to attach it to. I have
to use Linux, there are no Windows ubertooth drivers. You could use a Linux VM, the
problem is Windows will not pass USB device with no driver to the VM, so you have to get a driver
called WinUSB, which is just a generic Windows USB support. You can associate that driver with
the uber tooth then pass that in to your VM and it works. So, my equipment for this at first was
old ThinkPad in the garage. Alternatively a copy of Ubuntu, an uber tooth one, a global sat
USB-GPS dongle for $27 on Amazon, and an AZIO which is one of those Chinese brands that
doesn't actually exist -- they just slap a random name on products, a USB micro Bluetooth
adapter, also class one, for $16. And so I set up my Linux PC, update it, install with Lib
USB various USB drivers required, blue Z which is a really nice Linux Bluetooth sat.
Download the Pi-USB, the Bluetooth baseband, the uber tooth software, and finally
Kismet although you could install binary Kismet. You wouldn't necessarily build it
all yourself but will have to build the Kismet plug in that associates with uber tooth, so
you might as well download the source, you need it anyway. Install all that. This is older
version of Kismet, it is 2013. The latest released version of kismet is a year and half old.
There are newer ones available on get hub but for stability you're better off with an old
one. Kismet is meant as Wi-Fi scanner -- it will work as Bluetooth scanner but pushing it
out of its element. Anything that stabilizes it is helpful. And, okay, now I have a computer
that can sniff Bluetooth. That was all right. But I didn't really want to drive around with
computer on my dashboard all over the city for hours until the battery ran out and have to
go back and swap another one. So I thought, you know what would cooler if I had this on an
embedded system that I can just stick on the dashboard and plug in to the cigarette lighter and
do it all that way. So, I built an arm-based Bluetooth scanner. Let's show you a bit of that. It
was an inexpensive open source hardware platform, raspberry pie, made for education purposes
which basically shows you here, this is how you play with little embedded systems. It's an arm
processor, it's 35 bucks, probably buy them in the vendor room, too. And got two USB,
HDMI, audio, GPI with SDI capability all sorts of things I don't need for a Bluetooth
scanner. I also went ahead and bought a screen and enclosure for it I didn't want to drive
all over town for five hours, get home, and found I captured no data. I wanted to have a
readout. It's optional. I wouldn't have needed it, it works just fine without it. And
then the equipment from the PC build and -- finally I needed something to power it off of. It
runs on a five volt, 500 milliamp USB power supply. It is meant to plug in to any USB
adapter, a car charger has USB adapter now I can plug it in to my cigarette lighter. Let me
show you what I built here. The problem I have is I cannot see my own screen. So I am going to
show you with my camera here what is built but you will have to tell me if I am not actually
aiming at it. Here is -- is that in focus? Okay. Here is the raspberry pie with display on
it, those are a bunch of Bluetooth Mac addresses and number of packets it is captured
from. I turned this on in speaker room about 45 minutes ago and as you can see there's a
nice long list of Bluetooth Macs that I have captured from friendly DEF CON goers. Over
here is what it is plugged in to, we've got -- is that in focus there? We've got USB hub,
which has on it my GPS dongle which is getting no reception here in the Rio but in theory it
could -- and my uber tooth one. Then finally we have what's powering all of this. This is a
$29 gorilla gadget 16,800 milliamp cell phone re-charger that also worked as USB counter
source. Those altogether give me a less than $200 embedded system for use as a Bluetooth scanner.
All right. Am I back to slides? Setting this up was pretty straight forward. Update the
firm ware, I used the standard raspbiean image. There is a standard image there's actually
available that already has support for the screen if you are using the screen then you
can use that as well. And it recompiles, a bunch of kernel packets are required for
raspberry pie, because repurposes the general purpose IO pins as a high speed bus to
transmit and receive from the screen. Installed the same Bluetooth -- same packages as
before, although a few others are necessary. Actually I don't list it there you also need
build essential, Raspian does not by default include some of the tool change packages you
need to build this. But Apt is pretty friendly about telling you what you're missing.
Download usual software, make an install. One thing is, the raspberry pie is not the fastest
DEF platform out there. Compiling kismet on the pie takes about four and half hours.
As a result, you're going to be doing a lot of experimenting with this, it's probably worth
setting up a Linux box to cross compile going to be a hell of a lot faster. But if you're only
compiling kismet once on the device it's not that big a deal to just let it compile for four
and a half hours. Then I did a little more set up. Putting my user in a plug DEF group setting
up USB to automatically associate the uber tooth with that, so that I can run kismet
in user mode instead of having to run it as a root. I added a new user called scanner, and
that user is in the appropriate groups. I modified a tab to instead of display log in prompt
on TTI one, the console, to automatically log in the scanner user. That way, when I boot up
the pie, it automatically displays the scanner user's console on the screen I don't
have to have plug a keyboard in to it and do any kind of log in. Then set GPSD speed to start up.
This is actually necessary because GPSD on Raspian - there seems to a bug in install
packages. It will not auto start if you do a package re-configure to tell it to auto start, it
writes a bad GPSD config that doesn't actually work. So, I added a GPSD config to make it
work and then finally start up kismet on a computer where you have a keyboard and a screen
because you have to set up the kismet UI the way you like it to look then exit, that will save
all your UI settings to display the uber tooth plug in, and not display the AI211, all the stuff
we're not using, display GPS coordinates that sort of thing. Then finally modify the scanner
user's batch RC to start up kismet as soon as they log in. The screen we saw on the little
scanner a minute ago, that's what it boots to. I just plug in power it immediately starts
running. It worked great to just take it in to my car with car charger drive around town with
it and record logs. When I got home the pie has Ethernet adapter, so I plug it in to a
network and SSH in to it, pull off all the log files. And I pulled off quite a lot of log
files from it. So there were a few issues with raspberry pie. I got that USB hub, even though I
have two devices plugged into it and the pie has two USB ports. Problem is the pie's USB source
only supply 140 milliamps, and that's not really enough to drive uber tooth and Bluetooth
transceiver and a GPS. I needed external power. I grabbed a powered USB hub. Other problem I
had with that is powered USB has to plug in to something. And USB hub normally have a wall wart. I
took the wall wart, took cut that cord, soldered the power cords in the wall cord to the
power pins on the USB cord and then just plug it in to the same car charger as the pie. So I've
got a custom made power cord for the thing. Only other issue I ran into is I cannot solder
worth a damn. I found this out the hard way when putting this together and made plenty of
mistakes with I think that was my second power cable and had to do a lot of desolderring to get
the screen soldered on. But as a result I can solder now. That was an added benefit of this
project. [Laughter.] Even if it took a few extra hours. Finally kismet on -- uber tooth and
kismet on the pie sometimes crashes with this corrupted double link list error. Usually
happens right at start up if it does crash it's fine, you just run kismet again, usually
doesn't crash the second time. If it doesn't crash in the first two minutes it usually doesn't.
I actually wrote a script for that kismet's client and server are started separately and if
the server goes down just cycles it and starts up again and the client reconnects to the server
so that, once again, you don't have to have a keyboard, don't have to have SSHN, The device
just runs autonomously and it recovers from its own faults. I also have been working with
people on Get Hub to try to figure out what exactly this plug is. It doesn't just happen
on Raspian it happens on Cali also, and that's a platform they would like uber tooth to work
properly on. Cali based on Ubuntu, and it works great on 1204 and 1404. And it doesn't
work on Cali, and we don't seem to have figured out why. Thanks to Dominick for his help in
debugging this, even if we have not quite figured how to get it 100% reliable yet. But fault
tolerance script works. I was still able to gather data. You scan with uber tooth scan which
performs an inquiry scan, it sends out beacons. That needs both an uber tooth one and a
Bluetooth transceiver. That will tell us the LAP only, nothing else, or we can use kismet which
will passively monitor all frequencies, it takes only the uber tooth one and it logs GPS
coordinates constantly as well as logging our data packets. So, that's what I used for most of
my data gathering because I need coordinates. I need to know exactly where I observed all
these Bluetooth addresses. It's a continuous sweep, it will miss things because it is only
getting one packet in 64 from each connection. And, if it gets enough packets to guess UAP it
will do so. I have UAP on some of the addresses I captured not others. Um, the amount of time
in inquiry scan it needs to be sure it got everybody is 10.24 seconds. So if I'm going at
highway speeds about 60 miles an hour, that means 268.2 meters of driving in order to be sure I
caught everything around. A class 1 transceiver, 300A, is 100 meters. it should be mostly
enough to get at least the vast majority of the devices. But I have to accept that I'm not
going to get everything unless I drive by over and over and over again. So, then we get to the
results. First of all, after I got all those logs I loaded them in to wire shark in order to
parse the kismet logs, and basically dump everything but the Mac address. I don't care
about the data, I don't need the contents of the packets, all I really want is the Bluetooth
addresses. So dumped all that to a ridiculously massive CSV, was very happy to have excel 2013
because the 32-bit versions of excel would have choked on my 16 gigabyte spread sheet.
[Laughter.] The 64 bit version was not delighted by it, either, but it was able to work with it.
And here we have whole bunch of packets from, you will notice, 98B3316. The generic inquiry
access code. These are beacons that were picked up. Then I mapped them all out on Google
maps. These are areas on the Seattle highways that are showing recurrent inquiry
activity. These are -- I found an emitter of Bluetooth inquiries on every pass of these
locations, implying that there is a stationary Bluetooth source. Now, yes, it could be
somebody semi pulled off the side of the road for five hours. I can't rule out the possibility
that, these are not scanners these are -- happens to be stationary Bluetooth sources
that are trying to pair all the time. It seems maybe a little unlikely, but it is
circumstantial evidence. The other thing is . . . These locations map expected stops for
route source tracking. If you look at where they are -- on a ramp to a highway over in
Redmond, we've got place before the highways diverge on the north side of Seattle, likewise
we've got a couple of places on south side of Seattle just before major intersections of
high traffic. Got couple downtown between I-5 20 and I-90 which are the main thoroughfares
across the grid. They are places I would expect the DOT to want to put scanners. Combined with
that, we got this. That said, there are not as many as I would expect. I probably missed a fair
number of them. I also did not spend all week driving around Seattle. I can probably gather
more if I spent more time gathering data. Well, that tells me with inquiry scans, but what
if they're not doing inquiry scans? What if they're doing other types of Bluetooth scans?
I loaded in the data of all the Mac addresses not just the inquiries and looked for --
what's the first time I spotted this? What's the last time I spotted this? How far apart are
they in hours and if they were more than half hour apart, then -- in the same location, that is
stationary source. I looked all the ones I spotted more than an hour apart from themselves, then
calculated the haversine distance between those locations. Haversine distance is
the distance across the surface of a sphere -- it is the way you calculate distance if you have
GPS coordinates. I found a variety of them that had very small haversine distance and
very large time difference, once again implying a stationary Bluetooth emitter. They tended
to look like this. We had multiple areas where an address was found in less than a 200
meter area on multiple passes around the highways. I'd show you a map of these but honestly
it looks whole lot like the other map did. They were for the most part a subset of the
inquiry stand locations. I saw them at the same places. What this means, I am not sure. They
could be using multiple transceivers, they could be false positives. It's a little
difficult to know what to make of that data. Notably absent, though, there weren't any on
state road 520 bridge which surprises me. We saw on the Star Labs experiments, that's where
they were testing them originally -- in addition the 520 bridge has dynamic speed
limit signs. They are definitely calculating travel times for cars and calculating speed. They
got some sort of traffic monitoring on there. And they've got Bluetooth scanners so I
would think those things would be connected. But despite quite a few passes, I did not find
evidence that that is the case. This said, unlike when they were doing the experiment, the 520
bridge is a toll bridge now. That means people have toll passes, so they may have just
switched to using electronic tolling sensors and abandoned using Bluetooth sensors on that
bridge now that they have got a potentially more reliable and more uniquely identifiable way
of tracking. On the other hand that won't give them route choice, tell them people are
crossing the bridge, won't tell them where they're going afterwards, unless they have put
hidden toll sensors elsewhere that don't charge you a toll. That may get in to paranoia
territory but that's what DEFCON is for. [Laughter.] So. Counter measures. so what do we do about
this or do we need to do anything about it? Well first of all there is going back to
recognizing that if they weren't doing this, they would probably put license plate readers
everywhere and that would be worse. Nevertheless, the main thing you can do is of course
turn off your phone. Unfortunately a little harder to turn off the Bluetooth
transceivers that are built in your car. Depending on the car, sometimes they don't have an
off. They may transmit to anything that transmits to them. Some of them basically beacon
continuously. They are pretty easy to detect. If you want to know you just build one of these
things and you sniff your own car see what you got. You can check your own Bluetooth
emanations. I know I found that my car does not beacon continuously but if it's powered
on or if it has been powered on in the last ten minutes it is sending Bluetooth packets. Now I
have -- I have devices its paired to relatively near it -- I'm not making hands-free call,
I'm not playing Bluetooth radio, the ignition is turned off, I'm not in the car and it's still
exchanging Bluetooth data. These devices are relatively leaky from an information perspective
and there is not a whole lot you can do about that. This said, this kind of leaking requires
passive scanning, not the inquiry scans which are probably what most DOTs are using. If I
look at commercial products that's mostly what they're doing. You read between the
lines of what the capabilities are they talk about only finding discoverable devices. Inquiry
scans only find discoverable devices, passive scans will find all devices. Well, all devices
that are not turned off. The other thing that you can do, you can be someone else. I can run
my sniffer look at all those nice LAPs I got. And if I know who one of them belongs to I can
just -- this sniffer works just as well as a spoofer. As a spoofer, I can plug in a couple
of Bluetooth dongles and then with blue smash tools which are included in backtrack and Cali,
open source security tools, just change my Bluetooth adapters to spoof other Bluetooth Macs of my
choice. Then I pair them off with each other so they will start leaking data everywhere
and drive around and now I can be someone else. If this is being used as a surveillance
system, if they are tracking people this way, I can lay a false trail. With my one device
I can lay a false trail of as many devices as I want. I know somebody has a car has five
Bluetooth devices in it, that's fine, I've got a hub so I can plug in multiple transceivers
and leak all the data I want. You can duplicate multiple addresses with multiple
transceivers. So that's where my current state was. I do have a little bit of follow-up ideas
for what I'm going to do with it next. One is now that I've got these stationary locations, I'm
going to go to them and try to pair with them. If I make a connection attempt and they are
a commodity Bluetooth hardware they should give me their manufacturer and their service
class and all the other data necessary. I don't need to connect to them, but I'm
curious. Because once again if they all have the same manufacturer, that's another
piece of evidence that, yes, these are probably scanners and not just some truck parked by
the side of the highway. So, that is my current state. We have any questions? Yes. >> You
talked about how -- >> The question was, any way to know that they're actually only
collecting 3-6% and not capturing the Dragnet? Truth is they're trying to capture a
dragnet, but that's part of the evidence that they're doing inquiry scans. If you're doing
inquiry scans you only get discoverable devices and most are not discoverable. Also
because of the frequency hopping spectrum you're only getting one packet in 64. That's where that
3-6% comes from. Not that they're trying to do sampling or trying to protect privacy, it's
that the scanning methodology they use loses a lot of packets. And because the DOT just doing
statistical analysis they don't care. They don't have any incentive to capture more
packets or to make the system better. That's good enough for them. So really the only
evidence we have is the kind of - assume that DOT have fixed budgets not going to spend money
on stuff that doesn't actually improve their mission. Unless the NSA wants to pay for it, the
NSA probably has to take what they can get from them. Yes? The tool built into Cali and
Backtrack? Let's see. There is uber tooth tools in kismet but you may be thinking of blue
smash tools which include a command line. Bluetooth Mac changer. That said, you don't
even necessarily need that. The blue Z library that is the key Bluetooth library of Linux will
allow you to specify Mac addresses to your devices. I think may able to do with it HDI
tool, I'm not certain about that. On Linux Bluetooth Macs are user programmable. You can
set -- it's actually kind of nice because the blue Z stack was basically Linux's Bluetooth
support was written open source from the start so a lot of the great stuff that we had to clone
drivers and Wi-Fi world can manage to get to work was built in there from the ground up on
Bluetooth. It's been quite convenient for people like me. Anything else? How the scanners
communicate with each other? I've not looked in to that. Like I said they said either Ethernet
or cell modem is the way all of the manufacturers I looked at advertise communication. If it's
cell modem, you can use software radio and try to interpret that -- probably two G cell modem,
they don't need much bandwidth at all. If it's Ethernet it's obviously a little harder.
Question over there? The question was, is there some mechanism like acknowledgment
frames in Bluetooth where you can stimulate a response on somebody else. Yes, there is. In
fact the uber tooth scan tool does basically that. It spews out a bunch of packets to get
responses from things. The main thing, though, is beaconing. If the device is discoverable
that's what the GISD address packets do. You send them out and they're basically screaming,
does anybody want to pair with me and any device that's discoverable will respond, yes,
this is my address. And they can allow initiate a connection. All right. One more? Question was
classic Bluetooth not BLE? Yes, it is. Because those devices in cars all headsets those are
Bluetooth 1.0 and 2.0, they aren't BLE devices, they're not Bluetooth smart. Bluetooth smart
is hell of a lot easier to sniff than classic Bluetooth is. But in this case that is not what
they're using because the particular devices they want to track, that's not what they're
using. All right. I've got the link to where I've got copy of my slides up on my blog. I will
update those to the current copy of the slides today. And I will also within next week be posting
this talk in more white paper oriented format on permitergrid.com. All right.
Thanks. [Applause]