Using infected USB devices safely on Qubes

User Support
1

This has been addressed here https://forum.qubes-os.org/t/badusb-qubes-questions/2319?u=qqubes, but it is crucial that I don’t make a mistake so I want to double check my understanding.

I have USB drives that have been used with a seriously compromise system and a compromised smartphone that I want to plug into the USB port of my Qubes OS system.

Assuming I don’t get snagged by unknown bugs, will the following procedure ensure that my Qubes system is not compromised?

  1. Do not plug in any USB devices before Qubes is up and running.

  2. I have a PS/2 keyboard and touchpad, and a default sys-usb VM that automatically connects to my USB mouse. To be safe and make sure the infected device doesn’t get attached to sys-usb, I can shut it down in this step.

  3. Create a disposable usb VM, and set the policy to not allow any input devices.

  4. Start the disposable usb qube, and plug in my infected device.

  5. Attach this device to the disposable usb qube, and do my thing with the infected USB device.

  6. Detach device, shutdown vm

Thanks in advance

1 Like
2

what is your thread model, this might fine for people who almost “having nothing to hide” (offline pc to play locally installed game), but might not for you

what you mean here?

3

The threat model is actually irrelevant to my question, but you may assume life and death (it isn’t in reality though). By “safe” I mean safe from comprise.

By compromised, let’s say anyone besides myself being able to read/write data on my system, including conduct surveillance such as reading my email while I am viewing webmail in a browser.

4

@qqubes

If I had a touch pad on a completely different PCI controller, “USB mouse” wouldn’t even be part of the discussion. I would unplug it and throw it in the trash.

If I had a fully volatile named disposable USB VM that was not networked, no other USB devices attached, all USB devices hidden from dom0 and no USB devices configured to pass through to dom0 (no mouse and no keyboard), then I would be relatively confident about plugging in the USB drive.

If I was feeling paranoid, I might have a dom0 terminal open with qvm-kill sys-usb typed and ready to execute. Maybe a sys-usb terminal open with sudo reboot or sudo poweroff typed and ready to execute as well.

But the more I think about it, the more I would be interested in monitoring and logging as much device activity as possible rather than blocking it from acting as an HID. I would want the device to “do it’s thing” so I could confirm if it was indeed “bad”.

I would be strongly inclined to leave sys-usb completely out of the picture and attach the USB device to a new, fully volatile VM based on the Kali template (with the PCI controller directly attached) so I would have more forensic tools available - and possibly create a ‘dummy’ VM (also based on Kali) that acts as the netVM (without actually connecting to the internet), so I could simulate incoming traffic and monitor network activity.

Of course, once I realized that I have no experience using most of the tools availabe in Kali and know nothing about forensics or hacking, I would quickly put on a hoodie and dark sunglasses so I at least looked like I did. Then when I discovered that the USB drive was just a regular USB drive with no malicious payloads, I would quietly tell myself I knew it all along! :smile:

1 Like
5

No, it isn’t.

In this case you should not rely on community volunteers and ask a real security expert.

Correct.

Looks right.

This policy is the default for a new usb qubes AFAIK. This step can be improved if you hardware allows that and if your threat model implies that usb controller firmware can be compromised. You should put separate USB controllers into the main sys-usb and the secondary one, if you have more than one usb controller. Some of these devices allow that.

In theory, a malicious USB device can not just compromise the OS in the sys-usb qube but also the USB firmware. See also: Reset / reinstall USB qube after compromise.

As a side note, I also recommend to create a disposable sys-usb for everything, including your mouse. By the way, it’s a default in Qubes 4.1.

See also: Proposed procedure for using untrusted USB drives.

2 Likes
6

The problem is there - “I want to plug into the USB port of my Qubes OS
system”.
You don’t want to do this at all.
What you want to do is get at the data on those drives.

The steps you propose may be adequate in dealing with data.
But if the system is “seriously compromised” I would do nothing like
this at all.
A major risk is in infecting the USB controller firmware.
One way round this is to use a burner to get the data off the
drives. You could transfer the data in to Qubes across the network: then
sanitise and scan as best you can.
Depending on your risk model (and that really is important), this may
be adequate.

If it really were a matter of life and death, you would ditch the
drives - under no circumstances would you plug them in to an important
system.

