12 ms·

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

368 points by 3np 3y ago

3np 3y ago
https://nvd.nist.gov/vuln/detail/CVE-2023-45866 https://nvd.nist.gov/vuln/detail/CVE-2023-45866 https://lists.debian.org/debian-lts-announce/2023/12/msg00011.html https://lists.debian.org/debian-lts-announce/2023/12/msg0001... https://source.android.com/docs/security/bulletin/2023-12-01 https://source.android.com/docs/security/bulletin/2023-12-01 https://support.apple.com/en-us/HT214036 https://support.apple.com/en-us/HT214036 https://support.apple.com/en-us/HT214035 https://support.apple.com/en-us/HT214035
- diebeforei485 3y ago
  Disappointingly, this hasn't been fixed on the prior versions iOS 16 / macOS 13.
  - mmsc 3y ago
    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-vulnerabilities https://joshua.hu/apple-ios-patched-unpatched-vulnerabilitie...
- deleted 3y ago
  [deleted]
neverrroot 3y ago
Oh snap, here we go again, convenience vs security, zero sum game.
- amluto 3y ago
  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.
  - jeroenhd 3y ago
    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.
    - MBCook 3y ago
      > 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.
    - kelnos 3y ago
      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.
- segfaultbuserr 3y ago
  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
SpikeDad 3y ago
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.
- kccqzy 3y ago
  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.
  - MBCook 3y ago
    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.
    - tedunangst 3y ago
      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.
      - wtallis 3y ago
        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?
modeless 3y ago
> 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.
- binkHN 3y ago
  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.
- deleted 3y ago
  [deleted]
- andrepd 3y ago
  Yeah, Google wants to be the only one to spy on you :)
- kelnos 3y ago
  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.
  - mdaniel 3y ago
    I had such high hopes for FirefoxOS but it got Mozilla-ed
DiabloD3 3y ago
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).
- jeffbee 3y ago
  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.
  - wtallis 3y ago
    Doesn't Android Auto carry audio over Bluetooth? That would be consistent with how unreliable the audio is.
    - jeffbee 3y ago
      I don't know. What's the wire for? Needing both the USB cable and Bluetooth has always struck me as pretty dumb.
      - pepelotas 3y ago
        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.
        TylerE 3y ago
        Needs to be bluetooth so the handsfree controls on the steering wheel work without an outrageous degree of coupling.
Andrex 3y ago
[flagged]
- xp84 3y ago
  It seems like it had no competitors though, why wouldn’t it have become a standard? Without it, we would only have proprietary incompatible wireless everything. I’m happy enough with most of my Bluetooth things.
- CompYOUT 3y ago
  [flagged]
- tux2bsd 3y ago
  [dead]
naglis 3y ago
FWIW on Arch Linux it is fixed starting with bluez 5.70-2 [1]. [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bluez/-/commit/47e9592b1b322c54bdb094238f52fa20513c624b https://gitlab.archlinux.org/archlinux/packaging/packages/bl...
CompYOUT 3y ago
[flagged]
exikyut 3y ago
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 :)
- ComodoHacker 3y ago
  I believe it's because they just didn't bother trying this on Windows (yet)
  - SCdF 3y ago
    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/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675 https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
    - SpaghettiCthulu 3y ago
      I think "insecure default" or even "wrong default" is more fitting in this case.
- wkipling 3y ago
  Because Bluetooth barely works normally for Windows
  - 3y ago
diebeforei485 3y ago
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.
- deleted 3y ago
  [deleted]
- Terretta 3y ago
  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.
  - diebeforei485 3y ago
    I have no idea if usability with bluetooth keyboards is affected in different boot states. It certainly isn't affected during normal use, but I don't know about the various recovery modes. Considering the amount of time they took to release this, I assume they figured out a way to get it to work in those various cases after a lot of engineering effort.
deleted 3y ago
[deleted]
DeathArrow 3y ago
>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.
- clort 3y ago
  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
- overstay8930 3y ago
  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.
  - Koffiepoeder 3y ago
    Ctrl+alt+t (insert malicious shell command)
    - TylerE 3y ago
      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?
      - stavros 3y ago
        Wireless protocols don't count as physical access, since I can perform the attack from a car outside your house.
      - jeroenhd 3y ago
        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.
