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."
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.
Hell I wandered into the phone system/networking closet at a fairly prominent Chicago hotel, on accident, after walking past multiple security guards.
Come to think of it, couldn't a device just be hidden in a package? Like a small statue delivered to a bad address?
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.)
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.
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.
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.
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.
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 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.
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.
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.
I can't recall the last time I used bluetooth for anything.
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.
It's still good to keep WiFi and Bluetooth off for battery and security.
> 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?
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.
(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.
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.
(Remember that these vulnerabilities have been around a long time, laying there undiscovered).
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.
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.
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.
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.
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?
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.