Hacker News new | comments | show | ask | jobs | submit login
Billions of devices imperiled by new clickless Bluetooth attack (arstechnica.com)
284 points by mcone 14 days ago | hide | past | web | 108 comments | favorite

Stuff like this is why physical pentesting is so effective. If you sneak into a company and stick a raspi in a corner, nobody tends to notice a black box amidst a bunch of cables. But that black box can attack the dev machines in a variety of ways: it can be a honeypot wifi AP until someone accidentally connects to it, at which point you have creds for the real network. Then you can connect to the real network and look for workstations to attack. Or, as this article points out, you might be able to use a tricky bluetooth attack to get onto the workstations directly.

I'm not sure there's any way to protect against this. Physical pentesters tend to get caught less than 10% of the time. It's very easy to sneak into a building if you know what you're doing and have confidence. And "knowing what you're doing" generally consists of "dress up like a construction worker xor interviewee."

Delivery people... I've had my laptop stolen by a fake delivery worker who cleaned up the building.

An UPS or DHL uniform will get you most everywhere, and you have an excuse for carrying bulky stuff.

Edit: Kevin Mitnick's The Art of Deception is an oldie but goodie detailing most of this stuff.


Hmm, what kind of company lets a UPS/etc man past the front desk? It seems pretty standard practice everywhere I've ever worked that packages went to a designated spot (front desk, loading dock, etc) and the final recipient was pinged via email/whatever to come pick it up.

Most companies. A clip board, a smile and a sense you know where you are going is a pretty powerful combo.

Hell I wandered into the phone system/networking closet at a fairly prominent Chicago hotel, on accident, after walking past multiple security guards.

My huge employer does - UPS takes the cargo elevator but get access to the mailroom, inside secured the premise.

Come to think of it, couldn't a device just be hidden in a package? Like a small statue delivered to a bad address?

You don't even need physical access. Just stick it outside in a planter.

Brilliant, plant it by the smoking areas where there's captive targets

You can also buy UPS and Fedex uniforms off eBay for dirt cheap. AT&T shirts, too. Pretty much any uniform you'd want to infiltrate a building in the developed world, you can buy it on eBay.

Worse still, the raspberry pi can sit quietly, doing nothing, until a few seconds after a relevant 0-day exploit is discovered. You could have great security practices, you could patch the moment vendors release them, and still be vulnerable.

The only solution is layered security. (And to be clear, 802.11i barely qualifies as a layer.)

Well, you could ban any unknown devices that appear on your network. That's not too difficult.

Then you can adjust your Pi to spoof a known device. That's not too difficult.

The only solution is layered security. (And to be clear, banning unknown devices barely qualifies as a layer.)

Yay for 802.1X.

I'll add that extending the range of a Bluetooth transmitter significantly (hundreds of meters) is possible using a directional antenna and a power amplifier.

This means that sitting in a building next door, or just having a direct line of sight to the target, is enough to perform such attacks.

The beauty of just dropping your black boxes everywhere is that once you have a 0-day, you can just run it on your full fleet of machines scattered everywhere. Once you find a new 0-day, you can run that one etc. Less effort with a lot more payoff.

There's no way anybody has actually done this. Are you guys just fantasizing?

Tomorrow's news today?

Companies need to invest in high quality cameras. Facial recognition software is getting so good even HUMINT is having a problem with it. Soon I see these things integrated with facial recognition software so realtime alerts can detect false-delivery persons and known criminals.

Well, you either do the whole honeypot routine (and enterprise WLAN running MSCHAPv2 is certainly a very good target) or you just stick it directly into the next RJ45. At most there is a MAC filter.

> Stuff like this is why physical pentesting is so effective.

It's also why physical pentesting is a scam.

Like you say, people can get caught and you're screwed if you're not working for a pentesting company.

You have to travel to the target which is an expensive PITA. You need to know the culture (in company and in country). Then to top it off you are in the countries jurisdiction, in person. Look what happened to Aaron Swartz (Which might be more an inside job, his father did work for MIT so he might have had some inside information)

Most intelligent people won't do it. It also involves a skill set quit different to computer hacking and most social engineering.