sneak 3y ago
One of the many reasons I still exclusively use wired input peripherals.
kelnos 3y ago
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.
- rplnt 3y ago
  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...
  - haraldooo 3y ago
    Am I missing something? Swipe from the top, tap to disable BT?
    - hybridtupel 3y ago
      That’s unfortunately only disconnecting until the next day (see text appearing above when pressing).
    - rplnt 3y ago
      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.
      - cma 3y ago
        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.
acidburnNSA 3y ago
Dang it, now I guess I have to toss my out of support android phone that works fine but doesn't support lineage.
- dotancohen 3y ago
  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).
  - dotancohen 3y ago
    TIL that "headsets" and "breasts" are close enough on the qwerty keyboard to confuse swiping keyboards.
    - rezonant 3y ago
      Usually breasts aren't audio devices, but it does occasionally happen. Good luck finding some with Bluetooth support though.
  - acidburnNSA 3y ago
    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.
tommiegannert 3y ago
> 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...
- atoav 3y ago
  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.
  - Aachen 3y ago
    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.
souffian 3y ago
[dead]
phendrenad2 3y ago
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 3y ago
  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 3y ago
  On a computer, you could conceivably hide a poisoned sudo/su somewhere and add it to the $PATH.
  - deleted 3y ago
    [deleted]
teruakohatu 3y ago
MacOS / IOS > Lockdown Mode does not prevent the attack That is disappointing.
- MBCook 3y ago
  There is a list of stuff lockdown does. That was never in the list. So it’s not too surprising.
nolist_policy 3y ago
> 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 3y ago
  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/3dda6d5ed56af34534dd4cdcdd85627df25aec55/pkgs/os-specific/linux/bluez/default.nix#L45-L50 https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c... [2] https://ubuntu.com/security/notices/USN-4311-1 https://ubuntu.com/security/notices/USN-4311-1
  - amarshall 3y ago
    > 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.
  - yencabulator 3y ago
    The NixOS change seems to be still stuck in staging-23.11, and not released: $ git log --grep=CVE-2023-45866 origin/nixos-23.11 $ git log --grep=CVE-2023-45866 origin/staging-23.11 ^origin/nixos-23.11 commit 8ba508ba10d27f61fe9f40eb8513d8d0864fbe14 Merge: f5cf92f30bd7 8fb1486901a3 Author: Martin Weinelt <hexa@darmstadt.ccc.de> Date: 2023-12-11 13:02:10 +0100 Merge pull request #272751 from leona-ya/backport-272672-to-staging-23.11 [Backport staging-23.11] bluez: apply patch for CVE-2023-45866 commit 8fb1486901a3f4e7cbdee5616f7d1a39a5dc7a99 Author: Leona Maroni <dev@leona.is> Date: 2023-12-07 13:44:59 +0100 bluez: apply patch for CVE-2023-45866 (cherry picked from commit 7d7f66dfba9f239f15aaec6512afb3443bbae915)
rkagerer 3y ago
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 3y ago
  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
  - SahAssar 3y ago
    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-with-touch-id-and-numeric-keypad-for-mac-models-with-apple-silicon-us-english-black-keys https://www.apple.com/shop/product/MMMR3LL/A/magic-keyboard-...
- meandmycode 3y ago
  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.
huppeldepup 3y ago
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).
- yonatan8070 3y ago
  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
  - Aachen 3y ago
    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.
  - huppeldepup 3y ago
    That's not what I mean. You can instruct the phone - over bluetooth, within the bluetooth functionality - to dial a number. No lock screen or dial app to access.
eviks 3y ago
> 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
jesprenj 3y ago
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.
- MBCook 3y ago
  The author appears to be holding further details until a presentation at a conference.
yunohn 3y ago
> 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?
beebeepka 3y ago
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.
- acdha 3y ago
  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.
  - beebeepka 3y ago
    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.
    - acdha 3y ago
      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.
      - beebeepka 3y ago
        Clearly even modern devices are nowhere near 5ms but hey, let's just agree your perception is more forgiving.
        3y ago
tungah 3y ago
This is great news now that the industry phased out physical audio connection on phones in favor of wireless. Good job, guys.
- slacka 3y ago
  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/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675 https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
  - chalsprhebaodu 3y ago
    > 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.
  - davrosthedalek 3y ago
    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?
    - deleted 3y ago
      [deleted]
    - punkybr3wster 3y ago
      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.
  - core_dumped 3y ago
