Archive for the ‘Bluetooth’ Category

« Older Entries
Newer Entries »

Dumber than a bag of hair.

Tuesday, June 19th, 2018

I missed the first part of this story last week, but I caught the second part when it came across the Hacker News Twitter feed.

There is a company called Tapplock that makes a $99 “smart” padlock. No, this isn’t the same company that makes a “smart” padlock that’s “completely invincible” to anybody that doesn’t have a screwdriver. Different company, different lock.

But it does have a fingerprint scanner and Bluetooth.

Part 1:

Among other features, you can set up multiple fingerprint profiles, so you can enable multiple people to unlock the padlock with their fingerprints.

Except: their protocol doesn’t gracefully handle revocation. The lock communicates over HTTP: there’s no encryption, and…

I could see that a string of “random” looking data was sent to the lock over BLE each time I connected to it. Without this data, the lock would not respond to commands.
But it was also noted that this data did not change, no matter how many times I connected. A couple of lines of commands in gatttool and it was apparent that the lock was vulnerable to trivial replay attacks…
…I shared the lock with another user, and sniffed the BLE data. It was identical to the normal unlocking data. Even if you revoke permissions, you have already given the other user all the information they need to authenticate with the lock, in perpetuity.

But wait, there’s more! It turns out that that random data, that unique key…is derived directly from the lock’s MAC address! The one that’s constantly broadcast by the lock so you can access it over Bluetooth!

I scripted the attack up to scan for Tapplocks and unlock them. You can just walk up to any Tapplock and unlock it in under 2s. It requires no skill or knowledge to do this.

Part 2:

But wait, there’s more! Another security researcher, who didn’t have a Tapplock (“I am out of IoT budget for this month as my wife has -kindly- informed me”), decided to play around with the Tapplock’s cloud based admin tools…

…and discovered that, once you logged in with a valid account, you could access any other account simply by incrementing the account ID.

As a result, Stykas could not only add himself as an authorised user to anyone else’s lock, but also read out personal information from that person’s account, including the last location (if known) where the Tapplock was opened.
Incredibly, Tapplock’s back-end system would not only let him open other people’s locks using the official app, but also tell him where to find the locks he could now open!

References:

The Pen Test Partners initial attack.

The Vangelis Stykas admin interface attack.

Sophos “Naked Security” blog: part 1. Part 2.

Posted in Bluetooth, Geek, Locks, Radio, Stupid | Comments Closed

Random notes toward an after action report: Dallas.

Tuesday, May 8th, 2018

This is a catch-all for random and undifferentiated thoughts that didn’t make it into my previous NRAAM reports. I’ll put in a jump, since this is running long…

(more…)

Posted in asus_eee, Bluetooth, Books, Clothing, Geek, Guns, Hats, linux, Mixology, Photography, project_e, Radio, Shirts | Comments Closed

Is safe! Is not safe!

Monday, December 11th, 2017

Another thing I haven’t had a chance to blog before now:

Vaultek makes gun safes. Among their models is the VT20i, which has a fingerprint reader and Bluetooth. You can use Bluetooth and an app to unlock the safe.

And, yes, you already know where this is going, don’t you?

In this case, the responsible party is Two Six Labs. This is a pretty fascinating takedown.

High points:

  • “The manufacturer’s Android application allows for unlimited pairing attempts with the safe. The pairing pin code is the same as the unlocking pin code. This allows for an attacker to identify the shared pincode by repeated brute force pairing attempts to the safe.”
  • “There is no encryption between the Android phone app and the safe. The application transmits the safe’s pin code in clear text after successfully pairing.”
  • “An attacker can remotely unlock any safe in this product line through specially formatted Bluetooth messages, even with no knowledge of the pin code…the safe does not verify the pin code, so an attacker can obtain authorization and unlock the safe using any arbitrary value as the pin code.”

Even if you aren’t into guns, or safes, or gun safes, I think this is a pretty good “how do I go about banging on a Bluetooth device” primer.

Somewhat to their credit, Vaultek says they are offering a patch, though it looks like you’ll have to send your safe back to get it. (Vaultek says they’ll cover shipping both ways, which can’t be cheap.)