I'd like to know of examples of real world incidents.

Since Van Eck phreaking tools exist which can read keystrokes and RAM states on specific machines from blocks away, and since no one talks about these tools, I am leaving this comment here.

What a bunch of nonsense. Reading out RAM states and keystrokes from one room over is already quite a feat, to read RAM states or keystrokes from 'blocks away' is science fiction and if it could be done would be news to me.

Yes, it is possible to recreate the contents of screens from quite far away, it is possible to piece together a lot of data from magnetic fields leaking from computers but this is not simple nor something that easily lends itself to longer distances.

In short, the reason nobody talks about those tools is because they don't exist.

Enjoy the dark ages.

From blocks away? Bullshit. Maybe from the next room using a CRT monitor. I'd love to see the study saying they're able to reliably get keystrokes or screen images from any significant distance.

Link to the whitepaper.


Part of the attack is on BlueZ's implementation.

> In BlueZ’s case, L2CAP is included as part of the core Linux kernel code. This is a rather dangerous choice. Combining a fully exposed communication protocol, arcane features like EFS and a kernel space implementation is a recipe for trouble.

Why are none of the CVE vulnerability ids from that paper coming up for me in the CVE database? Eg http://www.cvedetails.com/cve/CVE-2017-14315/

I tried all 8 of them, none found.

Depends on the newness of the attack. It can take awhile for an attack to get into the CVE DB. Though usually it says "this CVE is reserved" rather than "not found."

It was only unembargoed at 9AM EDT. More details here: https://access.redhat.com/blogs/product-security/posts/blueb...

That was also not there a couple of hours ago!

Is EFS here referring to Qualcom chipset filesystem, and what does that have to do with L2CAP being in the kernel just like IP and other protocols?

From the WP: "... Extended Flow Specification (EFS​) [is a] feature of L2CAP ..."

As a slightly related side note, I pretty much only turn on bluetooth when I actually need to use it (which is rarely, such as syncing my Garmin every now and then). It's a waste of battery power to keep it on, and Bluetooth is also often used to track people. For example, it's used by traffic monitoring systems to measure the speed of traffic[1] by storing and tracking the MAC address.

It would be nice if Android and iOS provided a convenient way to activate Bluetooth temporarily, only when needed.

[1]: http://www.tyco-its.com/products-and-services/urban-traffic-...

