BadUSB attacks on AppVMs
121 views
Skip to first unread message
Vít Šesták
Sep 11, 2015, 1:44:41 PM9/11/15
to qubes-users
Suppose that there is an USB controller assigned to an AppVM. Let's insert there a malicious device. I'd like to exclude some physical attacks like high voltage as they are neither Qubes-specific nor interesting (destroying a HW is not as interesting as pwning a device). What can the attacker do?
For Windows and all non-seamless systems, I suppose that attacker can perform pretty standard BadUSB attack.
For seamless systems (e.g. Qubes Debian/Fedora template), it seems that keyboard input comes into a tty. I was able to shut the system down using ctrl+alt+delete. I was, however, unable to log in the system as root (like I can do using virsh) and perform some commands like touch /tmp/i-am-here. Is such attack possible? If not, how is such attack mitigated?
My second consideration is about non-keyboard attacks deployed through USB. What else can attacker perform supposing I have a VM originating from an ITL template (provided that I haven't done any drastical modifications)? Maybe he can connect an USB network card and hijack all the network communication. This could have some implications on usbip-based USB-VMs. Is there anything more interesting?
Apparently, the attacker can't attack dom0 even if he shuts the AppVM down, as the USB controller is not automatically attached to dom0 after shutdown.
Reagrds,
Vít Šesták 'v6ak'
For Windows and all non-seamless systems, I suppose that attacker can perform pretty standard BadUSB attack.
For seamless systems (e.g. Qubes Debian/Fedora template), it seems that keyboard input comes into a tty. I was able to shut the system down using ctrl+alt+delete. I was, however, unable to log in the system as root (like I can do using virsh) and perform some commands like touch /tmp/i-am-here. Is such attack possible? If not, how is such attack mitigated?
My second consideration is about non-keyboard attacks deployed through USB. What else can attacker perform supposing I have a VM originating from an ITL template (provided that I haven't done any drastical modifications)? Maybe he can connect an USB network card and hijack all the network communication. This could have some implications on usbip-based USB-VMs. Is there anything more interesting?
Apparently, the attacker can't attack dom0 even if he shuts the AppVM down, as the USB controller is not automatically attached to dom0 after shutdown.
Reagrds,
Vít Šesták 'v6ak'
Marek Marczykowski-Górecki
Sep 11, 2015, 2:21:16 PM9/11/15
to Vít Šesták, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Sep 11, 2015 at 10:44:41AM -0700, Vít Šesták wrote:
> Suppose that there is an USB controller assigned to an AppVM. Let's insert
> there a malicious device. I'd like to exclude some physical attacks like
> high voltage as they are neither Qubes-specific nor interesting (destroying
> a HW is not as interesting as pwning a device). What can the attacker do?
>
> For Windows and all non-seamless systems, I suppose that attacker can
> perform pretty standard BadUSB attack.
>
> For seamless systems (e.g. Qubes Debian/Fedora template), it seems that
> keyboard input comes into a tty. I was able to shut the system down using
> ctrl+alt+delete. I was, however, unable to log in the system as root (like
> I can do using virsh) and perform some commands like touch /tmp/i-am-here.
> Is such attack possible? If not, how is such attack mitigated?
The active session is X session, not a standard tty. But if you switch
to a text console with something like Alt+Ctrl+F1, you'll probably be
able to login. Other than that, its possible to inject keystrokes into
active UsbVM window.
> My second consideration is about non-keyboard attacks deployed through USB.
> What else can attacker perform supposing I have a VM originating from an
> ITL template (provided that I haven't done any drastical modifications)?
> Maybe he can connect an USB network card and hijack all the network
> communication. This could have some implications on usbip-based USB-VMs. Is
> there anything more interesting?
If that UsbVm is also your NetVM, then probably yes - he/she can
probably sniff/hijack all the network connections. But if UsbVm is
separate (and even better - not connected to any netvm), then it
shouldn't be possible.
If you attach USB stick (as a block device) from such compromised UsbVM
to some other VM, it would be able to try attacks on filesystem metadata
parsing code. But the same applies to simply infected USB stick...
> Apparently, the attacker can't attack dom0 even if he shuts the AppVM down,
> as the USB controller is not automatically attached to dom0 after shutdown.
Yes. This is exactly the reason for such decision.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJV8xuQAAoJENuP0xzK19csx5IH/3SspDAQVB69knCMyi5My+ju
Mo+vUYnF4fEXI/4zzBGB4BPlB0D8S4CeJ6VyaCrEyMtfBp3VUQ4lARVivmxubG5F
2xx1TSux/GLA98ibTW7ZkNtmu6psY/LzY0v68pcuNy0SpYW9iHHbUCoRmcwYDSog
hCSp30RYF0+7gUjoyImrLOheB79nkBVhQP3bryDXbr58cVfiIfXyIs4s2AAT2TlH
k1D4NEQ740quJWBT7PYoeycO3aY7noso/7jfca7newqvWLqIhwSJviZErW9enaCh
1fEmMaWfOW72UqBnjL81QYHKxF1QmC/YZbkb+MByr9jpHfxyULGKJ+ENT+ZcCD4=
=MBWg
-----END PGP SIGNATURE-----
Hash: SHA256
On Fri, Sep 11, 2015 at 10:44:41AM -0700, Vít Šesták wrote:
> Suppose that there is an USB controller assigned to an AppVM. Let's insert
> there a malicious device. I'd like to exclude some physical attacks like
> high voltage as they are neither Qubes-specific nor interesting (destroying
> a HW is not as interesting as pwning a device). What can the attacker do?
>
> For Windows and all non-seamless systems, I suppose that attacker can
> perform pretty standard BadUSB attack.
>
> For seamless systems (e.g. Qubes Debian/Fedora template), it seems that
> keyboard input comes into a tty. I was able to shut the system down using
> ctrl+alt+delete. I was, however, unable to log in the system as root (like
> I can do using virsh) and perform some commands like touch /tmp/i-am-here.
> Is such attack possible? If not, how is such attack mitigated?
to a text console with something like Alt+Ctrl+F1, you'll probably be
able to login. Other than that, its possible to inject keystrokes into
active UsbVM window.
> My second consideration is about non-keyboard attacks deployed through USB.
> What else can attacker perform supposing I have a VM originating from an
> ITL template (provided that I haven't done any drastical modifications)?
> Maybe he can connect an USB network card and hijack all the network
> communication. This could have some implications on usbip-based USB-VMs. Is
> there anything more interesting?
probably sniff/hijack all the network connections. But if UsbVm is
separate (and even better - not connected to any netvm), then it
shouldn't be possible.
If you attach USB stick (as a block device) from such compromised UsbVM
to some other VM, it would be able to try attacks on filesystem metadata
parsing code. But the same applies to simply infected USB stick...
> Apparently, the attacker can't attack dom0 even if he shuts the AppVM down,
> as the USB controller is not automatically attached to dom0 after shutdown.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJV8xuQAAoJENuP0xzK19csx5IH/3SspDAQVB69knCMyi5My+ju
Mo+vUYnF4fEXI/4zzBGB4BPlB0D8S4CeJ6VyaCrEyMtfBp3VUQ4lARVivmxubG5F
2xx1TSux/GLA98ibTW7ZkNtmu6psY/LzY0v68pcuNy0SpYW9iHHbUCoRmcwYDSog
hCSp30RYF0+7gUjoyImrLOheB79nkBVhQP3bryDXbr58cVfiIfXyIs4s2AAT2TlH
k1D4NEQ740quJWBT7PYoeycO3aY7noso/7jfca7newqvWLqIhwSJviZErW9enaCh
1fEmMaWfOW72UqBnjL81QYHKxF1QmC/YZbkb+MByr9jpHfxyULGKJ+ENT+ZcCD4=
=MBWg
-----END PGP SIGNATURE-----
Franz
Sep 11, 2015, 2:54:48 PM9/11/15
to Vít Šesták, qubes-users
On Fri, Sep 11, 2015 at 2:44 PM, Vít Šesták <groups-no-private-mail--con...@v6ak.com> wrote:
Suppose that there is an USB controller assigned to an AppVM. Let's insert there a malicious device. I'd like to exclude some physical attacks like high voltage as they are neither Qubes-specific nor interesting (destroying a HW is not as interesting as pwning a device). What can the attacker do?
Are you inserting the malicious device, without knowing it is malicious, or is the attacker who has physical access to your machine?
For Windows and all non-seamless systems, I suppose that attacker can perform pretty standard BadUSB attack.
For seamless systems (e.g. Qubes Debian/Fedora template), it seems that keyboard input comes into a tty. I was able to shut the system down using ctrl+alt+delete. I was, however, unable to log in the system as root (like I can do using virsh) and perform some commands like touch /tmp/i-am-here. Is such attack possible? If not, how is such attack mitigated?
My second consideration is about non-keyboard attacks deployed through USB. What else can attacker perform supposing I have a VM originating from an ITL template (provided that I haven't done any drastical modifications)? Maybe he can connect an USB network card and hijack all the network communication. This could have some implications on usbip-based USB-VMs. Is there anything more interesting?
Apparently, the attacker can't attack dom0 even if he shuts the AppVM down, as the USB controller is not automatically attached to dom0 after shutdown.
Reagrds,--
Vít Šesták 'v6ak'
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/68269b18-dced-4543-9972-744bf4935275%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Robert Fisk
Sep 11, 2015, 10:41:40 PM9/11/15
to qubes...@googlegroups.com
most of this year. I am currently bench-testing the first prototype, and
hope to release a public beta in a few weeks when the bugs are squashed
and the docs are written.
It is an embedded system using two microprocessors to sanitise USB
transactions between host and device. A feature already present in the
firmware is the enforcement of some basic rules: A single feature per
device (no composite devices), and no run-time class changes after
enumeration. This will effectively prevent innocent-looking devices
surreptitiously inserting keystrokes, jacking network connections, etc.
Regards,
Robert
jonbrown...@gmail.com
Sep 11, 2015, 11:23:19 PM9/11/15
to qubes-users, rober...@fastmail.fm
Robert,
Very cool, looking forward to seeing your solution. I have wondered about using https://github.com/dominicgs/USBProxy to only allow block devices connected to it firewall keyboard based input, faked hid and etc.. The idea is you setup a beagleboard with this software as your dedicated usb flash drive device that blocks anything but block access to data.
Vít Šesták
Sep 12, 2015, 5:33:19 AM9/12/15
to qubes-users, groups-no-private-mail--con...@v6ak.com
On Friday, September 11, 2015 at 8:21:16 PM UTC+2, Marek Marczykowski-Górecki wrote:
The active session is X session, not a standard tty. But if you switch
to a text console with something like Alt+Ctrl+F1, you'll probably be
able to login. Other than that, its possible to inject keystrokes into
active UsbVM window.
Well, this does not correspond with my experiments on Qubes 3.0 with Debian 8 using an external USB keyboard attached to a particular AppVM:
* I was able to use ctrl+alt+del to perform a reboot (actually shutdown – probably due to Xen config). This is common on a tty but not on X11.
* I was not able to inject keystrokes to the current window of that AppVM.
* I was unable to log in the tty and perform something like touch /tmp/i-am-here. I was able to do the same using the virsh console (using the keyboard attached to dom0), so the key sequence does not seem to be wrong.
But my experiments were blind. I was unable to sniff any tty.
* I was able to use ctrl+alt+del to perform a reboot (actually shutdown – probably due to Xen config). This is common on a tty but not on X11.
* I was not able to inject keystrokes to the current window of that AppVM.
* I was unable to log in the tty and perform something like touch /tmp/i-am-here. I was able to do the same using the virsh console (using the keyboard attached to dom0), so the key sequence does not seem to be wrong.
But my experiments were blind. I was unable to sniff any tty.
> My second consideration is about non-keyboard attacks deployed through USB.
> What else can attacker perform supposing I have a VM originating from an
> ITL template (provided that I haven't done any drastical modifications)?
> Maybe he can connect an USB network card and hijack all the network
> communication. This could have some implications on usbip-based USB-VMs. Is
> there anything more interesting?
If that UsbVm is also your NetVM, then probably yes - he/she can
probably sniff/hijack all the network connections. But if UsbVm is
separate (and even better - not connected to any netvm), then it
shouldn't be possible.
I considered another scenario – UsbVM sharing its USB ports through network to other VMs. While this might look innocent provided that you trust your FirewallVM enough for that purpose, a network adapter might allow one USB device to communicate to other USB devices (even if both devices are connected to other USB controllers and keyboard-based USB attacks is somehow mitigated).
If you attach USB stick (as a block device) from such compromised UsbVM
to some other VM, it would be able to try attacks on filesystem metadata
parsing code. But the same applies to simply infected USB stick...
OK.
On Friday, September 11, 2015 at 8:54:48 PM UTC+2, Francesco wrote:
Are you inserting the malicious device, without knowing it is malicious, or is the attacker who has physical access to your machine?
I consider the first – inserting a malicious device without knowing it is malicious.
On Saturday, September 12, 2015 at 4:41:40 AM UTC+2, Robert Fisk wrote:
I have been brewing a solution to BadUSB in my limited spare time for
most of this year. I am currently bench-testing the first prototype, and
hope to release a public beta in a few weeks when the bugs are squashed
and the docs are written.
It is an embedded system using two microprocessors to sanitise USB
transactions between host and device. A feature already present in the
firmware is the enforcement of some basic rules: A single feature per
device (no composite devices), and no run-time class changes after
enumeration. This will effectively prevent innocent-looking devices
surreptitiously inserting keystrokes, jacking network connections, etc.
I suppose that USB hubs are also disabled. But I am not sure if such device can prevent BadUSB attacks without a further tuning:
First, consider an USB device that suddenly turns itself off. After your proxy realizes that the device has been turned off, it turns itself on, but it has a different feature.
Second, consider a slightly more social-engineering-based attack: You insert an USB stick to your computer and some BadUSB attack is performed in some invisible-enough way. You realize that the USB device does not work, Maybe you will try to reinsert the device, maybe to another port. But after the BadUSB attack is performed, the device would work like it is supposed to. I would bet that even most of the security experts would not consider this to be suspicious. And even if the user considered this to be suspicious, it is too late. This reminds me the joke about a man putting his bike to a place so that he can see anyone trying to steal his bike. Well, he saw someone.
Regards,
Vít Šesták 'v6ak'
Marek Marczykowski-Górecki
Sep 12, 2015, 6:17:25 AM9/12/15
to Vít Šesták, qubes-users, Robert Fisk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Sat, Sep 12, 2015 at 02:33:18AM -0700, Vít Šesták wrote:
>
>
> On Friday, September 11, 2015 at 8:21:16 PM UTC+2, Marek
> Marczykowski-Górecki wrote:
> >
> >
> > The active session is X session, not a standard tty. But if you switch
> > to a text console with something like Alt+Ctrl+F1, you'll probably be
> > able to login. Other than that, its possible to inject keystrokes into
> > active UsbVM window.
> >
>
> Well, this does not correspond with my experiments on Qubes 3.0 with Debian
> 8 using an external USB keyboard attached to a particular AppVM:
>
> * I was able to use ctrl+alt+del to perform a reboot (actually shutdown –
> probably due to Xen config). This is common on a tty but not on X11.
> * I was not able to inject keystrokes to the current window of that AppVM.
> * I was unable to log in the tty and perform something like touch
> /tmp/i-am-here. I was able to do the same using the virsh console (using
> the keyboard attached to dom0), so the key sequence does not seem to be
> wrong.
>
> But my experiments were blind. I was unable to sniff any tty.
Maybe this is different on Debian. On Fedora when you connect keyboard
>
>
> On Friday, September 11, 2015 at 8:21:16 PM UTC+2, Marek
> Marczykowski-Górecki wrote:
> >
> >
> > The active session is X session, not a standard tty. But if you switch
> > to a text console with something like Alt+Ctrl+F1, you'll probably be
> > able to login. Other than that, its possible to inject keystrokes into
> > active UsbVM window.
> >
>
> Well, this does not correspond with my experiments on Qubes 3.0 with Debian
> 8 using an external USB keyboard attached to a particular AppVM:
>
> * I was able to use ctrl+alt+del to perform a reboot (actually shutdown –
> probably due to Xen config). This is common on a tty but not on X11.
> * I was not able to inject keystrokes to the current window of that AppVM.
> * I was unable to log in the tty and perform something like touch
> /tmp/i-am-here. I was able to do the same using the virsh console (using
> the keyboard attached to dom0), so the key sequence does not seem to be
> wrong.
>
> But my experiments were blind. I was unable to sniff any tty.
to UsbVM, you can type anything in UsbVM windows.
> > My second consideration is about non-keyboard attacks deployed through
> > USB.
> > > What else can attacker perform supposing I have a VM originating from an
> > > ITL template (provided that I haven't done any drastical modifications)?
> > > Maybe he can connect an USB network card and hijack all the network
> > > communication. This could have some implications on usbip-based USB-VMs.
> > Is
> > > there anything more interesting?
> >
> > If that UsbVm is also your NetVM, then probably yes - he/she can
> > probably sniff/hijack all the network connections. But if UsbVm is
> > separate (and even better - not connected to any netvm), then it
> > shouldn't be possible.
> >
>
> I considered another scenario – UsbVM sharing its USB ports through network
> to other VMs. While this might look innocent provided that you trust your
> FirewallVM enough for that purpose, a network adapter might allow one USB
> device to communicate to other USB devices (even if both devices are
> connected to other USB controllers and keyboard-based USB attacks is
> somehow mitigated).
mechanism - either USBIP, PVUSB or anything else), the device would be
able to perform at least subset of USB based attacks there. Pretending
to be some other device is one of them.
But going back to your scenario - for such attack to work, something need to
enable the network interface and add some route. Otherwise
kernel would not process any packets from there. If you have UsbVM as
NetVM (so NetworkManager is running there), this will be probably done
automatically - depending on your NetworkManager configuration. But
otherwise not.
have some white list of allowed device classes. So for example only
storage devices would be allowed (not keyboard etc).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
3kJGEtLLrO6vIYouAYaOKdWrrvpLm1b5ODD/Eq0Hwr7fMQg8b3ZTXnBD7guRh4pN
EDbe19f7rTjIg4/BpTvrL23N5oGRMVpdVVP8VLLcigWjvdrAfeMIbmBQWTEEthKl
Jecczvn4wTyMUPbc4U2YepKvx14tIXJqRyAKq/FFl3/fX+1s3dMy4y+47LA7DSnv
NN/spdu/e6fvN8q6w9UKrYgbH4pcZTPx+IOW1p1heX6iZ3TSgU044JUSrkdpGEOp
yIjSc76kwYRortrfx5nO+U7ab2B/3RzMASp5FQBJnOf0Vi+mLz1PoJJSfZ+sKtw=
=YJXd
-----END PGP SIGNATURE-----
Robert Fisk
Sep 12, 2015, 8:57:00 PM9/12/15
to Marek Marczykowski-Górecki, Vít Šesták, qubes-users
On 12/09/15 22:17, Marek Marczykowski-Górecki wrote:
>> > On Saturday, September 12, 2015 at 4:41:40 AM UTC+2, Robert Fisk wrote:
>>> > >
>>> > > I have been brewing a solution to BadUSB in my limited spare time for
>>> > > most of this year. I am currently bench-testing the first prototype, and
>>> > > hope to release a public beta in a few weeks when the bugs are squashed
>>> > > and the docs are written.
>>> > >
>>> > > It is an embedded system using two microprocessors to sanitise USB
>>> > > transactions between host and device. A feature already present in the
>>> > > firmware is the enforcement of some basic rules: A single feature per
>>> > > device (no composite devices), and no run-time class changes after
>>> > > enumeration. This will effectively prevent innocent-looking devices
>>> > > surreptitiously inserting keystrokes, jacking network connections, etc.
>>> > >
>> >
>> > I suppose that USB hubs are also disabled. But I am not sure if such device
>> > can prevent BadUSB attacks without a further tuning:
The embedded USB host stack only supports one downstream device, no hubs
>> > On Saturday, September 12, 2015 at 4:41:40 AM UTC+2, Robert Fisk wrote:
>>> > >
>>> > > I have been brewing a solution to BadUSB in my limited spare time for
>>> > > most of this year. I am currently bench-testing the first prototype, and
>>> > > hope to release a public beta in a few weeks when the bugs are squashed
>>> > > and the docs are written.
>>> > >
>>> > > It is an embedded system using two microprocessors to sanitise USB
>>> > > transactions between host and device. A feature already present in the
>>> > > firmware is the enforcement of some basic rules: A single feature per
>>> > > device (no composite devices), and no run-time class changes after
>>> > > enumeration. This will effectively prevent innocent-looking devices
>>> > > surreptitiously inserting keystrokes, jacking network connections, etc.
>>> > >
>> >
>> > I suppose that USB hubs are also disabled. But I am not sure if such device
>> > can prevent BadUSB attacks without a further tuning:
supported. You can call this a 'feature'!
>> >
>> > First, consider an USB device that suddenly turns itself off. After your
>> > proxy realizes that the device has been turned off, it turns itself on, but
>> > it has a different feature.
permitted - i.e. the user has to unplug it from their computer.
>> >
>> > Second, consider a slightly more social-engineering-based attack: You
>> > insert an USB stick to your computer and some BadUSB attack is performed in
>> > some invisible-enough way. You realize that the USB device does not work,
>> > Maybe you will try to reinsert the device, maybe to another port. But after
>> > the BadUSB attack is performed, the device would work like it is supposed
>> > to. I would bet that even most of the security experts would not consider
>> > this to be suspicious. And even if the user considered this to be
>> > suspicious, it is too late. This reminds me the joke about a man putting
>> > his bike to a place so that he can see anyone trying to steal his bike.
>> > Well, he saw someone.
refuse to work through the proxy, inviting the user to 'just try it
directly', in which case we cannot help :(
> I think such device should not only allow only one function, but also
> have some white list of allowed device classes. So for example only
> storage devices would be allowed (not keyboard etc).
'feature'! Future versions will support more classes, in which case I
may compile single-device-class-only firmware images.
Regards,
Robert
Robert Fisk
Sep 12, 2015, 9:03:39 PM9/12/15
to jonbrown...@gmail.com, qubes-users
On 12/09/15 15:23, jonbrown...@gmail.com wrote:
> Robert,
>
> Very cool, looking forward to seeing your solution. I have wondered about using https://github.com/dominicgs/USBProxy to only allow block devices connected to it firewall keyboard based input, faked hid and etc.. The idea is you setup a beagleboard with this software as your dedicated usb flash drive device that blocks anything but block access to data.
>
I wouldn't rely on the USBProxy to keep you safe. If a device can own
> Robert,
>
> Very cool, looking forward to seeing your solution. I have wondered about using https://github.com/dominicgs/USBProxy to only allow block devices connected to it firewall keyboard based input, faked hid and etc.. The idea is you setup a beagleboard with this software as your dedicated usb flash drive device that blocks anything but block access to data.
>
your linux box over USB, then it can also own your linux box after first
owning linux on the BeagleBoard.
So it might slow an attacker down but it won't stop them.
Regards,
Robert
Vít Šesták
Sep 15, 2015, 8:34:49 AM9/15/15
to qubes-users, marm...@invisiblethingslab.com, groups-no-private-mail--con...@v6ak.com, rober...@fastmail.fm
On Sunday, September 13, 2015 at 2:57:00 AM UTC+2, Robert Fisk wrote:
The proxy device requires a power cycle before a device class change is
permitted - i.e. the user has to unplug it from their computer.
>> >
>> > Second, consider a slightly more social-engineering-based attack: You
>> > insert an USB stick to your computer and some BadUSB attack is performed in
>> > some invisible-enough way. You realize that the USB device does not work,
>> > Maybe you will try to reinsert the device, maybe to another port. But after
>> > the BadUSB attack is performed, the device would work like it is supposed
>> > to. I would bet that even most of the security experts would not consider
>> > this to be suspicious. And even if the user considered this to be
>> > suspicious, it is too late. This reminds me the joke about a man putting
>> > his bike to a place so that he can see anyone trying to steal his bike.
>> > Well, he saw someone.
Yes we rely on the user to always use the proxy device. A BadUSB may
refuse to work through the proxy, inviting the user to 'just try it
directly', in which case we cannot help :(
This is something different from what I meant. But I supposed that basically any device classes are supported and the device is just supposed to mitigate hidden attacks. Provided that keyboard (and another potentially malicious inputs) is (/are) not whitelisted, my attack would not work. The merit of the social engineering was rather to persuade the user to perform the power cycle than to persuade user to completely bypass the security measure.
On Sunday, September 13, 2015 at 3:03:39 AM UTC+2, Robert Fisk wrote:
I wouldn't rely on the USBProxy to keep you safe. If a device can own
your linux box over USB, then it can also own your linux box after first
owning linux on the BeagleBoard.
So it might slow an attacker down but it won't stop them.
Well, it depends. It is probably not so hard to configure Linux box to refuse all keyboards. Such attack might be also mitigated by having nothing interesting that can accept the user input. (I.e. when the box accepts keyboards, it can be used for no log in, so the attacker might effectively send just ctrl+alt+delete or maybe some sysrq commands.)
On the other hand, Linux kernel might have many many potentially exploitable USB features, and maybe it is not so easy to disable all of them. So, the Linux might be more likely to be vulnerable.
There seems to be some software-based mitigations of BadUSB attacks like disabling USB keyboards:
a. udev rules – this one looks like some race condition, but it should be likely to prevent such attacks:
https://security.stackexchange.com/questions/64524/how-to-prevent-badusb-attacks-on-linux-desktop
b. GRsec kernel
Regards,
Vít Šesták 'v6ak'
Vít Šesták
Sep 15, 2015, 4:02:20 PM9/15/15
to qubes-users, marm...@invisiblethingslab.com, groups-no-private-mail--con...@v6ak.com, rober...@fastmail.fm
One more possible USB attack: USB GPU or USB HDMI port might allow capturing video and audio.
On 09/15/2015 04:49 PM, Jonathan Brown wrote:
Well, there were some attempts to bring GRSecurity to Qubes, maybe for both AppVMs and dom0. Something seemed to work properly, some features caused some problems. As far as I know, there is nothing such merged in official Qubes tree.
Benefits of grsecurity for Qubes – I believe there are some benefits (depending on the configuration), but they are probably lower than with standard Linux distributions. For example, you usually don't care about local privilege elevation with Qubes, as there is a different security model.
Regards,
Vít Šesták 'v6ak'
On 09/15/2015 04:49 PM, Jonathan Brown wrote:
Anyone know if dom0 is utilizing grsecurity and if would be beneficial?
Well, there were some attempts to bring GRSecurity to Qubes, maybe for both AppVMs and dom0. Something seemed to work properly, some features caused some problems. As far as I know, there is nothing such merged in official Qubes tree.
Benefits of grsecurity for Qubes – I believe there are some benefits (depending on the configuration), but they are probably lower than with standard Linux distributions. For example, you usually don't care about local privilege elevation with Qubes, as there is a different security model.
Regards,
Vít Šesták 'v6ak'
Reply all
Reply to author
Forward
0 new messages