55555 3y ago
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).
- Aachen 3y ago
  Yes, thankfully there's a password on installing software as root Obligatory https://xkcd.com/1200/ https://xkcd.com/1200/ Running code works fine without root, at least to copy your emails, saved logins, and browser sessions file and such
  - fsflover 3y ago
    Which is why I'm using Qubes OS to isolate Bluetooth from the rest of the system.
    - wayvey 3y ago
      How does that work?
      - fsflover 3y ago
        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.
sim7c00 3y ago
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
mr_mitm 3y ago
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.
- ycombinatrix 3y ago
  the author says they can't do anything that requires further authentication. you'd need to chain this with another attack.
- joseda-hg 3y ago
  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
  - mr_mitm 3y ago
    Can you use "tab" to cycle through UI elements on Android or how would you navigate the app store?
    - joseda-hg 3y ago
      You can, I just tested, 2 tabs + Enter get you writing on the Search Box A surprising amount of keyboard shortcuts work on android, Alt+Tab works to get Recent Activities, Directional keys let you move aroud elements, even the special keys like home/calculator work But there's a lot of unintuitive stuff, back button is Windows + Del
2devnull 3y ago
Bluetooth doesn’t need to exist.
- s3p 3y ago
  And what do you propose as the alternative? How do you think people should connect their headphones, watches, fans, etc.
rini17 3y ago
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 3y ago
  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 https://mitxela.com/projects/smsc this cool project from yesterday he was able to use on his phone that way.
  - rini17 3y ago
    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.
    - capitainenemo 3y ago
      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 https://en.wikipedia.org/wiki/USB_condom
- ycombinatrix 3y ago
  What Android device are you using that has a physical "charging only" port?
  - rini17 3y ago
    Not physical, software switch.
layer8 3y ago
> 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?
- maxerickson 3y ago
  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.
  - layer8 3y ago
    “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).
    - maxerickson 3y ago
      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.
      - layer8 3y ago
        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.
jrmg 3y ago
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/HT214036 https://support.apple.com/en-us/HT214035 https://support.apple.com/en-us/HT214035
_rdvw 3y ago
My DivestOS patched this on Android 7 through 13 in the December update: https://divestos.org/pages/patch_counts https://divestos.org/pages/patch_counts
nojvek 3y ago
Related https://www.theverge.com/23308394/usb-rubber-ducky-review-hack5-defcon-duckyscript 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.
desertraven 3y ago
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?
meehow 3y ago
Hi, I generated new article from your comments. https://hntelegraph.com/post/bluetooth-keystroke-injection-vulnerabilities-protecting-your-devices/ https://hntelegraph.com/post/bluetooth-keystroke-injection-v...

368 points by 3np 3y ago

3np 3y ago

https://nvd.nist.gov/vuln/detail/CVE-2023-45866 https://nvd.nist.gov/vuln/detail/CVE-2023-45866 https://lists.debian.org/debian-lts-announce/2023/12/msg00011.html https://lists.debian.org/debian-lts-announce/2023/12/msg0001... https://source.android.com/docs/security/bulletin/2023-12-01 https://source.android.com/docs/security/bulletin/2023-12-01 https://support.apple.com/en-us/HT214036 https://support.apple.com/en-us/HT214036 https://support.apple.com/en-us/HT214035 https://support.apple.com/en-us/HT214035

diebeforei485 3y ago
Disappointingly, this hasn't been fixed on the prior versions iOS 16 / macOS 13.
- mmsc 3y ago
  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-vulnerabilities https://joshua.hu/apple-ios-patched-unpatched-vulnerabilitie...
deleted 3y ago
[deleted]

neverrroot 3y ago

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

amluto 3y ago
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.
- jeroenhd 3y ago
  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.
  - MBCook 3y ago
    > 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.
  - kelnos 3y ago
    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.
segfaultbuserr 3y ago
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

SpikeDad 3y ago

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.

kccqzy 3y ago
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.
- MBCook 3y ago
  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.
  - tedunangst 3y ago
    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.
    - wtallis 3y ago
      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?

modeless 3y ago

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

binkHN 3y ago
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.
deleted 3y ago
[deleted]
andrepd 3y ago
Yeah, Google wants to be the only one to spy on you :)
kelnos 3y ago
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.
- mdaniel 3y ago
  I had such high hopes for FirefoxOS but it got Mozilla-ed