3 Likes
7

I’d also back everything up too in case s*** really hits the fan.

8

OK, point taken. Though someone may not be able to afford a real expert, or know where to find a capable one.

This gets to the main point of my question. So “in theory” it is not safe to use infected USB devices. In that thread @unman says “If the device has attacked the USB controller, then it’s done,
and nothing in Qubes will help.” but does not elaborate.

On the other hand, if it can only infect the controller attached to the VM, then I might be able to keep the other controllers “clean” (I still have to check whether I have more than one USB controller).

Also, you choice of words “in theory” makes it sound like it is questionable whether this had ever been done before.

So in that thread, @unman again states that a USB device attacking the system controller is a viable threat.

On the other hand, @alx’s post suggests this may not be the case:

Does anyone have further information on this topic so I can make an informed decision about the safety of using potentially infected USB devices?

1 Like
9

For the USB drives, yes 100% correct and so far I have been sending the data across the network (from the compromised system, encrypting the data before the compromised system is allowed to connect to the internet. I realize this is probably not foolproof, but good enough for my actual threat model).

However, for the smartphone I would like to perform forensics as @necker suggested, since I strongly believe it has been compromised (for the computer system there is no question about compromise, btw). I also may need to connect it to a USB port to transfer the data to a new clean smartphone.

Aside: The Qubes project has been extremely helpful it reasuring me that I can use my computer in privacy. However, I have no such reassurance for using my smartphone. If anyone has pointers to information on how to secure a smartphone I would be grateful. Apologies if this should have only been mentioned in a new thread.

So while @fsflover says this could happen “in theory” you are saying it is a major risk. Do you have any references to more information about such an attack?

Also, from what you have said in other threads, it seems that this can be done safely, even in a life or death threat model, if the system has multiple USB controllers and one of those controllers is restricted for use with untrusted devices.

1 Like
10

@qqubes

Regarding USB devices, I whimsically entertained the idea of using a Kali Qube to analyze an untrusted USB device after you explicitly said that the threat was not life and death. I’m sure there are better approaches. Kali isn’t exactly a Blue Team favorite. :laughing:

I wasn’t aware that the USB host controller was vulnerable to firmware attacks via a malicious USB device in a disposable USB qube. It certainly seems plausible considering that sys-usb is in HVM mode and exposes the device directly to the PCI. I always wondered about that.

Given the confidence of most Qubes users who talk about sys-usb vs badUSB, I assumed that Xen somehow mitigated the direct exposure to PCI hardware and IOMMU prevented subsequent compromise on system memory beyond the domain of sys-usb.

I certainly appreciate @unman’s willingness to stand alone in his warning about potential risks. What a relief. Most of the information available about Qubes makes it seem like disposable VMs have the power to turn real attacks into bad dreams… only requiring a reboot to wake up… It’s a sobering reminder that all forms of defense have their limitations.

Also… I did not suggest forensic analysis of your smart phone. That is far more complex than a USB device and likely requires specialized equipment to properly handle it. I would also be extremely wary of attempting to “transfer” anything from it to a clean device. If there is any way to manually enter necessary information into your new phone or get the data from a trusted source, do that. How can you be sure that the data you transfer doesn’t contain compromised files? I’m not even sure it’s possible to guarantee that.

1 Like
11

I am another qubes user who’s wondered about USB controller firmware. I’m not current on the topic but here’s some traces of information I just found again.

I didn’t research further, or test ASMTool, but presume the risk is more than theoretical. Maybe someone more knowledgeable will comment.

Best regards…

1 Like
12

Hmm - I don’t claim to be more knowledgeable.
But it is possible to update firmware on some USB controllers, just as
it’s possible to update firmware on some USB devices.
Researchers have found that manufacturers will switch between different
chips - some may be updateable , some not - on the same device.

So, since the firmware on the controller can be attacked, and malicious
USB devices can be used to download and attack hosts, the attack is more
than theoretical.

Note that there’s no requirement that the USB device be attached to the
controller that is being attacked.

Take a look at https://opensource.srlabs.de/projects/badusb:
“One interesting point about hubs, however, is that many main boards
(and Notebooks) contain a USB hub. If the hub is reprogrammable (which
is often the case for USB3.0 hubs), this allows persistent infection of
the main board even if the BIOS/UEFI is protected against
unauthorized/unsigned upgrades.”