Edited to add: something from Vaultek’s site on this issue:

Either of these methods are not easily captured and require several factors to execute including time, the right equipment, and close proximity to the safe.

They also refer to the attack as requiring “special equipment”. The “special equipment” is an Ubertooth, which you can get here and here, among other places.

As for proximity, that’s a good question that Two Six Labs didn’t address: with the right antenna and Bluetooth adapter, how far away can you be to make a successful attack? Does anyone remember the “Picking Bluetooth Low Energy Locks from a Quarter Mile Away” talk from DEFCON 24?

(Yes, door locks have to be accessible from the outside, while your gun safe is almost certainly inside. Modern construction almost certainly attenuates the signal some. But how much? Could I drive through the neighborhood with a Sena UD100 or something very much like it, just sniffing for Vaultek safes? And then come back later to attack them?)

Posted in Android, Bluetooth, Guns, Radio | Comments Closed

Here’s your hat.

Wednesday, July 26th, 2017

Black Hat 2017 is just getting started.

There’s some overlap with DEFCON 25. For example, hacking wind farm control networks and the SHA-1 hash talk are on both schedules. But there are also a few things unique to the Black Hat 2017 schedule:

The same rules for the DEFCON post apply here: if you’re a presenter who wants some love, or if you want me to follow a specific talk, leave a comment.

Posted in Apple, Bluetooth, Cars, DEFCON, DEFCON 25, GPS, Locks, Radio, WiFi | Comments Closed

Actually, they can read your poker face.

Wednesday, October 26th, 2016

Or at least your cards.

This is a presentation that I overlooked from DEFCON 24, but the authors have now been blogging.

For somewhere between $1,300 and $5,000, you can buy a device that helps you cheat at poker.

The technology is quite interesting. It isn’t just “disguised” as a phone: the device is actually a fully functional Android phone, with a custom ROM and app that controls the cheating portion.

Ironically, there is a hardcoded backdoor password in the app, which makes this security measure pointless if you know the backdoor password.

How does it work? Hidden camera, concealed infrared LEDs, and…

What makes the whole thing work is the use of a special deck in which the four edges of each card are marked with IR-absorbing ink. As a result, when this marked deck is illuminated by the IR LEDs, the spots of ink absorb the IR, creating a sequence of black spots…
The sequence of black spots created by the IR illumination, illustrated in the photo above, is read remotely by the cheating device to infer a card’s suit and value. You can think of those markings as invisible barcodes.

So yes, you do need to slip in a marked deck. But the people who will sell you the phone will also sell you pre-marked decks, which are designed to look like they haven’t been messed with. And apparently the phone will pair with Bluetooth based audio and haptic feedback devices, so you don’t even have to be looking at the display.

And yes, because it is based on marked cards, it will work with card games other than poker, too. (High-end bridge cheating? Chris Christie, call your office, please. Sorry, little joke there.)

The post that’s up now is just the first one in a promised series: I’ll try to link to the other ones as they go up.

Posted in Android, Bluetooth, DEFCON 24, Geek, Phones, Radio | Comments Closed

More on Blue Hydra.

Sunday, August 7th, 2016

Earlier, I wrote “It runs! It works! Mostly. Kind of.”

I’ve been banging on Blue Hydra in my spare time since Thursday, and I stand by that statement. Here’s what I’ve run into so far.

The README is pretty clear, and I didn’t have any problems installing the required packages. (I don’t have an Ubertooth, so I skipped that one. We’ll come back to the Ubertooth later.)

First problem, which was actually very tiny: I know next to nothing about Ruby, other than that cartoon foxes are somehow involved, so the phrase “With ruby installed add the bundler gem” was more like “I don’t speak your crazy moon language”. Google cleared that up pretty quickly: the magic words are gem install bundler.

Next problem: running bundle install resulted in an error stating that it couldn’t find the Ruby header files. It turns out that, while my Ubuntu installation had Ruby 2.1 installed, it didn’t have the ruby-dev package installed. sudo apt-get install ruby-dev fixed that issue.

Next problem: the SQLIte Ruby gem failed to install when I ran bundle install. It turns out that I also needed the sqlite3-dev package as well. And with that installed, the bundle built, and I could do ./bin/blue_hydra.

