Bluetooth keystroke-injection in Android, Linux, macOS and iOS

I had to dig a little to figure this out, so, to keep yourself safe:

Android: disable Bluetooth when you're not using it (but you'll be vulnerable while you are). My Pixel just got the 12/5/2023 security update, which fixes the issue; not sure about non-Pixel phones.

Linux: Open up /etc/bluetooth/input.conf and set ClassicBondedOnly=true (in my case I just had to uncomment this, not add anything). The next version of bluetoothd should default to =true, but you can set this yourself now. Don't forget to restart the bluetooth service after doing so.

Not sure about macOS or iOS; I don't have devices running either of those.

Too bad iOS makes it very hard to disable bluetooth. Android was swipe+click, iOS it's swipe, two long presses, two clicks. Or you can type it, but that's obviously more clicks (though possibly faster).

I used to make the effort when I switched from Android, but I already gave up...

I had to create custom shortcuts to disable WiFi and Bluetooth after Apple made the ones from Control Center useless.

Is it possible to do for Location as well? Last time I tried to search for it, it really wasn't possible except through Siri somehow.

I made one to open locations in settings via open URL: prefs:root=Privacy&path=LOCATION

Wow, that's bonkers. I thought apple cared about privacy?

it's route for the settings menu, not sure it works in the browser :)

here's a list with all settings urls: https://github.com/FifiTheBulldog/ios-settings-urls/blob/mas...

It makes sense for most people. When they want to turn those off they want to either disconnect from WiFi or disconnect from Bluetooth audio, and they don’t expect things like airdrop or their Apple Watch to stop working when they turn them off.

Sounds like an excellent opportunity for a UI affordance to me. Instead, Apple has chosen the path of least-yet-most-unpleasant surprise.

Am I missing something? Swipe from the top, tap to disable BT?

Notice the difference in color when you do that. As the other comment pointed out, it only disconnects devices. Apple makes it hard for their users to disable bluetooth (or gps) so features like airtag work well.

You are sacrificing your battery life (and I guess privacy and security) for the ecosystem to work.

Google won't let you use GPS for maps without also turning on wifi for similar reasons I guess. It does make it more accurate but shouldn't be required.

Wasn’t there this thing that Google collected a list of SSIDs using their Google Maps cars, and that gave them “good enough” geolocation using passive WiFi scanning, which was much less battery intensive and faster than GPS?

That's nonsense, Maps works perfectly fine with wifi off

That’s unfortunately only disconnecting until the next day (see text appearing above when pressing).

Too bad iOS makes it very hard to disable bluetooth.

Depending on whether you have the Settings icon on your Home Screen, that’s three taps (Settings -> Bluetooth -> Off). Not even any scrolling.

You can make a shortcut with the action Toggle and set Bluetooth

I’m trying this now and can’t figure this out. I’ve been trying for months now.

I’m adding a new action, I search toggle and Bluetooth and I’m not getting any actions to set Bluetooth. What am I doing wrong? Edit: Scratch that! I figured it out! Realised I wanted a way to connect to a Bluetooth device (my flaky headphones don’t always connect, pain to dig into the settings every time)

Setting doesn't always open on "home".

Annoyingly so it doesn't even always open on the expected screen, e.g. when opening "Wifi settings" from the network selection you might end up in notifications if it was the last screen you used. Not a consistent bug.

On iOS you can scroll diagonally from top right corner and one more click to disable it.

It is not permanent and comes back when disabling airplane mode, in addition to updates too.

The toggle in control centre does not disable Bluetooth. It disconnects Bluetooth until tomorrow. It even says that in control centre when you tap on the toggle.

It’s impossible to permanently disable Bluetooth on iOS. Every iOS update re-enables it.

Same on MacOS. It got to the point where I made a start up script to check and disable Bluetooth.

Apples official stance is that this behavior “functions as intended”.

https://lapcatsoftware.com/articles/bluetooth.html

To be fair, the default behavior does exactly what I want: Disconnect me from a broken Wi-Fi network/Bluetooth headphone/speaker implementation that is hijacking my audio output, without breaking "Find My", Airdrop or Wi-Fi geolocation.

AirPods can stay connected, which is maybe unfair towards third-party vendors, but they also don't insist on connecting to all paired devices at once and usually pick the two wrong ones and steal audio from whoever in my home is using that device at the moment.

Make a shortcut to disable or enable and add that shortcut to your Home Screen

Seems like the flag defaults to true since December 7 (Fedora 38) with bluez v5.70-4:

    $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
    * Thu Dec 07 2023 Peter Robinson <pbrobinson@fedoraproject.org> - 5.70-4
    - Add mitigation for CVE-2023-45866

This seems correct, however 'ClassicBondedOnly=true' is commented out in '/etc/bluetooth/input.conf' in Fedora 39 with bluez v5.70-4 anyways.

Presumably so you can't turn it off simply by uncommenting the line. The default is defined in some source file.

Mine says

  # Defaults to true for security.
  #ClassicBondedOnly=true

(which is the patch indicated)

I don't follow your point.

Generally commented out lines are defaults, right?

Often yes, but not always. Here both the default is mentioned and a commented line is offered (I like commented lines as they show a proper format).

  # Set idle timeout (in minutes) before the connection will
  # be disconnect (defaults to 0 for no timeout)
  #IdleTimeout=30

Android: disable Bluetooth when you're not using it (but you'll be vulnerable while you are).

Page says it only works for stuff that doesn't require password or biometrics.

I actively lock my phone when not using it, and surely I'd see the activity of the keystrokes being sent when using my device, no?

In that case it doesn't seem that horrible to leave Bluetooth enabled.

surely I'd see the activity of the keystrokes being sent when using my device, no?

That was my first thought as well. Then I remembered how much time my device spends in my pocket or on my nightstand

Right, but can it enter keystrokes when the device is locked? As in use the device "behind" the lock screen?

I don't have a device lock because I keep the thing on my body and anyone violating that will also get the password anyhow and I don't want to have to authenticate a million times a day. That logic worked until now I guess :/

Does this even work without pairing?

