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."
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.
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.)
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.
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.
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.
> 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.
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."
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.
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.
> 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.
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.
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).
It tends to be on by default afaik on iOS (and updating iOS has also been known to accidentally restore defaults without user consent) not sure about Android devices but I would also expect the majority of users have it on.
> 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.
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 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).
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.
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.
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]:
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.
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.
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.
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).
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.
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?
> 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.
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.
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?
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.
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.
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."