Which gave an error stating that it didn’t have permissions to open a handle for write. Okay, let’s try sudo ./bin/blue_hydra (because I always run code from strangers as root on my machine; everyone knows strangers have the best candy). And that actually worked: Blue Hydra launched and ran just fine. In fairness, this may be a configuration issue on my machine, and not an issue with the software itself.

In playing with it, I’ve found that it does what it claims to do. Sort of. It’s been able to detect devices in my small lab environment with Bluetooth discovery turned off, which is impressive. I also like the fact that it stores data into an SQLite database; other Bluetooth scanning tools I’ve played with didn’t do that.

However, it seems to take a while to detect my iPhone; in some instances, it doesn’t detect it at all until I go into Settings->Bluetooth. Once I’m in the Bluetooth settings, even if I don’t make a change, Blue Hydra seems to pick up the iPhone. Blue Hydra also has totally failed to detect another smart phone in my small lab environment (and I have verified that Bluetooth was both on and set to discoverable.)

Now, to be fair, there may be some other things going on:

  • I’ve also observed previously that Bluetooth under Ubuntu 15.10 didn’t work very well. At all. So at one point on Saturday, just for giggles, I upgraded Project e to Ubuntu 16.01.1 LTS. And shockingly (at least for me) Bluetooth works much much better. As in, I can actually pair my phone with Ubuntu and do other Bluetooth related stuff that didn’t work with 15.10. That seems to have mitigated the discovery issues I was seeing with Blue Hydra a little, but not as much as I would have liked. (Edited to add 8/8: Forgot to mention: after I upgraded, I did have to rerun bundle install to get Blue Hydra working again. But the second time, it ran without incident or error, and Blue Hydra worked immediately aftewards (though it still required root).)
  • I was using the Asus built-in Bluetooth adapter in my testing. Also just for giggles, I switched Blue Hydra to use an external USB adapter as well. That didn’t seem to make a difference.
  • In fairness, Blue Hydra may be designed to work best with an Ubertooth One. The temptation is great to pick one of those up. It is also tempting to pick up a BCM20702A0 based external adapter (like this one) partly to see if that works better, partly because I don’t have a Bluetooth LE compatible adapter (and this one is cheap) and partly because the Bluetooth lock stuff is based on that adapter. (Edited to add 8/8: I’m also tempted by this Sena UD100 adapter. It is a little more expensive, but also high power and has a SMA antenna connector. That could be useful.)
  • It may also be that I have an unreasonable expectation. Project e is seven years old at this point, and, while it still runs Ubuntu reasonably well, I do feel some slowness. Also, I think the battery life is slipping, and I’m not sure if replacements are available. I’ve been thinking off and on about replacing it with something gently used from Discount Electronics: something like a Core i5 or Core i7 machine with USB3 and a GPU that will work with hashcat. Maybe. We’ll see. Point is, some of my issues may just be “limits of old hardware” rather than bugs.
  • And who knows? There may very well be some bugs that get fixed after DEFCON.

tl, dr: Blue Hydra is nice, but I’m not yet convinced it is the second coming of Christ that I’ve been waiting for.

Posted in Apple, Bluetooth, DEFCON 24, Geek, linux, Nokia, project_e, Radio, Ruby | 4 Comments »

DEFCON 24: August 7, 2016 updates.

Sunday, August 7th, 2016

The presentations on the conference CD are here, if you’re looking for something specific that I didn’t mention. I’m still going to try to provide links to individual presenters and their sites, simply because I believe those are the most recent and best updated ones. Just to be clear, I’m not trying to rip off anyone else’s work, which is why I link directly. I want to provide myself (and possibly other interested folks) with one-stop shopping for the latest versions of the things I’m most interested in.

This takes us into today. I’ve been at this for about an hour and a half now. I’m not proud. Or tired. But I do have some other things I want to do, and I think it is a bit early to expect Sunday presentations to be up. I’ll end this one for now, and see if I can do another update tomorrow. Also, I want to do a further write-up on Blue Hydra, possibly tonight, maybe tomorrow as well.
If you are a presenter who’d like to provide a link to your talk (even if it is one I didn’t specifically call out) or you have other comments or questions, please feel free to comment here or send an email to stainles [at] sportsfirings.com.

