[HN Gopher] Bluetooth keystroke-injection in Android, Linux, mac...
___________________________________________________________________
Bluetooth keystroke-injection in Android, Linux, macOS and iOS
Author : 3np
Score : 317 points
Date : 2023-12-16 02:26 UTC (20 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 3np wrote:
| 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
| diebeforei485 wrote:
| Disappointingly, this hasn't been fixed on the prior versions
| iOS 16 / macOS 13.
| mmsc wrote:
| 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...
| neverrroot wrote:
| Oh snap, here we go again, convenience vs security, zero sum
| game.
| amluto wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| tedunangst wrote:
| Perhaps there is a bug and the unique identifier isn't
| checked.
| MBCook wrote:
| 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...
| Findecanor wrote:
| 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.
| kelnos wrote:
| 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?
| modeless wrote:
| > 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 wrote:
| 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.
| andrepd wrote:
| Yeah, Google wants to be the only one to spy on you :)
| kelnos wrote:
| 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.
| DiabloD3 wrote:
| 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 wrote:
| 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 wrote:
| Doesn't Android Auto carry audio over Bluetooth? That would
| be consistent with how unreliable the audio is.
| jeffbee wrote:
| I don't know. What's the wire for? Needing both the USB
| cable and Bluetooth has always struck me as pretty dumb.
| pepelotas wrote:
| 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 wrote:
| Needs to be bluetooth so the handsfree controls on the
| steering wheel work without an outrageous degree of
| coupling.
| xp84 wrote:
| 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.
| kelnos wrote:
| 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.
| wtallis wrote:
| _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.
| MBCook wrote:
| It's a point to point link too, not standard access point
| style.
| charcircuit wrote:
| >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.
| shzhdbi09gv8ioi wrote:
| 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.
| icehawk wrote:
| Regular Bluetooth audio isn't guaranteed to save you
| there. My car has a 6 second delay on the Bluetooth
| audio.
| MBCook wrote:
| That's why always use wired CarPlay despite having
| wireless support.
| TylerE wrote:
| If it's anything like CarPlay, it's absolutely NOT
| bluetooth.
| lxgr wrote:
| 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 wrote:
| 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 :)
| kelnos wrote:
| 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.
| aydyn wrote:
| 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.
| hexfish wrote:
| 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.
| aydyn wrote:
| 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.
| strogonoff wrote:
| 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.
| stavros wrote:
| I find the notion that wires are less reliable than
| wireless extremely contrary to my own experience.
| jtc331 wrote:
| 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.
| stavros wrote:
| 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.
| shzhdbi09gv8ioi wrote:
| 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.
| aYsY4dDQ2NrcNzA wrote:
| Which is how a cat chose your username. I know how that
| feels.
| pcthrowaway wrote:
| 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.
| crazygringo wrote:
| > _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.)
| bee_rider wrote:
| 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.
| naglis wrote:
| FWIW on Arch Linux it is fixed starting with bluez 5.70-2 [1].
|
| [1]:
| https://gitlab.archlinux.org/archlinux/packaging/packages/bl...
| exikyut wrote:
| 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 wrote:
| I believe it's because they just didn't bother trying this on
| Windows (yet)
| SCdF wrote:
| 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...
| SpaghettiCthulu wrote:
| I think "insecure default" or even "wrong default" is more
| fitting in this case.
| wkipling wrote:
| Because Bluetooth barely works normally for Windows
| Etheryte wrote:
| Can't be affected by an attack vector if the vector doesn't
| work to begin with, clever.
| d3w4s9 wrote:
| 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
| FirmwareBurner wrote:
| 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.
| 360MustangScope wrote:
| 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
| FirmwareBurner wrote:
| 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.
| 360MustangScope wrote:
| 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
| vel0city wrote:
| 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.
| givinguflac wrote:
| 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.
| FirmwareBurner wrote:
| 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.
| 360MustangScope wrote:
| 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.
| acdha wrote:
| > 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.
| vel0city wrote:
| 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.
| fsflover wrote:
| When people say that Linux works flawlessly with the
| right hardware, people also often don't seem care.
| 360MustangScope wrote:
| 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
| FirmwareBurner wrote:
| 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.
| vel0city wrote:
| 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.
| solardev wrote:
| 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)
| 360MustangScope wrote:
| 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
| solardev wrote:
| Yeah, I feel ya :/ My Xbox controller works better on a
| Mac than it ever it did on my Surface Book. Ironic.
| ofrzeta wrote:
| 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.
| worewood wrote:
| 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.
| WhackyIdeas wrote:
| 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.
| teddyh wrote:
| > _knowing that the Windows Bluetooth stack has the
| architectural equivalent of BlueZ 's `ClassicBondedOnly=false`_
|
| Did you mean "ClassicBondedOnly=true"?
| diebeforei485 wrote:
| 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.
| DeathArrow wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| Ctrl+alt+t (insert malicious shell command)
| TylerE wrote:
| 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 wrote:
| Wireless protocols don't count as physical access, since
| I can perform the attack from a car outside your house.
| jeroenhd wrote:
| 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.
| 127361 wrote:
| Even more scary: (launch child porn web site)
| TylerE wrote:
| 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"?
| atoav wrote:
| 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?
| TylerE wrote:
| 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/
| atoav wrote:
| Ah thanks for the context
| jgilias wrote:
| > The vulnerabilities work by tricking the Bluetooth host
| state-machine into pairing with a fake keyboard without user-
| confirmation.
| mihalycsaba wrote:
| Is this possible to pair a keyboard device to Android without
| confirmation?
| stavros wrote:
| If the vulnerability author is to be believed, yes.
| keep_reading wrote:
| It's apparently a feature of ancient Bluetooth
| sneak wrote:
| One of the many reasons I still exclusively use wired input
| peripherals.
| kelnos wrote:
| 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 wrote:
| 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 wrote:
| Am I missing something? Swipe from the top, tap to disable
| BT?
| hybridtupel wrote:
| That's unfortunately only disconnecting until the next day
| (see text appearing above when pressing).
| rplnt wrote:
| 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 wrote:
| 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.
| slau wrote:
| 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?
| 0xDEADFED5 wrote:
| That's nonsense, Maps works perfectly fine with wifi off
| sumuyuda wrote:
| I had to create custom shortcuts to disable WiFi and
| Bluetooth after Apple made the ones from Control Center
| useless.
| rplnt wrote:
| 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.
| vldo wrote:
| I made one to open locations in settings via open URL:
| prefs:root=Privacy&path=LOCATION
| malfist wrote:
| Wow, that's bonkers. I thought apple cared about privacy?
| vldo wrote:
| it's route for the settings menu, not sure it works in
| the browser :)
| vldo wrote:
| here's a list with all settings urls:
| https://github.com/FifiTheBulldog/ios-settings-
| urls/blob/mas...
| judge2020 wrote:
| 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.
| CamperBob2 wrote:
| Sounds like an excellent opportunity for a UI affordance
| to me. Instead, Apple has chosen the path of least-yet-
| most-unpleasant surprise.
| amarshall wrote:
| It's impossible to permanently disable Bluetooth on iOS.
| Every iOS update re-enables it.
| SamuelAdams wrote:
| 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
| DougBTX wrote:
| > 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.
| rplnt wrote:
| 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.
| vldo wrote:
| You can make a shortcut with the action Toggle and set
| Bluetooth
| ace2358 wrote:
| 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)
| lencastre wrote:
| Make a shortcut to disable or enable and add that shortcut to
| your Home Screen
| lxgr wrote:
| 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.
| mejutoco wrote:
| 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.
| diroussel wrote:
| 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.
| magicalhippo wrote:
| > 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.
| mihalycsaba wrote:
| Does this even work without pairing?
| Aachen wrote:
| > 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
| magicalhippo wrote:
| Right, but can it enter keystrokes when the device is
| locked? As in use the device "behind" the lock screen?
| Aachen wrote:
| 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 :/
| davrosthedalek wrote:
| 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.
| fellerts wrote:
| 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
| jdfedgon wrote:
| This seems correct, however 'ClassicBondedOnly=true' is
| commented out in '/etc/bluetooth/input.conf' in Fedora 39
| with bluez v5.70-4 anyways.
| maxerickson wrote:
| Presumably so you can't turn it off simply by uncommenting
| the line. The default is defined in some source file.
| cozzyd wrote:
| Generally commented out lines are defaults, right?
| tesdinger wrote:
| 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.
| galangalalgol wrote:
| 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.
| lofaszvanitt wrote:
| 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
| horusthegame wrote:
| Ubuntu 2022, the default appears to be true already:
|
| # Defaults to true for security. #ClassicBondedOnly=true
| moritzwarhier wrote:
| 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.
| lannisterstark wrote:
| >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
| acidburnNSA wrote:
| Dang it, now I guess I have to toss my out of support android
| phone that works fine but doesn't support lineage.
| dotancohen wrote:
| 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 wrote:
| TIL that "headsets" and "breasts" are close enough on the
| qwerty keyboard to confuse swiping keyboards.
| rezonant wrote:
| Usually breasts aren't audio devices, but it does
| occasionally happen. Good luck finding some with Bluetooth
| support though.
| acidburnNSA wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| phendrenad2 wrote:
| 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 wrote:
| 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 wrote:
| On a computer, you could conceivably hide a poisoned sudo/su
| somewhere and add it to the $PATH.
| teruakohatu wrote:
| MacOS / IOS
|
| > Lockdown Mode does not prevent the attack
|
| That is disappointing.
| MBCook wrote:
| There is a list of stuff lockdown does. That was never in the
| list. So it's not too surprising.
| nolist_policy wrote:
| > 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 wrote:
| 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
| amarshall wrote:
| > 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.
| rkagerer wrote:
| _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 wrote:
| 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 wrote:
| 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-...
| meandmycode wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| eviks wrote:
| > 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 wrote:
| 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 wrote:
| The author appears to be holding further details until a
| presentation at a conference.
| yunohn wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tungah wrote:
| This is great news now that the industry phased out physical
| audio connection on phones in favor of wireless. Good job, guys.
| slacka wrote:
| 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...
| chalsprhebaodu wrote:
| > 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 wrote:
| 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?
| punkybr3wster wrote:
| 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 wrote:
| 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
| msephton wrote:
| Yet you reply with snark? Be the change you want to see in
| this world.
| fsflover wrote:
| My phone has both audio jack and USB-C.
| asystole wrote:
| USB-C DACs are inexpensive and widely available.
| 55555 wrote:
| 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 wrote:
| 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
| fsflover wrote:
| Which is why I'm using Qubes OS to isolate Bluetooth from the
| rest of the system.
| sim7c00 wrote:
| 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 wrote:
| 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 wrote:
| the author says they can't do anything that requires further
| authentication. you'd need to chain this with another attack.
| rini17 wrote:
| 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 wrote:
| 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.
| rini17 wrote:
| 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 wrote:
| 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
| ycombinatrix wrote:
| What Android device are you using that has a physical "charging
| only" port?
| 2devnull wrote:
| Bluetooth doesn't need to exist.
| s3p wrote:
| And what do you propose as the alternative? How do you think
| people should connect their headphones, watches, fans, etc.
| layer8 wrote:
| > 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| 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.
| maxerickson wrote:
| I guess if you have Apple devices, yeah, it might be
| worth figuring it out.
| jrmg wrote:
| 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
| SubzeroCarnage wrote:
| My DivestOS patched this on Android 7 through 13 in the December
| update: https://divestos.org/pages/patch_counts
| nojvek wrote:
| 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.
___________________________________________________________________
(page generated 2023-12-16 23:01 UTC)