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.<p>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."
Link to the whitepaper.<p><a href="http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf" rel="nofollow">http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Pa...</a><p>Part of the attack is on BlueZ's implementation.<p>> 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.
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.<p>It would be nice if Android and iOS provided a convenient way to activate Bluetooth temporarily, only when needed.<p>[1]: <a href="http://www.tyco-its.com/products-and-services/urban-traffic-control/bluetooth-travel-timespeed-measurement-system" rel="nofollow">http://www.tyco-its.com/products-and-services/urban-traffic-...</a>
From description of vulnerability in Linux Kernel bluetooth code:<p>> This function receives a configuration response buffer in the rsp argument, and its length in the len argument<p>> 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.<p>> However, the size of this response buffer is not passed into the function<p>C developers are repeating the same mistake for years. Why don't they invent some type or class for safe work with memory buffers?
>It's already patched.<p>This refrain is tired and myopic.<p>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]:<p>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0<p>Note: it will likely take some time for your handset manufacturer to test and release the patch for your specific phone.<p>0: <a href="https://source.android.com/security/bulletin/2017-09-01" rel="nofollow">https://source.android.com/security/bulletin/2017-09-01</a>
(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.<p>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.<p>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.
I wonder, if a physical "chain reaction" attack described is possible.<p>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?