Posted in Bluetooth, DEFCON 24, Geek, Radio | Comments Closed

DEFCON 24 notes: Hail Hydra!

Thursday, August 4th, 2016

GitHub repository for Blue Hydra.

I’m jumping the gun a little, as the presentation is still a few hours away, but I wanted to bookmark this for personal reference as well as the enjoyment and edification of my readers.

Edited to add: quick update. Holy jumping mother o’ God in a side-car with chocolate jimmies and a lobster bib! It runs! It works! Mostly. Kind of.

If I get a chance, I’ll try to write up the steps I had to follow tomorrow. Yes, this blog is my personal Wiki: also, while the instructions in the README are actually pretty good, I ran into a few dependency issues that were not mentioned, but are documented on Stack Overflow.

Posted in Bluetooth, Bookmarks, DEFCON 24, Geek, linux, Radio | Comments Closed

DEFCON 24: 0-day notes.

Wednesday, August 3rd, 2016

Another year observing DEFCON remotely. Maybe next year, if I get lucky, or the year after that.

The schedule is here. If I were going, what would I go to? What gets me excited? What do I think you should look for if you are lucky enough to go?

(As a side note, one of my cow-orkers was lucky enough to get a company paid trip to Black Hat this year. I’m hoping he’ll let me make archival copies of the handouts.)

(more…)

Posted in Android, Apple, Bluetooth, Books, DEFCON 24, Geek, Phones, Radio | 2 Comments »

New toy! New project!

Saturday, April 9th, 2016

I was out and about earlier today with my mom and my nephew: we stopped by Hobby Lobby because I was looking for something. I’ll be posting about that something later on, but while we were there, I found one of these and ended up getting a screaming deal on it with the 40% off coupon.

Which is great, but that looks like a manual control box, right? How do you control it with a PC? Lots of soldering and a custom circuit board?

Ah. Nope. They have a USB device interface for the OWI-535. Isn’t that nifty?

But wait! The included software only runs on a PC! How do you control it with a Mac, or a LINUX system?

Surprise! People have reverse-engineered the control protocol! For example, this guy! (I love that blog title, by the way.) It looks like most of the other control examples I’ve found all loop back to Vadim Zaliva’s work documenting the protocol for the OWI-535. (He’s also documented the control protocol for the OWI-007 here.)

And look! Here’s control code in Python. running on a Raspberry Pi! Isn’t that a clever cleaver!

We’ll see if I can get the arm together and working without breaking it. Bad news: I don’t have that much mechanical aptitude. Good news: they claim all you need is needle-nosed pliers, diagonal cutters, and a Phillips screwdriver. No soldering required, which is good. I could probably solder my way out of a paper bag if someone held a gun to my head, but I’ve never been what you could call “good”, or even “competent” at it…

(As a side note, I’ve been trying to get back to “Talkin’ GPS Blues“. Unfortunately, I also decided to upgrade Project e to Ubuntu 15.10…and Bluetooth apparently doesn’t work well on 15.10, at least as of when I completed the upgrade. So once I get Bluetooth working again, and have some more time, I intend to revisit GPS, this time with some skanky Perl, Python, and possibly even Java code. We’ll see.)

Posted in Bluetooth, Bookmarks, Geek, GPS, linux, Programming Languages, project_e, Python, Radio | 1 Comment »

A few random things I found interesting.

Monday, September 14th, 2015

Some by way of the Hacker News Twitter, others from elsewhere.

Nice appreciation of Elmore Leonard from The New York Review of Books.

Brian Krebs goes to Mexico in search of Bluetooth ATM skimmers, part 1.

Fun with software defined radio, or scanners live in vain.

NFL loser update resumes tomorrow.

Posted in Bluetooth, Books, Clippings, Geek, Radio, SDR | Comments Closed

DEFCON 23 notes: August 12, 2015.

Wednesday, August 12th, 2015

More slides! More stuff!

Posted in Bluetooth, Bookmarks, DEFCON 23, Geek, Radio | Comments Closed

« Older Entries
Newer Entries »