That said, for most cases, keeping separate controllers for separate
uses looks like good practice.

3 Likes
13

Hmm - I don’t claim to be more knowledgeable.

unman I’ve found your contributions, both past and present, to be
immeasurably helpful and educational (i.e. you’re a guru, thank you!).

Thanks for helping clarify the potential threat to USB controller
firmware from USB devices.

Note that there’s no requirement that the USB device be attached to the controller that is being attacked.

Unsure I understand this note. Does this mean an attack launched from a USB controller assigned to one sys-usb could succeed against a 2nd USB controller assigned to another sys-usb (e.g. malicious USB device attached to sys-usb-untrusted-dvm could compromise 2nd USB controller assigned to sys-usb-trusted)? Put another way, would two physically discrete USB controllers (not a hub in disguise) be vulnerable to each other’s devices? Even if they are separately assigned to two properly configured sys-usb qubes? Or… Did I completely misunderstand this note?

1 Like
14

Hmm - I don???t claim to be more knowledgeable.

@unman I’ve found your contributions, both past and present, to be
immeasurably helpful and educational (i.e. you’re a guru, thank you!).

Thank you.

Thanks for helping clarify the potential threat to USB controller
firmware from USB devices.

Note that there???s no requirement that the USB device be attached to the controller that is being attacked.

I believe the two controllers would have to be attached to the same qube

  • this is why I advocate a separate usb qube for each controller.
1 Like
15

My mind goes to a non-Qubes solution, to wonder how that solution might apply to Qubes.

Puppy Linux tries to load the entire OS into main memory. For a problem like this, one would start up Puppy Linux for just using one USB key, and immediately shut it down Puppy after using it.

Leaving me with the thoughts of whether the USB Controller has some kind of malware debris left?
Or whether main memory has some kind of debris left in it?
Plus whether, if I boot Puppy Linux from a USB key, that boot Key might have been infected by the USB from the key that might have malware on it.

I am not an expert on how the USB malware is passed around. Or when the USB controller is re-loaded with an honest copy of USB firmware. I would guess on booting the Operating System.

Some of the folks on the Puppy Forum had suggested that the most secure form of Puppy Linux, was to use a re-writeable optical Disk. In an application such as working with a USB suspected of having Malware, (perhaps they all should be) I think an boot from optical disk would be best.

Tails Linux, booted from an optical disk might be a better solution. I think part of the Tails goals was to wipe RAM after use. Guessing all the stuff that might in a cache somewhere, or residing on the Bus. Hmm. My lack of knowledge of hardware can’t answer the point.

I think sometimes of obtaining the IBM desktop that is of the same as the Lenovo X-230, as it does not use a USB Mouse, or USB Keyboard. In this case, I would have to be sure the firmware that goes to the optical drive has not been corrupted. If the thing would function without a hard drive, disconnect the hard drive.

Perhaps try to copy the information I want from the suspect USB to a less corruptible area. Used to be possible to boot a Puppy ISO from CD. Remove the Puppy CD, and use the Optical Drive again. Suggesting the possibility of copying the Suspect USB to a blank Optical Disk, which removes only part of the problem, but makes it more secure to use the suspicious Optical Disk with Qubes, with some carefulness.

Is there a way to write over all of RAM that a Qube is going to use - As the Qube is starting. Is it possible to write over the RAM from a Qube, as it is shutting down. What about the information that is being exchanged to Dom0? Overactive imagination. What about a selection to overwrite all of RAM on Shut Down/Power Off.

I don’t have solution. Just more questions, that I felt others might find interesting.

16

The problem you’re trying to solve (and cyber security in general) is about skills, not about using a specific “Red Team” OS.

1 Like
17

Shouldn’t it be the default in Qubes OS then?

18

Frankly, new users have enough problems with one sys-usb.

19

I actually don’t see how several sys-usb qubes should make things much more complicated. New users generally don’t do anything with their sys-usb qube(s), instead using Qubes Devices widget. I guess this widget can transparently work independently on the number of sys-usb qubes.

20

In my experience, they do.
I also promote having separate sys-usb per NIC, but again, not for new
users.