Not sure. Doesn't the iphone lock you out for a day if you enter your pin wrong too often? If that pin-entering can be done via bluetooth.... More a prank than an attack, but still quite annoying.

I don't have an input.conf file on my OnePlus phone. There are bt_stack.conf and bt_did.conf in the same directory though.

iOS: https://support.apple.com/en-us/HT214035

macOS: https://support.apple.com/en-us/HT214035

Both say:

Impact: An attacker in a privileged network position may be able to inject keystrokes by spoofing a keyboard Description: The issue was addressed with improved checks.

I always hated that after an ios update bluetooth always came back as enabled... when I never actually used it... this puzzled me for a long time......

also, the emmentaler like wifi cannot be fully turned off from the control panel either

disable Bluetooth when you're not using it (but you'll be vulnerable while you are

As someone with bluetooth devices (Smartwatch, buds, headphones, glasses etc) this is...difficult lol

Ubuntu 2022, the default appears to be true already:

# Defaults to true for security. #ClassicBondedOnly=true

Any idea how to tell if grapheneOS fixed this in its sunfish (4a) branch? I'm stuck on android 13 with a 4a and I need Bluetooth to open my car door. If graphene fixed this, it would spur me to finally move to it. I just can't justify getting a new phone when this one works fine.

I'm really glad I went with a Pixel!

Honestly, I'm not surprised. Bluetooth is an unsecured microcontroller that does not run an open source firmware (and yes, I'm aware, the CVE is partially enabled by the software stack as well). By definition, that is a security nightmare.

I don't generally use Bluetooth devices in my house. Between the security nightmare aspect and the fact that it's always a worse end user experience than just going wired (no dropped packets, no failure to pair after being paired fine for months, no batteries slowly dying and then becoming spicy pillows; just 100% pure glorious wire).

Wireless keyboard generally seem like a totally terrible idea, just waiting for hacks. The author mentions not going after wireless gaming keyboards because they were the “wrong kind of mess,” I assume, security through abstrusity :)

I never really understood the benefits of a wireless keyboard. Do people usually carry their keyboard from their desk with them when they take their laptop somewhere else?

I guess I could maybe -- maybe -- see the convenience if you have some sort of small-form-factor keyboard that you stash in your bag. But still, the wire doesn't seem like much of a burden, and personally I'd find the annoyance of needing to ensure the batteries are charged/fresh to be... more annoying.

I can kinda see how a wireless mouse would be nice; the wire can get in the way of mousing around sometimes. But I'd still rather a wired one than wireless.

A laptop by default is not suitable for working any substantial length of time due to the fixed coupling between its screen and keyboard. Separating them—so that you can relax while keeping your screen roughly at your eye level and at comfortable distance, and your elbows bent at comfortable 90 degrees (or more)—gets you 80% there in terms of ergonomics.

You could carry around a portable display, but that might be a bit of an overkill in terms of cost and bulk. Unlike a display, a portable keyboard is lighter and often smaller than the laptop itself. Modern wireless keyboards have almost no lag, have nice mechanical keys with replaceable keycaps, etc.

Working away from a stationary setup, I consider a separate keyboard a must—and particularly a wireless keyboard, since the one thing that reliably breaks on every laptop is physical I/O, especially USB/USB-C ports (and every time plugging/unplugging another accessory brings that closer).

Working with a stationary setup you have a detached keyboard anyway, and if it’s wired you don’t really need to unplug it, like, ever, so a wireless keyboard loses a lot of its advantages—though if you have a really large screen and have a lot of leeway for moving your chair around for comfortable work not having cables get in the way might be nice as well.

I find the notion that wires are less reliable than wireless extremely contrary to my own experience.

That’s not what the parent said. The wired connection itself is better, but it has the tradeoff of physical wear and tear and ports that break.

Right, but I count both as reliability, and while I've had wireless connections be flaky tons of times, I haven't had a physical port break yet.

Either you mean a desktop machine, or I envy you. Every one of my laptops had developed issues with physical I/O (be it ports, keyboard, trackpad). The one I especially hate is flaky USB ports that make external HDD spontaneously disconnect while being heavily used, like copying many files over (and it’s not a power issue as it happened both while laptop is powered and with HDDs that have their own dedicated power).

Ah, I use a Framework, so if (when?) a physical port goes bad, I can just replace it for $10 or whatnot. I've never had issues like you mention, though.

The most flaky removable thing I've encountered is microSD cards, and I don't know if it's the card or the reader, but they tend to only work half the time. I even check them for authenticity of space, so I don't know why they're so flaky.

My previous laptop had indeed its SD slot borked at some point (part of why I don’t care that my new laptop lacks it—I would just not expect it to work reliably, so why have another dust collection point). My first laptop’s keyboard had very occasionally working keys in the middle (I blame my pianist fingers bashing them too hard)—I count that as physical I/O, though not a port issue.

Is it easy to source replacement I/O boards for Framework?

Yes, but wireless wouldn't have saved you with the latter.

Sure, as long as the keyboard is separate (wired or not) bashing it would have saved the built-in keyboard for a rainy day.

You may want to get one with replaceable switches, I built one and had one or two switches go bad after a few years, I popped them off, plugged new ones in, and that was it. Lifesaver.

Much respect for people building keyboards (a colleague’s done it as well). Since I’d love to have a compact split one (whether wired or not), and apparently it’s quite hard to find them pre-built and in stock, it looks like I’d have to get into building them as well. It’d be a while though, gotta move to a bigger place to have the space to build anything at all.

But on the original topic, it appears that modern wireless keyboards fare well enough as far as connection and latency[0] to qualify for gaming, so I wonder if your impression about connection reliability could be a bit outdated?

[0] https://www.rtings.com/keyboard/reviews/logitech/g715#test_6...

A friend builds wireless keyboards, so I guess they must be fine now with ZMK, but the issue I had with mine and QMK was that I never knew if the battery was dying or if the keyboard was just being flaky. I switched to wired and never looked back, but, to be fair, it is for a desktop computer.

