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

[kelnos]

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.

[lofaszvanitt]

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

[fellerts]

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 <[email protected]> - 5.70-4
    - Add mitigation for CVE-2023-45866

[rplnt]

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...

[magicalhippo]

> 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.

[galangalalgol]

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.

[lannisterstark]

>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

[moritzwarhier]

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.

[tesdinger]

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.

[horusthegame]

Ubuntu 2022, the default appears to be true already:

# Defaults to true for security. #ClassicBondedOnly=true

[eternityforest]

I'm really glad I went with a Pixel!

[exikyut]

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 :)

[WhackyIdeas]

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.

[wkipling]

Because Bluetooth barely works normally for Windows

[teddyh]

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

Did you mean “ClassicBondedOnly=true”?

[ComodoHacker]

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

[tungah]

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

[asystole]

USB-C DACs are inexpensive and widely available.

[slacka]

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...

[rkagerer]

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?

[nikanj]

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

[meandmycode]

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.

[jrmg]

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

[naglis]

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

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

[eviks]

> 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

[phendrenad2]

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.

[iforgotpassword]

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".

[eternauta3k]

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

[rini17]

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.

[capitainenemo]

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.

[ycombinatrix]

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

[nolist_policy]

> 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.

[l0b0]

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

[huppeldepup]

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).

[acidburnNSA]

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

[diebeforei485]

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.

[Terretta]

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.

[sneak]

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

[DiabloD3]

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).

[lxgr]

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.

[bee_rider]

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 :)

[jeffbee]

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.

[mr_mitm]

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.

[joseda-hg]

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

[ycombinatrix]

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

[55555]

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).

[nojvek]

Related https://www.theverge.com/23308394/usb-rubber-ducky-review-ha...

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.

[jesprenj]

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.