Billions of devices imperiled by new clickless Bluetooth attack
arstechnica.com
arstechnica.com
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."
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 only solution is layered security. (And to be clear, 802.11i barely qualifies as a layer.)
The only solution is layered security. (And to be clear, banning unknown devices barely qualifies as a layer.)
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.
https://www.goodreads.com/book/show/18160.The_Art_of_Decepti...
Come to think of it, couldn't a device just be hidden in a package? Like a small statue delivered to a bad address?
Hell I wandered into the phone system/networking closet at a fairly prominent Chicago hotel, on accident, after walking past multiple security guards.
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.
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.
http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Pa...
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.
I tried all 8 of them, none found.
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-...
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.
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.
Is there any way to disable that 'feature'? Seems like an unnecessary risk.
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.
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.
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.
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.
Bluetooth is the Microsoft Bob of connectivity.
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's still good to keep WiFi and Bluetooth off for battery and security.
I can't recall the last time I used bluetooth for anything.
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.
> 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?
https://github.com/Microsoft/checkedc
https://github.com/Microsoft/checkedc/releases/download/v0.6...
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.
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)
Pretty sad that random opensource projects are offering better support than the companies I paid for their products.
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.
- Edit: Yes, it is, on the stack.
(Remember that these vulnerabilities have been around a long time, laying there undiscovered).
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.
it says it right there in the article
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.