I would not argue that wired is more reliable in terms of connection. It’s just that if you’re working at a laptop then connection reliability competes with wear and tear, ergonomics, and outlier scenarios like “trip on a cable and brick your work machine” (e.g., by spilling coffee or dropping it). In case of a desktop, connection reliability only competes with ergonomics, and to a much lesser extent—I can see myself using a wired keyboard at a desktop, perhaps even a split one (and that’s an additional wire).

Anecdotally, I don’t tend to run into connection issues with wireless keyboards—I do with wireless mice, however.

Hm, yeah, laptops are a bit difficult ergonomically. For me, just the hassle of "this is misbehaving again, is it the battery or interference?" is enough to prefer wired everything, but I get your point about wear and tear.

Luckily, in USB-C, the springy bit is in the cable, so that's where the wear and tear is. If it stops working, the cable is generally easy to replace.

I’ve had many similar issues with ports, to be honest. Just recently had to get the I/O board swapped on an M1 MBP—one day it decided that one of the USB ports wouldn’t connect 80% of the time. It was relatively inexpensive to do officially even without the warranty (around US$60 all in all), and took just a couple of days, to be fair.

Huh, maybe I'm an outlier. Maybe it's the way you remove your connectors? Some people tend to wiggle them side-to-side, I touch the chassis with my thumb and index finger around the USB, and kind of roll my fingers so they put pressure against the chassis. That leads to the removing force vector pointing strictly straight out of the connector, and I've never had a problem with any port.

Past me was definitely careless. Current me—doubtful, or at least I’d like to think I’d have learned to be nicer to ports…

I touch the chassis with my thumb and index finger around the USB, and kind of roll my fingers so they put pressure against the chassis

This doesn’t work when you have two ports in close proximity and one of them is occupied. In that scenario I’d have to either lift the laptop in order to squeeze the connector from top & bottom while removing (this option requires not being exhausted or lazy) or pull on a cable a bit further away from the connector (though I do it gently nowadays, pushing with another finger against the chassis for at least some balance).

My cats insist on sleeping on the desk, so wireless keyboard & mouse is a must for me so I can navigate around cats.

They all is USB-C charged so I use a single charger cable for macbook, gaming controller, keyboard and mouse.

Which is how a cat chose your username. I know how that feels.

true story

I wish I had USB-C charged cats. Imagine savings on food...

I don’t see how people can STILL use wired nowdays. It’s so much less desk clutter and vastly better aesthetics to go full wireless.

Charging is not an issue, get some Logitech that lasts months if not years.

Not everyone cares about the aesthetics of their tools or shares your sense of aesthetics (minimalism). Furthermore: OP and things like mousejack are exactly tbe reason why some people will not use a wireless input device.

Keyboards are used to enter secrets so they rank pretty high in my threat model.

That sounds a little paranoid, especially when you have options for factory paired keyboard/dongle encryption.

And aesthetics? This is a forum that tirelessly obsesses over micro usb vs usb-c. Wired is de facto obsolete afaiac.

If you're using an external display, your display might not be near your computer.

In that case, you likely want a wireless keyboard and mouse to use it.

Do people usually carry their keyboard from their desk with them when they take their laptop somewhere else?

Yes, absolutely. Having your keyboard right next to your screen is terrible ergonomics. Fine in a pinch or during a meeting, but not for working for hours.

The Magic Keyboard slides right into my bag, and I use it on my lap while my laptop sits on a table or airplane tray. It's incredibly more comfortable. I have long arms and it's literally impossible to type on a plane otherwise, without elbowing seatmates in the ribs. If I'm working somewhere remote that's more private, I use a tiny collapsible stand that raises the laptop display closer to eye height as well. (Don't want to attract weird attention like that in a coffee shop though.)

The only case I like for it is, I’ve got a windows computer that I plug into the TV for gaming (glorified console really). It is nice to not have wires across the room.

For some reason Bluetooth has to be enabled for Android Auto to work, even though it's wired, so I leave it enabled. But there should be a way to just disable keyboards categorically, for phones.

Doesn't Android Auto carry audio over Bluetooth? That would be consistent with how unreliable the audio is.

Hey don’t knock it until you’ve tried Apple’s equivalent (wireless CarPlay) which has a 3 second buffer since they decided to use Wi-Fi for audio. Imagine if every time you play or pause or change tracks you have to count to three in your head before it responds.

Yes, I’m bitter. Somehow the video and touch are lag-free 1 but the audio is on a delay. I’d love to have regular Bluetooth audio be used.

Wait, what? Wifi? Does that mean that a car that has CarPlay must also have Wifi that can act as an access point, and do some sort of automatic connection negotiation when the phone is plugged in and CarPlay is activated? That seems... terrible.

Wireless CarPlay didn't show up until several years after the original USB-based CarPlay, which is still around and there may still be new vehicles on the market which only support the USB-based CarPlay. Wireless CarPlay starts with a Bluetooth connection which is then used to negotiate the higher-bandwidth WiFi link. Neither CarPlay nor Android Auto can operate on Bluetooth alone, because the video data that needs to be streamed far exceeds what Bluetooth can handle.

It’s a point to point link too, not standard access point style.

Your 3-sec delay issue sounds more like AirPlay 1 vs AirPlay 2 issue to me.

AirPlay 1 has this delay (or more like 2 seconds to be fair), while it is reduced to like 200ms on AirPlay 2.

shairport-sync runs on a raspberry AND supports airplay 2. You can hook it up to your car.

Regular Bluetooth audio isn't guaranteed to save you there. My car has a 6 second delay on the Bluetooth audio.

since they decided to use Wi-Fi for audio

Choosing to buffer for 3 seconds isn't the fault of wifi. There is no reason it couldn't start playing in a few milliseconds.

That’s why always use wired CarPlay despite having wireless support.

I don't know. What's the wire for? Needing both the USB cable and Bluetooth has always struck me as pretty dumb.

The bluetooth connection is for phone calls. The rest of functionality works over the wire. As for the why does it need bluetooth at all, no idea.

Needs to be bluetooth so the handsfree controls on the steering wheel work without an outrageous degree of coupling.

If it's anything like CarPlay, it's absolutely NOT bluetooth.

As is the baseband, or the Wi-Fi chip, or most of the other components in a modern phone.

Proper hardware isolation (e.g. using IOMMUs) should be able to mitigate many of the resulting problems – and if the OS can be compromised using the software driver stack, that is indeed a problem of the OS/driver.

This doesn't mention Windows at all.

That sounds great on the surface, but it would be really helpful to understand why Windows is not actually at fault so I can better measure the risk profile.

For example, knowing that the Windows Bluetooth stack has the architectural equivalent of BlueZ's `ClassicBondedOnly=false` would be really helpful to know; that would tell me to keep an eye out for it being `true` in environments I'm trying to harden, for example.

Alternatively the stack might work entirely differently and the status quo might consist of a different set of considerations to keep in mind.

This is awesome and I'm looking forward to the PoCs and (pleeease) video with lots of demonstrations :)

But Windows has enough market share and enough sysadmins are going to be going "!!!...???" that some info would be helpful.

That info might be "I haven't attacked Windows yet". That would be good to know too :)

Because Bluetooth barely works normally for Windows

I know it's a popular trope on HN to say nothing on Windows ever works but anecdotally I've been using Bluetooth on windows for over 10 years now from 7 to 11, and never had any issues whatsoever that were related to Windows itself.

The only issues I have are Bluetooth disappears after wake from sleep which after research appears to be due to buggy firmware of the Mediatek network card installed in the laptop and not due to Windows, as the same issue happens at wake from sleep in Ubuntu.

And another issue was due to the device used being a Chinese no-name bootleg e-waste piece of crap off Amazon. Ironically never had any issues with Bluetooth earphones off AliExpress.

So YMMV.

I’ve had a ton issues on Windows with Bluetooth and I know it’s not the hardware because on Linux it works fine.

My Xbox Series controller is the biggest issue. For instance will not automatically reconnect when I pair it the first time and then disconnect. On the next turn on of the controller, it never finds the PC and connects. Windows then has no push for me to press to connect.

I have to delete the controller and then repair it each time. Sometimes I can’t even delete it and have to go into RegEdit and delete it. The delete button just does nothing sometimes in that menu

I've experienced Bluetooth issues like that before on Windows. 100% of the time it's been solved by using a better Bluetooth adapter. I don't have any issues after using actually good Bluetooth adapters, such as modern Intel ones.

I could do that, but I’m using the built in Bluetooth on my desktop. Honestly, I’m just annoyed with Bluetooth and windows. Everything else not based on Windows work completely fine, from macOS to my multiple linux desktops

That's like arguing graphics suck in Linux compared to Windows because your 4090 in Windows works great but your CGA adapter you use on your one Linux desktop isn't that great. You're not doing a real comparison of like hardware, you're comparing different adapters across different OSes.

True, but I can’t feasibly rip out my wireless adaptor on my motherboard and connect it to my Mac.

Linux was running on the same hardware that windows was because I wanted to utilize my 4090 for some machine learning projects, so yes, there was an apples to apples comparison

Are your Mac and Linux desktops using the same Bluetooth adapter as your Windows machines? If not, then maybe you do have an adapter issue and it's not the OS.

Linux and Windows are on the same machine. I can’t rip out my motherboard’s adaptor to connect it to my Macs

When people say that Linux works flawlessly with the right hardware, people also often don't seem care.

Side note, have you tried a firmware update with the Xbox controller, inside the Xbox app for Windows? It helped me a lot, especially earlier generation / early production units.

(But yes, I always have issues with Bluetooth on Windows too)

I have, it’s on the latest firmware from the Xbox app. Still have these issues, the Xbox controller is just the biggest thing, my Sony headphones also have issues with Windows.

All of my coworkers have issues with anything regarding Bluetooth on Windows too

Yeah, I feel ya :/ My Xbox controller works better on a Mac than it ever it did on my Surface Book. Ironic.

For what it’s worth, I had a similar experience with my old Xbox controller. I bought a new one and the issue went away.

Could be one of two issues here. Either your old controller could have been faulty, or the other one, the new controller has a firmware update or HW revision that fixes the issue your old one had. Impossible to know without deeper dives in HW & FW revisions.

For me, it never went away. I had an Xbox One S controller before with the same issue. Bought the Xbox Series controller last year for Elden Ring, same issue on Windows. Gave up, and just got a longer USB C cable.

The Xbox is a popular controller so its Bluetooth connection issues on windows should be well documented online by multiple users by now if it's a known issue. Or is it just you and a handful of unlucky users due to some buggy Bluetooth card-driver combo?

There are a lot of short straws you can pull in the Bluetooth stack lottery that don't necessarily stem from the OS.

A few of friends also have this experience with the controller. Nobody bothers to say anything though and they all told me that I’d just be better off plugging it in. Which is what they do and what I ended up doing

I've used an original Xbox One Bluetooth controller on Windows with about a dozen different Bluetooth adapters. I've never had problems. I also used a Bluetooth Xbox 360 controller before and once again didn't have issues. I also use a GuliKit Zen Pro controller without issues across close to half a dozen different Bluetooth adapters without issue. All in Windows.

I'd be interested in knowing what version of Windows you're using. Bluetooth has had a lot of updates in the past few generations of Windows.

I understand the desire to use Bluetooth, but there is a (relatively) cheap $20 adapter that uses a protocol and frequency more similar to WiFi I believe (like arctis gaming headsets if you’ve ever used those) which works much better. My experience with Bluetooth has always worked as far as connecting is concerned, but I had to use a TP Link Bluetooth adapter and disabled the motherboard Bluetooth to tell windows to use TP (it won’t assume for you). Even after being connected, I don’t think standard Bluetooth has the proper latency and bandwidth for the controller to work reliably in a crowded airspace (I live in an apartment). I will get small skips and latency spikes from time to time. The Xbox adaptor for PC makes it work basically just as effectively as connecting to an Xbox, with the only caveat being it will overheat pretty easily if you place it near an exhaust vent on the PC and are pumping hot air all around it. I put it on the front of my case and it stays cool enough there to work reliably.

I’ve had a ton issues on Windows with Bluetooth and I know it’s not the hardware because on Linux it works fine.

This isn’t enough to tell you it’s not the hardware: you’d still need to check that it’s not, say, Linux being more tolerant of errors or not supporting a particular feature that the other stack is using. I know at least one person who had some long rant like that about audio, and then updated their Linux distribution to find that the newer bluez failed the same way.

I agree. In Windows whenever I need to connect my BT headset I have to re-pair it, otherwise I get just speakers, no mic.

I think you mixed up Windows and Linux. Or maybe both have their share of problems. Or maybe it is, as some people here say, impossible to implement Bluetooth properly.

As someone who used a bluetooth mouse with Windows for the past few years, have to disagree

And Bluetooth got quite a bit better on Windows 11 after the new audio profile thing is available

Can't be affected by an attack vector if the vector doesn't work to begin with, clever.

I believe it's because they just didn't bother trying this on Windows (yet)

Do you believe that, or do you actually know that because he said it somewhere?

If you look at the linux patch[1] it's a case of bad defaults. So maybe Windows just has good defaults?

[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

I think "insecure default" or even "wrong default" is more fitting in this case.

knowing that the Windows Bluetooth stack has the architectural equivalent of BlueZ's `ClassicBondedOnly=false`

Did you mean “ClassicBondedOnly=true”?

Maybe this particular hack isn’t vulnerable to Windows.

But, with my Flipper Zero I can create a bluetooth device and as soon as a Windows client connects it will think it’s a keyboard and fire whatever powershell commands I want.. I have only used it to do a RickRoll myself (spawning Youtube), ai haven’t tried anything illegal with it.

Now I have all of my bluetooth disabled. But, I don’t know how to remove bluez without breaking linux.

Once the attacker has paired with the target phone or computer

A small detail, though, the target device has to accept the connection. Once someone lets you in his house, you can steal his silver, yes.

How in the world is this a CVSS 8.8 if this is the case? What a waste of everyone's time if this is true.

Ctrl+alt+t (insert malicious shell command)

Ok, but any reasonable threat model has assumed forever that physical access to the machine is essentially game over regardless.

Or to put it another way... who cares about that when the adversary is in position to just do a snatch and grab of the whole device?

Wireless protocols don't count as physical access, since I can perform the attack from a car outside your house.

This is an automatic bluetooth pairing attack. With the right equipment (which can be as simple as a Pringles can and an antenna aimed through a window) you can execute this attack from a hundred meters away. That's not physical access.

That is only part of the CVSS scoring system. Not only do you need near-physical access (i.e. not open to the internet, already drops the rating significantly), it requires the victim to interact with a suspicious prompt, which basically drops it to the level of a phishing email (i.e. not CVSS 8.8).

Even more scary: (launch child porn web site)

The vulnerabilities work by tricking the Bluetooth host state-machine into pairing with a fake keyboard without user-confirmation.

Is this possible to pair a keyboard device to Android without confirmation?

If the vulnerability author is to be believed, yes.

It's apparently a feature of ancient Bluetooth

People are silly about security. Has your social media not been flooded with oldsters circulating that copypasta about how iOS contact sharing is going to let thieves "STEAL YOUR INFO!!1?!111"?

So you are saying this is not true? You mean they got Google to react to a made up vulnerability? Did you even read the text?

They’re not talking about this. They’re talking about the NameDrop feature added in iOS 17. The one with multiple confirmation steps, while the facebook memes talk like hackers can steal your info from long range with no intervention.

https://www.snopes.com/fact-check/iphone-namedrop-warning/

Ah thanks for the context

Yes, i am reading the title which says 'Bluetooth keystroke-injection' which is concerning on one level, but in fact the article talks about authenticating a device without user interaction which seems way more serious to me.

however, it also mentions > stay tuned for Part 2: More Vulnerabilities

so I guess we'll see

This is great news now that the industry phased out physical audio connection on phones in favor of wireless. Good job, guys.

This vulnerability is about injecting keystrokes into connected wireless keyboards and mice.[1] With the phone industry adoption of USB-C, they've made wired easier than ever before.

[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

What does this have to do with the fact that now people have to switch on bluetooth for audio, instead of having a cable connection? And an attack requiring a physical cable connection is a little bit more visible, and less viable if I have my phone in my hand, than a wireless attack via bluetooth, don't you think?

You don’t “have to” switch to only wireless. There are plenty of inexpensive usb-c DACs and even the overpriced Apple usb-c to 3.5mm adapter is a whopping $9.

Yet you reply with snark? Be the change you want to see in this world.

My phone has both audio jack and USB-C.

This comment is generating far more snark than the parent to be frank.

Not everyone wants to use a USB-C dongle so they can use their old 3.5 headphones, and even more people don’t really care about being able to have a mouse and keyboard on their phone in the first place.

If you want me to show you what the “thoughtful discussion” is: The parent made the point that phone companies have been following a trend of locking down physical access in favor of wireless tech. I’ll add that this has not only removed beloved features, but now that everyone is being forced down the Bluetooth/wifi stack we are far more susceptible in public when exploits like these rear their ugly heads. There are roundabout solutions like using a USB-C dongle but… really? Does anyone find that to be effective at all? What about when you want more than one connection? You need a splitter or a hub. It’s just such a seemingly useless “improvement” if it feels like we’re going backwards having to buy extra stuff.

If you want to reply with your disagreement, please do so in a thoughtful manner. Please think before you post. I come to this website not for snark, but for thoughtful conversation ;) Ty

This is great news now that the industry phased out physical **audio** connection on phones in favor of wireless.

I recognize that there’s still wired audio connectors but you know full well that the experience is not great because the industry wanted to remove audio jacks.

USB-C DACs are inexpensive and widely available.

Well iOS and macOS are only vulnerable in a very narrow range of conditions. On the other hand Android is a field day.

And I believe these were patched in the current versions of iOS and macOS.

I read the original article to find the narrow range of conditions. It states "iOS and macOS are vulnerable when Bluetooth is enabled and a Magic Keyboard has been paired with the phone or computer" so does this mean if a computer has ever paired with a Magic Keyboard, it would allow itself to be paired with additional keyboards that the user did not want to pair?

As someone who has bought multiple Magic Keyboards, this definitely concerns me.

I’m sort of assuming the Magic Keyboard has to be present, but we don’t know that based on the write up. It’s a great question though. All desktop Macs come pre-paired with a Magic Keyboard even if you never use it. so if the keyboard doesn’t have to be actively connected at the time that would make them all vulnerable unless someone had unpaired them.

The other thing that wasn’t clear to me is if the vulnerability exists if a Magic Keyboard isn’t in the mix. If I have never paired one to my laptop and instead I am use a different brand of Bluetooth keyboard is it still a problem?

In other words is this Magic Keyboard specific? I’m assuming the author had other Bluetooth keyboards. Of course even if it is that doesn’t mean there aren’t other vulnerabilities lurking in iOS/macOS in this area.

Alas, merely guessing, but it sounds like you can tell an apple device "I am the magic keyboard you know and trust" and it will believe you.

Wouldn't that require knowing/guessing/brute-forcing a unique device identifier that's probably not available to be sniffed if the genuine keyboard in question isn't in use?

Perhaps there is a bug and the unique identifier isn't checked.

That was sort of the impression I got. It’s not that Apple is doing something unfixable, it’s that they have a bug that enables something that shouldn’t happen.

Still guessing here, but if I have a Magic Keyboard paired to my computer right now and I’m using it, is there any reason to let a second Magic Keyboard automatically pair itself?

If your Bluetooth device pretends to be the second Magic Keyboard and automatically pairs it could start injecting keystrokes. That seems like it would fit the description here.

Maybe (or maybe not) that involves pretending to be the first Magic Keyboard. Apple makes their stuff, they KNOW that no to have the same serial number (unlike some cheap stuff you can buy). But if they don’t protect against that…

Apple's "Magic Keyboard" is supposed to exchange Bluetooth keys with a MacOS host over its USB/Lightning cable the first time it gets plugged in.

Perhaps default pairing is left open to allow smoother pairing with iOS/iPadOS, as pairing otherwise would have required a cable with Lightning connector in both ends — which I don't think exists.

I was pretty surprised to see that Linux/BlueZ is only vulnerable under a very specific, rare situation. And fixing it for that situation doesn't even require a patch, just a small change to a configuration file. BlueZ (and its related GUI tools) otherwise is a usability nightmare. At least it's decently secure?

Oh snap, here we go again, convenience vs security, zero sum game.

Maybe lazy convenience vs security? Apple has a rather nice, convenient way to pair a keyboard that ought to resist unauthenticated injection.

The issues here appear to just be bugs.

According to the write-up, the vulnerability itself was fixed years ago in BlueZ, but left disabled by default for compatibility. I'm not sure about the macOS vulnerability, but at least on the Linux side, usability beat security.

To be fair, the Linux/BlueZ stack is only vulnerable while the adaptor is set to "discoverable" mode, which should be rare, and should only happen when the user sets it that way, for a limited time.

The Android vulnerability merely requires that Bluetooth be enabled, and it seems that's the case for macOS/iOS as well?

And fortunately the Linux/BlueZ issue doesn't even require a patch to fix; you can just change a boolean in a config file and restart the daemon. I never thought I'd be praising BlueZ for something, but I suppose there's a first time for everything.

According to the write-up, the vulnerability itself was fixed years ago in BlueZ

That’s the BlueZ vulnerability. Which is certainly different from the iOS/macOS vulnerability given Apple has their own BT stack.

The decision made by the Linux kernel developers and distribution maintainers not to enable the fix by default is theirs. It doesn’t imply anything about Apple’s behavior.

If Apple wasn’t aware of this, they couldn’t have made a security/convenience decision at all.

Without knowing more it seems like jumping to conclusions. The Linux maintainers may have made a reasonable decision based on possible fallout from breaking lots of devices.

Not just "convenience vs. security", also the plain old "backward compatibility vs. security". The BlueZ vulnerability was patched years ago but it was not enabled due to backward compatibility concerns:

    diff --git a/profiles/input/input.conf b/profiles/input/input.conf
    index 4c70bc561f..d8645f3dd6 100644
    --- a/profiles/input/input.conf
    +++ b/profiles/input/input.conf
    @@ -17,7 +17,7 @@
     # platforms may want to make sure that input connections only come from bonded
     # device connections. Several older mice have been known for not supporting
     # pairing/encryption.
    -# Defaults to false to maximize device compatibility.
    +# Defaults to true for security.
     #ClassicBondedOnly=true
 
     # LE upgrade security

I'm really not sure what sort of wireless keyboard to recommend at this point. If you are reading this and you make a secure wireless keyboard, please send me one so I can hack it for you.

Do I understand this correctly that the attack requires a vulnerable keyboard to be actively connected to the device? But the fix for the vulnerability is on the device side, not the keyboard side?

It's a reference back to where they stated that they used to recommend Bluetooth wireless keyboards. These attacks only involve keyboards to the extent that Apple devices have to be paired with a keyboard for them to work.

“Paired” in the sense of “the device knows this particular keyboard because it has been paired with it at some point in the past”, or in the sense of “currently connected”?

Secondly, it’s still not clear to me how a “secure” keyboard would solve the problem if the vulnerability is on the device side (which it seems to be given that it can be fixed there).

A wireless keyboard that didn't use Bluetooth wouldn't be vulnerable to this.

I didn't really try to figure it out, but I expect paired in the sense of paired, not connected. Sounds like ios toggles a setting for HID when you pair the magic keyboard an becomes vulnerable to this.

If it’s “paired” in the first sense, then merely using a non-Bluetooth keyboard is not sufficient, you also have to make sure to unpair any previously paired Bluetooth devices. It would therefore seem important to find out what precisely is the case.

I guess if you have Apple devices, yeah, it might be worth figuring it out.

Bluetooth is the gift that keeps on giving. Not sure why my Ubuntu insists on enabling it on every boot, at least on my hardware.

Good thing PC peripherals moved away from this junk. It was fascinating watching Logitech sell 300 euro BT keyboard with literally a second of lag, or "high end" mice with 500ms or more.

Hell, I barely use my PS5 controller because it sucks ass compared to my old Xbox 360 pad. Lag, lag, lag. 8 guess the majority does not notice or care, though.

That’s considerably worse than most people experience - keyboard latency is normally under 15ms - and I think that’s part of the problem there: if you live somewhere with a lot of congestion from other devices, poorly shielded microwave ovens, etc. you have a legitimately terrible experience but it’s not common enough for it to actually get fixed since it doesn’t impact sales.

Pretty sure you have forgotten or never experienced the awful bt devices from 15 years ago. Or maybe latency is not a big issue for you.

Latency is something I notice, but having used Bluetooth since it first came out, 500+ms is either a very noisy radio environment or defective hardware. It’s freakishly outside of normal for the technology - if you were seeing 5ms, maybe 10ms, that’d be within expectations but not even 50ms.

Clearly even modern devices are nowhere near 5ms but hey, let's just agree your perception is more forgiving.

Modern devices should be in the 10-15ms range. If yours are not, return them as defective.

The 5ms I referred to was the difference versus a cable - I’d expect a modern keyboard to be under 10ms and Bluetooth to be under 15ms. Since I’ve measured that the latency for a keystroke to render on screen in VSC at 16-24ms, I’m comfortable saying at least Apple has Bluetooth latency under that level.

By the way, USB is similar. If you connect a keyboard to "charging only" port, it works. Tried myself on Android. Was told off here it's supposedly not practically exploitable.

Do you only use your port on Android for charging? It's also super useful for HDMI. And, yeah, peripherals. I don't consider that a vulnerability though. It's just useful. The problem here is someone can do it without you noticing them and while you're using it for sensitive things.

https://mitxela.com/projects/smsc this cool project from yesterday he was able to use on his phone that way.

Perhaps you missed that "charging only" is a setting for when you really only want to allow charging when the charger is sus? At any other time, sure, get wild.

You said a "charging only" port, thanks for the clarification. I interpreted that as the physical port, not an android setting to filter communications on the port. I don't think I'd ever trust a random cable even with an OS config setting.

BTW. physical port charging only ports do exist.. Still wouldn't trust 'em w/ random cables though. Other end might deliver too much power if nothing else.

https://en.wikipedia.org/wiki/USB_condom

What Android device are you using that has a physical "charging only" port?

ChromeOS is the only Linux-based OS known to have enabled the fix

Once again ChromeOS is showing it cares about security more than seemingly any other end user OS. I think it's really underestimated as a platform.

I would be a lot more supportive of ChromeOS if it wasn't controlled by Google. It seems like it's mainly a vehicle to get students and others hooked on Google services and further normalize Google's brand of ad tracking and surveillance capitalism.

I had such high hopes for FirefoxOS but it got Mozilla-ed

It's really underrated; the easiest PHD (Push Here Dummy) OS I have ever used and the fact its security is top notch only makes it even better.

Yeah, Google wants to be the only one to spy on you :)

Dang it, now I guess I have to toss my out of support android phone that works fine but doesn't support lineage.

What phone? Can you not disable Bluetooth when you are not using the keyboard?

Can Bluetooth HID be disabled without disabling e.g. audio devices (breasts).

TIL that "headsets" and "breasts" are close enough on the qwerty keyboard to confuse swiping keyboards.

Usually breasts aren't audio devices, but it does occasionally happen. Good luck finding some with Bluetooth support though.

Oh maybe it can be disabled in Android? I have a smart watch that uses Bluetooth so I don't want to disable it completely. Phone is an old Samsung.

This is a pretty tremendous hack. Almost all computers are vulnerable and if you can get close enough to them you can quickly send keyboard presses to open a terminal window and install software (hopefully the password request saves you at this point).

Yes, thankfully there's a password on installing software as root

Obligatory https://xkcd.com/1200/

Running code works fine without root, at least to copy your emails, saved logins, and browser sessions file and such

Which is why I'm using Qubes OS to isolate Bluetooth from the rest of the system.

How does that work?

Qubes uses hardware virtualization to isolate different hardware, including audio stack, USB devices, into dedicated virtual machines. You do not normally run anything there except the drivers.

The vulnerabilities work by tricking the Bluetooth host state-machine into pairing with a fake keyboard without user-confirmation. The underlying unauthenticated pairing mechanism is defined in the Bluetooth specification, and implementation-specific bugs expose it to the attacker.

Why would you want to pair silently? Could someone provide more details on the intended purpose of the faulty mechanism?

In the bluetooth spec? For various non-computer things, like being able to pair your first controller to your playstation, without having to plug in an usb mouse to click ”allow pairing”

On the devices affected? Who knows

There are set-top boxes/TVs running android/linux that might have the same use-case for remotes/controllers and macOS/iOS share a lot of code with tvOS which has the same use-case. Macs ship with wireless keyboards that automatically pairs, apple even highlight this on their product page: "It pairs automatically with your Mac, so you can get to work right away." https://www.apple.com/shop/product/MMMR3LL/A/magic-keyboard-...

It's just an older design from a more innocent time, newer specifications don't allow this, but to maximise compatibility Bluetooth stacks left the new behaviour off.

Can someone walk me through the process of exploiting Android or iOS with this? I never attached a keyboard to my phones. How do I get to the app store and download an app using just the keyboard? On iOS it requires the fingerprint if I remember correctly, at least on mine. But it's for work and I do mostly very basic stuff with it, so I could be wrong.

On Android for free apps I believe the default is no password confirmation Assuming recent versions, you could press home + type "Play Store" to search and open the app, search for something and install without a password, assuming an unatended device, in my phone at least you can click to wake up the screen

Can you use "tab" to cycle through UI elements on Android or how would you navigate the app store?

the author says they can't do anything that requires further authentication. you'd need to chain this with another attack.