DiabloD3 3y ago

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

jeffbee 3y ago
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.
- wtallis 3y ago
  Doesn't Android Auto carry audio over Bluetooth? That would be consistent with how unreliable the audio is.
  - jeffbee 3y ago
    I don't know. What's the wire for? Needing both the USB cable and Bluetooth has always struck me as pretty dumb.
    - pepelotas 3y ago
      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.
      - TylerE 3y ago
        Needs to be bluetooth so the handsfree controls on the steering wheel work without an outrageous degree of coupling.

Andrex 3y ago

[flagged]

xp84 3y ago
It seems like it had no competitors though, why wouldn’t it have become a standard? Without it, we would only have proprietary incompatible wireless everything. I’m happy enough with most of my Bluetooth things.
CompYOUT 3y ago
[flagged]
tux2bsd 3y ago
[dead]

naglis 3y ago

FWIW on Arch Linux it is fixed starting with bluez 5.70-2 [1]. [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bluez/-/commit/47e9592b1b322c54bdb094238f52fa20513c624b https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

CompYOUT 3y ago

[flagged]

exikyut 3y ago

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

ComodoHacker 3y ago
I believe it's because they just didn't bother trying this on Windows (yet)
- SCdF 3y ago
  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/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675 https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
  - SpaghettiCthulu 3y ago
    I think "insecure default" or even "wrong default" is more fitting in this case.
wkipling 3y ago
Because Bluetooth barely works normally for Windows
- 3y ago

diebeforei485 3y ago

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.

deleted 3y ago
[deleted]
Terretta 3y ago
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.
- diebeforei485 3y ago
  I have no idea if usability with bluetooth keyboards is affected in different boot states. It certainly isn't affected during normal use, but I don't know about the various recovery modes. Considering the amount of time they took to release this, I assume they figured out a way to get it to work in those various cases after a lot of engineering effort.

deleted 3y ago

[deleted]

DeathArrow 3y ago

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

clort 3y ago
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
overstay8930 3y ago
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.
- Koffiepoeder 3y ago
  Ctrl+alt+t (insert malicious shell command)
  - TylerE 3y ago
    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?
    - stavros 3y ago
      Wireless protocols don't count as physical access, since I can perform the attack from a car outside your house.
    - jeroenhd 3y ago
      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.

sneak 3y ago

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

kelnos 3y ago

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.

rplnt 3y ago
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...
- haraldooo 3y ago
  Am I missing something? Swipe from the top, tap to disable BT?
  - hybridtupel 3y ago
    That’s unfortunately only disconnecting until the next day (see text appearing above when pressing).
  - rplnt 3y ago
    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.
    - cma 3y ago
      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.

acidburnNSA 3y ago

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

dotancohen 3y ago
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).
- dotancohen 3y ago
  TIL that "headsets" and "breasts" are close enough on the qwerty keyboard to confuse swiping keyboards.
  - rezonant 3y ago
    Usually breasts aren't audio devices, but it does occasionally happen. Good luck finding some with Bluetooth support though.
- acidburnNSA 3y ago
  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.

tommiegannert 3y ago

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

atoav 3y ago
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.
- Aachen 3y ago
  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.

souffian 3y ago

[dead]

phendrenad2 3y ago

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 3y ago
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 3y ago
On a computer, you could conceivably hide a poisoned sudo/su somewhere and add it to the $PATH.
- deleted 3y ago
  [deleted]

teruakohatu 3y ago

MacOS / IOS > Lockdown Mode does not prevent the attack That is disappointing.

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

nolist_policy 3y ago

> 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 3y ago
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/3dda6d5ed56af34534dd4cdcdd85627df25aec55/pkgs/os-specific/linux/bluez/default.nix#L45-L50 https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c... [2] https://ubuntu.com/security/notices/USN-4311-1 https://ubuntu.com/security/notices/USN-4311-1
- amarshall 3y ago
  > 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.