The battery power wasted is negligible (it's unnoticeable in the noise that makes me go from 100% at midnight to ~55% by the end of the day).

I connect to two different bluetooth devices; my helmet intercom (for phone calls, podcasts and music while commuting) and my headphones (normally for podcasts while doing housework or motorcycle maintenance). Needing to toggle settings on two different devices before connection would be more tedious than just one.

Same here. I keep BT on for the Pebble I use, and the battery usage is negligible.

> convenient way to activate Bluetooth temporarily, only when needed

the slide-up menu in ios is pretty convenient.... you can do it when the phone is locked, even. i use it all the time to disable and enable wifi and bluetooth and use the flashlight.

I assume GP must mean even _more_ convenient than that, since Android also has a settings panel you can pull down with the same functionality.

It'd be nice to use NFC to temporarily activate Bluetooth for a given device, for the duration of use. Even better if it generated a random MAC address every time you established the connection, and handle auth entirely in userspace through encrypted channels. You could bypass the stupid Bluetooth auth.

Plus an option to temporarily enable and disable the NFC radio!

>you can [activate bluetooth] when the phone is locked

Is there any way to disable that 'feature'? Seems like an unnecessary risk.

It's slightly related, and only to people with your specific use case.

The amount of people that would use "temporary bluetooth" is so small, that adding it would not be wise as it would confuse the majority of average users.

Most people that leave their bluetooth on do so because they have bluetooth headphones or devices they use regularly like their car stereo/phone link.

If you're worried about tracking or power consumption, turn your bluetooth off when you're not using it.

Trying to get the rest of the world to conform to your use case is not practical and would only introduce problems with little benefit.

That sounds like an opinion rather than a fact. Do you have any data that shows most people actually use Bluetooth 100% of the time? Speaking anecdotally, none of my friends use it, except occasionally.

Most people I know (including myself) don't give a shit about Bluetooth, or computer gadgetry for that matter. People just want their battery to last until the end of the day so they can keep refreshing Instagram, send/receive chats, and check the time.

First of all, this attack sin't constrained to smartphones - it would be folly to ignore the hundreds of millions of laptops/desktops that use bluetooth mice and keyboards in every office.

Second, most people I know with smartphones have bluetooth headsets, car stereos, or Apple watches that use bluetooth. Turning BT on every time you want to use those isn't terrible (swipe up control center, tap BT icon), but it does get old.

Fair enough, although I don't think I've ever used Bluetooth on my Macbook. It's unreliable and a pain to pair devices, so it's pretty much always easier to just plug a cable in, or connect over WiFi (if possible).

Bluetooth is the Microsoft Bob of connectivity.

All of Apples wireless keyboards and mice use bluetooth. It is literally the first requirement listed.

I can't turn off bluetooth on my phone because of my Apple Watch. Anyone who has an Apple Watch can't turn off Bluetooth.

That't the number one reason I ditched the smart watch I won. I toggle blue tooth and wifi as necessary.

I never said people use Bluetooth 100% of the time. I said "temporary bluetooth" is not a mass-market concept.

If you only use it occasionally, then I don't see why switching it on or off is a problem that needs a solution.

> It would be nice if Android and iOS provided a convenient way to activate Bluetooth temporarily, only when needed.

I can't speak about iOS, but if you're willing to do a little tweaking there are multiple ways to do this on Android devices.

The simplest is probably with "Llama - Location Profiles" though it's no longer actively developed. Disable or edit the default profiles that shift your phone to quiet, etc. and create your own that toggle wifi, Bluetooth, etc based on events or on a widget you create. The Bluetooth toggle action lets you specify on/off/on for X minutes, etc. The only issue I might see there is if a fitness tracker is seen as a connected device as far as Android is concerned. I'll note that mine does not show up on the list of devices.

The more maintained option would be doing something similar with Tasker, but I haven't tried it.

Tasker can be triggered by NFC using something like "NFC ReTag Pro", and Llama can have a trigger based on an NFC tag as well.

What do you mean by temporarily? You mean automatically? Because both on iOS as well as Android its both very accessible to turn it of or on.

My guess is that allow an app to turn it on/off as needed. I have a Pebble watch so I need the bluetooth on. Right now it's either always have the Bluetooth on or I don't use the watch. So I'm assuming that they meant that there could be a way to allow an app (or the OS handles this) to start up bluetooth, pair, send its message, then turn off. Like some form of Push Notification style Bluetoothing. That seems like it'll just add a whole bunch of more problems but I'm sure there are smart people out there that can figure it out.

I do the same, because as a general security practice, if I don't need it, I disable it.

I can't recall the last time I used bluetooth for anything.

I think a reasonable implementation of this would be a "manual connections only" mode, where Bluetooth is always kept off until you enter the Bluetooth connection menu, at which point it turns on and scan, and connects only to the specific device(s) you tell it to connect to. And then once the last Bluetooth device is disconnected, Bluetooth is deactivated once again (perhaps after a short delay to allow for reestablishment of a shaky connection).

It's already patched

Well, yes. But how long has the exploit been effective? It's certainly noteworthy.

A coworker once demo'd a metasploit module capable of taking over a Windows 7 machine. The vuln had long since been patched, but apparently it was still useful in the field sometimes because people hadn't bothered to upgrade every workstation.

Not that there aren't other signals, but iOS will periodically change your MAC address for privacy.

It's still good to keep WiFi and Bluetooth off for battery and security.

BLE uses so little power its insignificant. WiFi can actually save power if you are using cellular data. There is not one size fits all solution here.

I use Tasker on android for this and many other similar tasks.

From description of vulnerability in Linux Kernel bluetooth code:

> This function receives a configuration response buffer in the rsp argument, and its length in the len argument

> Each element it unpacks from the configuration response is validated and then packed back onto a response buffer, which is pointed to by the data argument.

> However, the size of this response buffer is not passed into the function

C developers are repeating the same mistake for years. Why don't they invent some type or class for safe work with memory buffers?


How would this be performance? Not checking a length, resulting in an overflow, should be a warning. Whatever it takes to make that happen needs to happen. This is beyond silly.

This game of C vulnerabilities and patches has been going on on the Internet for 20+ years. It's largely an awareness problem, and prejudice toward safer languages.

>It's already patched.

This refrain is tired and myopic.

We must operate with the assumption that like BadUSB, heartbleed, and this latest attack, there are likely devastating vulnerabilities present in all devices we use and actors may have the chance to exploit them before we ever become aware of them or have the opportunity to apply a patch.

We've had a number of folks at work ask if their Android phone will be patched, so I thought it would be helpful to list the Android Open Source Project (aka: device operating system) versions that will be receiving the necessary patches [0]:

4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0

Note: it will likely take some time for your handset manufacturer to test and release the patch for your specific phone.

0: https://source.android.com/security/bulletin/2017-09-01 (see CVE-2017-0781, 0782, 0783 and 0785)

Of course my Motorola (X Play) is getting no updates so I get to spend the evening installing LineageOS and reconfiguring the phone. Should have treated it like a computer: wipe the manufacturer's software right away and install a free alternative.

Pretty sad that random opensource projects are offering better support than the companies I paid for their products.

Is that why Google Play Protect was recommending to disable Bluetooth Share which seems to have caused a lot of issues for people. Turning it back on requires to reset all app preferences.

I got the update from Sony while I was reading the post. It's an Xperia X Compact and they've made a good job so far. Almost an update per month, it started with Android 6 and it's on Android 7.1.1 now, September patch level, which is safe according to the post.

Bluez for Ubuntu 16.04 LTS instead is old, from March 2016. There is a newer Bluez from August 2017 but it's probably for newer versions of Ubuntu. I hope they patch it quickly for everybody.

Is it a C buffer overflow?

- Edit: Yes, it is, on the stack.

So, I guess it's back to using wired headphones with the phone...

Wired headphones are superior anyway, IMO.

Wireless ones are better for running, so it's not a Pareto dominance thing. Both have pros and cons.

Wireless headphones pop out when running; wired phones have a convenient wire tethering them to one's phone.

> pop out when running

There are many different ways wireless headphones prevent that from happening.

> wired headphones have a convenient wire tethering them to one's phone

The wire is convenient if you tend to drop them to the floor, which won't happen to most wireless headphones. But it's hateful if it yanks them from your ears, as is sometimes the case when you're exercising.

For quality music. For everything else it matters less.

For all use cases? Or just yours

I'm just speaking in terms of my personal opinion. Most of the really good headphones are wired (i.e., higher-end audiophile headphones like Grado) and will probably remain so. People also like to supply their own amps. There are some portable Bluetooth headphone amps, but they're not so good compared to USB or analogue amps.

Unless you're on a new iPhone...

I don't wanna be that guy but ... the iPhone isn't mentioned as vulnerable in the article -anywhere-.

Actually, older versions of iOS are vulnerable (before iOS 10). I have no idea how many people actually run that, however.

iPhones that are required to use Bluetooth for headphones cannot run pre-10 versions of iOS, so this is a moot point.

Not people on the iPhone 7.

Ah, you're right, my mistake. Apologies all.

One of our bigger apps is showing about 1%.

This is just a grab bag of BT vulnerabilities they found. It's pretty likely that there are vulnerabilities in iOS BT, they just weren't found in this round.

(Remember that these vulnerabilities have been around a long time, laying there undiscovered).

Chalk one up for Windows Phone. Security through obscurity, on a more serious note does the flaw happen because of a common opensource implementation?

What makes you think that the Windows attack doesn't apply to Windows Phones? At least Windows Phone 8 and 10 are based on the normal Windows kernel, and I don't see why they wouldn't share the Bluetooth implementation as well.

> A Microsoft representative said Windows Phone was never vulnerable.

it says it right there in the article

whops, missed that.

I wonder, if a physical "chain reaction" attack described is possible.

Back in mid naughties, the "MMS of death" chain reaction attacks on Sony Ericsson phones were so intense, that they were taking down cell networks through which they propagated, thus fizzling.

I've noticed that, starting quite recently, Bluetooth has always been off every time I've gone to use it on my trusty old Nexus 5. I figured it was the sort of bug that tends to accumulate on old phones, but maybe not eh?

Is the playstation 3/4 vulnerable to this?

What is the actual exploit? Article was very thin on details....


> Apple identified and fixed these bugs 2 major releases ago.

Huh. Did they pass the information back to the relevant vendors, or just keep it in their toolbox for when they needed to say "See, Android is so insecure!"?

Edit: this is probably snarkier than it should be, but without reading a 30+ page white paper on my phone these seem to be OS and library issues not chipset issues. Did Apple do a big Bluetooth fix on their own stuff, or are they using (and fixing) some of the same libraries without passing vulnerabilities back to the library maintainers? I don't follow Apple enough to know.

It looks like Apple's implementation diverges substantially from other vendors, and is likely not based on the same stack at all.

I'm not so convinced Linux is a "tire fire". Just about everything has vulnerabilities and needs to be occasionally patched, doesn't mean we need to get into some sort of holy war every time there's a new exploit for one device or the other.

That said, Android's lack of updates for older devices is its biggest weakness. Google is looking to fix this next version as they separate the HAL out. Something to look at is definitely if there would be a standard kernel with loaded modules or if it would still be left to manufacturers.

No, Linux is qualitatively worse off since it keeps bug-dense code in areas of high privilege with few mitigating controls.

Yes, there will be bugs but refusing to properly address that ahead of time by separating and lowering privileges, applying sandboxes, and proactively auditing external attack surface is why Android is worse than iOS for security.

I'm not disagreeing that it's poorer for security, but in practice under most threat models you'll be able to patch in time for it to not even matter. And you'd still need to patch, even if it was nicely sandboxed - getting access to just the bluetooth stack could allow emulation of a keyboard or internet connection. Let's not forget that Apple has had trivially exploitable vulnerabilities in the past too - I'd argue that Linux's recent history has been significantly better in that department actually, despite the technical merits of the mitigations being worse.

There's no PoC code out for this even and it's been many times longer than it would take to patch something like this in most cases.

What I'm saying is that going from "Linux has worse security design" to "use an iPhone" is just a non-sequitur - people choose devices and operating systems for reasons other than the best security design and there's no reason that an attack like this should force you onto a single platform. It comes off as nothing more than fanboyism.

If I have to wait 3 minutes for a bus instead of 2, I am 'qualitatively worse off', but that extra minute doesn't flip into being 'a tire fire'.

>Linux is a security tire fire.

Perhaps I'm missing something, but why are you calling Linux a tire fire when it has had significantly less code execution and buffer overflow exploits than iOS?

Definitely missing something.

The CVE counts say otherwise.

Do you have a data source to back up your claim? It doesn't sound right.

first, exploits and vulnerabilities are different if related things. If you're showing links to CVEs, I'm guessing you meant vulnerabilities not exploits.

The number of reported vulnerabilities does not have a strong correlation at all to how vulnerable something actually is. People pay hundreds of thousands of dollars for apple bugs; indeed apple does. Based on the above data, I'd even suggest that it "proves" iOS is significantly more secure. The bounties available for Linux are minuscule.

Indeed, Linux's monolithic kernel design will mean that such errors will be continuing popping up.

The one has nothing to do with the other. I'm a big fan of microkernels but this class of bugs has nothing to do with whether or not you use a micro kernel or a monolithic one.

If by class of bugs you mean "munging the stack," yes - but the difference is in the effect on integrity of the total system. In monolithic kernels, if an attacker can monopolize on the situation (by defeating mitigations, if any) and control execution-flow, they can run code on ring 0. This isn't the case if you're on a microkernel where a bluetooth driver lives in userspace.

That's not true, it strongly affects the ability to separate privileges and apply sandboxing. For example, compare Apple's Seatbelt, which was a comparatively light lift to the intrusiveness of SELinux or restricted token sandboxing on Windows.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact