• General

  • How much harm can usb or bluetooth input devices do in GrapheneOS?

I recently found a news article that talks about infected public charging stations for example in trains or buses.
In the described scenario a infected charging station could act as an input device and do literally anything the user can do as long as the device is unlocked, for example getting passwords, pictures, documents and other stuff and send it do the attacker, or even worse: install a malicious app and give the app admin permission (or just all permission possibly + beeing a keyboard app (to get any keyboard input) + view the screen all the time), so that the attacker has permanent backdoor access. All the described things can happen very fast and in the background, without the user recognising it and having a chance to stop it.

My first thought was that i better don't use public charging points, but then to my mind comes:
What if only one of the chargers, power banks or USB sticks I bought from Amazon were malicious, or what about some of the Bluetooth devices? I realised that there are actually many devices that could be used as input devices and then cause damage.

Is there any protection in GrapheneOS do protect the system against such attacks in an unlocked state? I mean, not necessarily block any input, but at least block super fast background input?

  • de0u replied to this.

    If you have your phone set to charging only, my recommendation as your default setting, then you have nothing to worry about.

    If you use one of the less secure options then you are taking a risk. Allowing an open, wired, data connection to an unlocked device massively increases the potential attack surface.

      treequell

      Thank you for your reply.
      I changed the setting so per default this attack could not happen.
      But there are some cases where i need data transfer over USB-C to use a USB Stick and there are also Bluetooth devices that I use.
      It would be very good if connected devices (per USB-C and per Bluetooth) need extra permission to performing input actions.
      And if possible,for devices who then have input permission, there should be a protection against performing super fast background input, this could be implemented by allowing a limited amount of actions per second and also do something to prevent background operations.
      I hope this doesn't sound to demanding or something like this, I just want to put attention to this security vulnerability

          JollyRancher

          Yes, if this setting is on charging only there should be no threat.
          But letting it permanently on charging only and never connecting a USB or Bluetooth device is a thing that many users can't do, including me.

          I think this problem could be solved by two layers of protection against this

          1. A USB or Bluetooth device should not have direct permission to perform inputs when it is connected, instead there should be a toggle that needs to be switched to allow this permission for each device.
          2. If a device as input permission, it should be prevented from malicious actions, or slowed so much done in doing them that the user have a realistic chance to stop it before its to late.

            JollyRancher Use a secure USB drive like https://apricorn.com/aegis-secure-key-3

            Thanks for the link.

            JollyRancher If you aren't sure of the device and just need USB data transfer then use the secure USB stick as an intermediary. Absent the compromise of the firmware of the secure drive, BadUSB and the like simply aren't possible.

            Dou you mena that i should use the linked device as an intermediary? If yes, then doesn't the stick need at least one USB input and one USB output slot?

            Even if i do this, there are still devices that i want to use and i am not a fun of the "only use things your trust" strategy because its not apliccable for everyone. And the point of system like GrapheneOS should be that you don't need to trust anything you use, when you trust GrapheneOS.
            It should be possibly for the system to detect a attack like described, block the connection to the malicious device and report it to the user

                  Open_Source_Enjoyer

                  Open_Source_Enjoyer And the point of system like GrapheneOS should be that you don't need to trust anything you use, when you trust GrapheneOS.

                  This is not true. You still have to put trust into a lot of things depending on what you use. GrapheneOS allowing you to put more restrictions and safety measures on the apps or hardware you use simply reduces the level of trust you have to put into the things you use. It does not remove trust nor is there a actual way to remove trust. You will always have to put some level of trust into something regardless of if you are using this OS or not.

                  The truth is. No matter what GrapheneOS implements if it is even able to implement something for this it will not remove the need to trust something. That's why even if you don't like the "only use things you trust if possible" argument it really is the best argument! As using something you don't trust on a OS you can trust will not make that thing any more trustworthy. At best it will serve as harm reduction by limiting the potential harm of what said thing can do.

                  This isn't me trying to say your post doesn't address anything meaningful. I do think having further protections on anything is a good thing especially if it can come without compromise of usability! I'm just trying to say don't get the wrong idea from privacy and security features and their respective improvements. They can reinforce your trust boundaries but they will not ever remove the need to trust something.

                  Open_Source_Enjoyer It should be possibly for the system to detect a attack like described, block the connection to the malicious device and report it to the user

                  I'm not sure if there would be a reliable way for them to implement something to detect a attack like that as it sounds like something that could trigger a lot of false positives. Furthermore that kind of protection would imply you would have to trust the judgement of the Operating System which still implies a level of trust has to be extended to the Operating System to make sure that the USB device does not violate the users trust. And in this case also the USB device as you have to trust that it doesn't have a method of dodging detection of such a protection feature.

                  In case of Bluetooth as @treequell said Bluetooth devices are already pretty much under control and have their own permission toggles. And the permission toggles are already per device.

                        Open_Source_Enjoyer

                        "And the point of system like GrapheneOS should be that you don't need to trust anything you use, when you trust GrapheneOS."

                        This is not true, android nor GOS is zero trust with USB or Bluetooth devices.

                        "i am not a fun of the "only use things your trust" strategy because its not apliccable for everyone"

                        If you cannot trust every device you use, I have serious questions....

                        "A USB or Bluetooth device should not have direct permission to perform inputs when it is connected, instead there should be a toggle that needs to be switched to allow this permission for each device."

                        This can't be implemented in any meaningful way. USB devices can change ID details at any time. This is why adb uses key auth.

                        "If a device as input permission, it should be prevented from malicious actions, or slowed so much done in doing them that the user have a realistic chance to stop it before its to late."

                        How would this be achieved?

                        "But letting it permanently on charging only and never connecting a USB or Bluetooth device is a thing that many users can't do, including me."

                        Its toggable...

                            Open_Source_Enjoyer All the described things can happen very fast and in the background, without the user recognising it and having a chance to stop it.

                            A link to the article might be productive.

                            USB is a complicated family of protocols, and there are some attacks that could move pretty quickly, especially attacks targeted at a specific version of a specific OS. But there are limits to what can be done, and how quickly it can be done, by something pretending to be a keyboard and/or mouse. Among other things, the attacker would need to be able to send input events to the system without seeing what's happening. All in all, the summary description we have so far sounds like it might be more alarmist than accurate.

                                treequell You can temporarily enable data transfer when you need to do USB data transfer. Is that not sufficient?

                                What if the USB device has been tampered with? You don't know, because even if it has a trustworthy name on it, it can be faked by fraudsters and put on the market through systems like Amazon comingling (comingling means that the shopping site provider, such as Amazon, mixes the 'same' USB sticks from different sellers and doesn't know which item is from which seller).
                                This has already been proven to happen with USB sticks by faking them to have more space and then deleting the oldest files to keep the fake alive. What will happen when people like this move on to more malicious things?

                                treequell For Bluetooth devices, there already exists a per-device permission menu. That's provided as part of AOSP.

                                I know there are restricted permissions, but if I connect a bluetooth device that is requesting input device permission from the system, its immediately granting input device permission and the device could start the attack.
                                Half of the Blutetooth permission system is to actively deny a permission after the point where there is oppurtunity to attack.

                                raccoondad This is not true, android nor GOS is zero trust with USB or Bluetooth devices.

                                This is the problem I am addressing

                                raccoondad If you cannot trust every device you use, I have serious questions....

                                How do I know if the company behind my Bluetooth headphones or the remote clicker I use for my flash cards is trustworthy?
                                For example, even if I trust the company that makes a USB stick, the USB stick I get when I buy it on Amazon could be from a counterfeiter through Amazon Comingling.

                                raccoondad Its toggable...

                                And then i get attacked

                                de0u A link to the article might be productive.

                                The original article is in a non english language, i will search later for a english source.

                                de0u USB is a complicated family of protocols, and there are some attacks that could move pretty quickly, especially attacks targeted at a specific version of a specific OS. But there are limits to what can be done, and how quickly it can be done, by something pretending to be a keyboard and/or mouse. Among other things, the attacker would need to be able to send input events to the system without seeing what's happening. All in all, the summary description we have so far sounds like it might be more alarmist than accurate.

                                I am not sure exactly how this is working but i think the device can know if you are using Android, iOS, Windows, Linux, MacOS etc and then it know where are the buttons to press.

                                                Open_Source_Enjoyer I am not sure exactly how this is working but i think the device can know if you are using Android, iOS, Windows, Linux, MacOS etc and then it know where are the buttons to press.

                                                Anybody can claim anything. Some claims are more plausible than others. So far no source has been cited.

                                                    Open_Source_Enjoyer The original article is in a non english language, i will search later for a english source.

                                                    de0u A link to the article might be productive.

                                                    de0u Anybody can claim anything. Some claims are more plausible than others. So far no source has been cited.

                                                    Here comes the sources for the described security vulnerability:
                                                    https://en.wikipedia.org/wiki/BadUSB
                                                    https://www.wired.com/2014/07/usb-security/
                                                    https://www.tomsguide.com/news/this-critical-bluetooth-flaw-can-let-hackers-control-your-devices-what-you-need-to-know
                                                    https://blinksandbuttons.net/can-bluetooth-keyboard-be-hacked/

                                                    • de0u replied to this.

                                                            Open_Source_Enjoyer Those sources do not describe malware that can exfiltrate photos from an Android phone faster than a user can see.

                                                            It is one thing to attack a Windows machine by popping open a command prompt and pasting a command line, but more difficult to adjust settings on a device running an unknown variant of Android. So it seems as if there may be a gap between the general threat (which is real) and potentially wild claims made in an article that has been alluded to but still not linked to.

                                                            Recent macOS prompts the user when an unfamiliar USB device is connected and tries to describe the device by name. In theory Android could do that as well.

                                                                de0u It is one thing to attack a Windows machine by popping open a command prompt and pasting a command line, but more difficult to adjust settings on a device running an unknown variant of Android.

                                                                The interface of GrapheneOS is nearly the same if not the exact same as the ASOP so to make the right clicks shouldn't be very hard for a USB Stick acting as mouse and keyboard.
                                                                I think the command line is making a big difference in security so of course pc's are even more vulnerable then smartphones and i will also adress this security problem in Linux Forums.

                                                                • de0u replied to this.

                                                                    Again, if the issue is you are worried about compromised devices being badUSBs or similar, then simply enable charging only over USB.

                                                                    USBs can fake their identity, its not hard, there's no way to have a USB device whitelist. This is why ADB authenticates over RSA keys.

                                                                    You need to just know where your devices come from and if they are trust worthy, and if you cannot trust them, don't use them. Buy from the manufacturer if you are really worried, but being attacked in this way is not realistic.

                                                                    ADB requires authentication, and emulating keyboard/mouse inputs is very noticeable and easy to stop by just unplugging the device.

                                                                    If this is a genuine worry of yours, then you should just enable USB charge only, or use devices you absolutely trust, but USB as a protocol already assumes you trust the device you plugged in

                                                                      Open_Source_Enjoyer The interface of GrapheneOS is nearly the same if not the exact same as the ASOP so to make the right clicks shouldn't be very hard for a USB Stick acting as mouse and keyboard.

                                                                      I have not run AOSP since 2019, but that does not match my memory. I'm pretty sure the collection of pre-installed apps is different, so the very first few taps would not be the same, right? And that assumes no customization of the launcher home screen...?

                                                                      Originally it was claimed that some article says this sort of attack can be done "very fast", "in the background", and "without the user recognising it and having a chance to stop it". If that is true as opposed to imagination, there should be some sort of demo. Is there?

                                                                          raccoondad Again, if the issue is you are worried about compromised devices being badUSBs or similar, then simply enable charging only over USB.

                                                                          raccoondad You need to just know where your devices come from and if they are trust worthy, and if you cannot trust them, don't use them. Buy from the manufacturer if you are really worried, but being attacked in this way is not realistic.

                                                                          This is like saying
                                                                          "We don't need app sandboxing because you should only use us apps your are trusting"

                                                                          raccoondad ADB requires authentication, and emulating keyboard/mouse inputs is very noticeable and easy to stop by just unplugging the device.

                                                                          I agree, but then it has to be ensured that the input (on behalf of the user) can only take place in the foreground and never in the background, so that the user has a chance to see it.
                                                                          If that's guaranteed, I can't complain much. In this case, the user just has to make sure that he doesn't leave the device unlocked when he's not looking at it, but he shouldn't leave it unlocked anyway, so there's no problem.

                                                                                de0u I have not run AOSP since 2019, but that does not match my memory. I'm pretty sure the collection of pre-installed apps is different, so the very first few taps would not be the same, right? And that assumes no customization of the launcher home screen...?

                                                                                The thing is that when you use GrapheneOS you are using a hardened version of the ASOP, but I don't know of any changes that have been made to the design of it. The launcher that GrapheneOS uses is the ASOP launcher, so the GUI is the same.
                                                                                From this point, the attacker can go through a list of browser names until he finds one that is installed, and then perform the following steps:

                                                                                1. Go to a website hosted by the attacker and install a malicious .apk
                                                                                2. Then press the buttons to allow the browser to be a source for installations
                                                                                3. Give the installed app admin permission
                                                                                • de0u replied to this.