The Linux vulnerability was fixed in 2020 (CVE-2020-0556), but the fix was left disabled by default

Experiment flags should have a timer to auto-flip them after a few months...

This is a bad idea, and maybe if you think about it a few minutes you could come up with the reasons why, yourself.

For starters, enabling things can as easily introduce vulnerabilities as keeping them disabled. So you won nothing, created more pressure and have everyone working on top of a system that can change under their feet — a recipe for a disaster.

Release schedules are normal. That's how every deprecation scheme works: announce the change and follow through on date xyz. But I'm sure we'll see the light if only we think about it for a few minutes.

I doubt this is practical for use against phones or computers, but if you're responsible for keeping people from messing with kiosks your life just got more interesting.

I had accidentally exposed a Linux machine with a passwordless vnc to the Internet a good decade ago. A few minutes in I got someone connecting trying to run stuff via automated keystrokes that were obviously targeting Windows. You only need to successfully get a backdoor in and work from there.

In targeted cases it might be enough to send a shift key-press every minute to avoid a screen lock kicking in so you can approach the machine yourself later and "do something".

On a computer, you could conceivably hide a poisoned sudo/su somewhere and add it to the $PATH.

The Linux vulnerability was fixed in 2020 (CVE-2020-0556), but the fix was left disabled by default. ChromeOS is the only Linux-based OS known to have enabled the fix, even though it was announced by Ubuntu, Debian, Fedora, Gentoo, Arch and Alpine.

Took all of 30 seconds to verify it's in NixOS[1]. Another 30 seconds to see it was patched a week ago, at "Dec 8, 2023, 8:23 AM GMT+13", a day after the article was published (Dec 7, 2023, 10:18 AM GMT+13). :shrug:

Also, what do they even mean, if the distro announcement says to simply upgrade to fix it[2]? Do they mean that even after the upgrade you need to manually change a setting? Because the NixOS fix seems to be simply to flip the default setting. If they mean that users which have explicitly set ClassicBondedOnly=false need to change it, that could've been a lot clearer.

[1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...

[2] https://ubuntu.com/security/notices/USN-4311-1

Do they mean that even after the upgrade you need to manually change a setting?

Yes, that’s what “the fix was left disabled by default” would mean.

It’s good that it’s fixed by default now, but now is not 2020.

If you can silently pair to a phone, you can make the phone dial whatever number you want. Recently found this out when connecting the serial terminal to an earbud for repair (it wouldn't auto-connect to the other earbud).

How would you reliably unlock the phone and get to the dialer app? Given how varied home screen layouts are, even an unlocked phone might be hard to attack this way

You can always reset by tapping the home button or swiping the most recent app away or so, so you can try various UI layouts until one works. Most Androids have a settings button in the notification area and then you can find the installed apps, search for the dialer, etc. Don't need to assume a certain homescreen location.

https://nvd.nist.gov/vuln/detail/CVE-2023-45866

https://lists.debian.org/debian-lts-announce/2023/12/msg0001...

https://source.android.com/docs/security/bulletin/2023-12-01

https://support.apple.com/en-us/HT214036

https://support.apple.com/en-us/HT214035

Disappointingly, this hasn't been fixed on the prior versions iOS 16 / macOS 13.

I don't really understand how Apple can say they still support these older devices when there are known vulnerabilities which they don't patch. I just wrote something similar: https://joshua.hu/apple-ios-patched-unpatched-vulnerabilitie...

MacOS / IOS

Lockdown Mode does not prevent the attack

That is disappointing.

There is a list of stuff lockdown does. That was never in the list. So it’s not too surprising.

Are there any more details about this? I read all the comments here and the entire readme and I still don't know if I'm affected.

The author appears to be holding further details until a presentation at a conference.

I'm going to guess that Apple made some decisions here to trade off security for usability so the Magic Keyboard can "work like magic" regardless of what stage of the boot cycle, recovery mode, etc the computer is in, and this vulnerability takes advantage of that.

Looks like this has just been fixed in iOS/macOS.

If your hypothesis is correct, that Apple traded security for usability, then if the security is fixed the keyboard must be less usable, right?

Or, if no usability is lost, then maybe the hypothesis isn't correct.

Bluetooth doesn’t need to exist.

And what do you propose as the alternative? How do you think people should connect their headphones, watches, fans, etc.

iOS and macOS are vulnerable when Bluetooth is enabled and a Magic Keyboard has been paired with the phone or computer

I’d really love more details on this, especially given the Magic Keyboard pairing requirement. Surely they can disclose the exploit now that it’s been fixed?

One of the many reasons I still exclusively use wired input peripherals.

glad my hunch was right. always feel weird being the only one with wired everything... but now i can say i was righ...stubborn :p

Same idea - pretend you are a Bluetooth keyboard and send keystrokes at superhuman speeds.

This exploits the auto connect to special keyboard aspect of most OSs.

FWIW on Arch Linux it is fixed starting with bluez 5.70-2 [1].

[1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

Hi, I generated new article from your comments.

https://hntelegraph.com/post/bluetooth-keystroke-injection-v...

Note that this was fixed in macOS 14.2 and iOS 17.2:

https://support.apple.com/en-us/HT214036

https://support.apple.com/en-us/HT214035

I was intimidated by Bluetooth at the time, and just sort of assumed it was secure. I didn't try to hack any Bluetooth devices, and I recommended Bluetooth as a secure alternative to the plethora of custom protocols. It never occurred to me that Bluetooth would have trivial keystroke-injection vulnerabilities like the MouseJack protocols, so I never looked.

Oh yeah, intimidation is a strong basis for that myth that somewhere up high in the complex tech stacks there are people who know what they're doing and don't use sticks to prop up the castles built on quicksand

I use a UBPorts Pinephone as my daily driver. Sometimes I wonder about the security implications of that decision. I imagine there are WAY more vulnerabilities for a phone like mine, compared to iOS/Android. It's buggy enough from a user perspective, let alone a security one. Does anyone have any knowledge or thoughts in this regard?

My DivestOS patched this on Android 7 through 13 in the December update: https://divestos.org/pages/patch_counts