- yencabulator 3y ago
  The NixOS change seems to be still stuck in staging-23.11, and not released: $ git log --grep=CVE-2023-45866 origin/nixos-23.11 $ git log --grep=CVE-2023-45866 origin/staging-23.11 ^origin/nixos-23.11 commit 8ba508ba10d27f61fe9f40eb8513d8d0864fbe14 Merge: f5cf92f30bd7 8fb1486901a3 Author: Martin Weinelt <hexa@darmstadt.ccc.de> Date: 2023-12-11 13:02:10 +0100 Merge pull request #272751 from leona-ya/backport-272672-to-staging-23.11 [Backport staging-23.11] bluez: apply patch for CVE-2023-45866 commit 8fb1486901a3f4e7cbdee5616f7d1a39a5dc7a99 Author: Leona Maroni <dev@leona.is> Date: 2023-12-07 13:44:59 +0100 bluez: apply patch for CVE-2023-45866 (cherry picked from commit 7d7f66dfba9f239f15aaec6512afb3443bbae915)

rkagerer 3y ago

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 3y ago
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
- SahAssar 3y ago
  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-with-touch-id-and-numeric-keypad-for-mac-models-with-apple-silicon-us-english-black-keys https://www.apple.com/shop/product/MMMR3LL/A/magic-keyboard-...
meandmycode 3y ago
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.

huppeldepup 3y ago

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

yonatan8070 3y ago
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
- Aachen 3y ago
  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.
- huppeldepup 3y ago
  That's not what I mean. You can instruct the phone - over bluetooth, within the bluetooth functionality - to dial a number. No lock screen or dial app to access.

eviks 3y ago

> 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

jesprenj 3y ago

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.

MBCook 3y ago
The author appears to be holding further details until a presentation at a conference.

yunohn 3y ago

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

beebeepka 3y ago

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.

acdha 3y ago
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.
- beebeepka 3y ago
  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.
  - acdha 3y ago
    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.
    - beebeepka 3y ago
      Clearly even modern devices are nowhere near 5ms but hey, let's just agree your perception is more forgiving.
      - 3y ago

tungah 3y ago

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

slacka 3y ago
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/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675 https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
- chalsprhebaodu 3y ago
  > 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.
- davrosthedalek 3y ago
  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?
  - deleted 3y ago
    [deleted]
  - punkybr3wster 3y ago
    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.
- core_dumped 3y ago

55555 3y ago

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

Aachen 3y ago
Yes, thankfully there's a password on installing software as root Obligatory https://xkcd.com/1200/ https://xkcd.com/1200/ Running code works fine without root, at least to copy your emails, saved logins, and browser sessions file and such
- fsflover 3y ago
  Which is why I'm using Qubes OS to isolate Bluetooth from the rest of the system.
  - wayvey 3y ago
    How does that work?
    - fsflover 3y ago
      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.

sim7c00 3y ago

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

mr_mitm 3y ago

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.

ycombinatrix 3y ago
the author says they can't do anything that requires further authentication. you'd need to chain this with another attack.
joseda-hg 3y ago
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
- mr_mitm 3y ago
  Can you use "tab" to cycle through UI elements on Android or how would you navigate the app store?
  - joseda-hg 3y ago
    You can, I just tested, 2 tabs + Enter get you writing on the Search Box A surprising amount of keyboard shortcuts work on android, Alt+Tab works to get Recent Activities, Directional keys let you move aroud elements, even the special keys like home/calculator work But there's a lot of unintuitive stuff, back button is Windows + Del

2devnull 3y ago

Bluetooth doesn’t need to exist.

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

rini17 3y ago

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 3y ago
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 https://mitxela.com/projects/smsc this cool project from yesterday he was able to use on his phone that way.
- rini17 3y ago
  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.
  - capitainenemo 3y ago
    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 https://en.wikipedia.org/wiki/USB_condom
ycombinatrix 3y ago
What Android device are you using that has a physical "charging only" port?
- rini17 3y ago
  Not physical, software switch.

layer8 3y ago

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

maxerickson 3y ago
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.
- layer8 3y ago
  “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).
  - maxerickson 3y ago
    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.
    - layer8 3y ago
      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.

jrmg 3y ago

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/HT214036 https://support.apple.com/en-us/HT214035 https://support.apple.com/en-us/HT214035

_rdvw 3y ago

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

nojvek 3y ago

Related https://www.theverge.com/23308394/usb-rubber-ducky-review-hack5-defcon-duckyscript 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.

desertraven 3y ago

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?

meehow 3y ago

Hi, I generated new article from your comments. https://hntelegraph.com/post/bluetooth-keystroke-injection-vulnerabilities-protecting-your-devices/ https://hntelegraph.com/post/bluetooth-keystroke-injection-v...