If your machine has a USB port, it's no longer properly isolated.
Obviously that's a tremendous pain to work with, because you're limited to PS/2 keyboards and mice (etc etc), but given that there's no way of authenticating USB devices and they've already been used in various attacks, a serious airgap protocol has to ban USB ports.
You could quite easily hide a USB mass storage device inside a mouse, or with a bit more work have an unmodified mouse with a spare Flash area used for data exfiltration.
(Firewire is even worse, and Thunderbolt lets you onto the PCI bus)
This is slightly too strong – it should be “has to ban unsecured USB ports”. By 2002 or so, people I met who worked at SPAWAR were advising conference attendees to follow their standard practice of epoxying necessary USB devices to the computer and completely filling unused ports. That moved USB into the same difficulty class as other physical access attacks, which they were already depending on building security to restrict.
Also note that while it's true that Firewire and Thunderbolt are definitely still riskier, newer versions of Windows, OS X, and Linux can use the IO-MMU to prevent DMA attacks. That started shipping in OS X 10.7 and Windows 8.1 (only when locked) and OS X 10.8 enables that all of the time for hardware made around 2012 and later.
If you just leave away the USB mass storage kernel module when compiling the kernel, the mass storage device won't work anymore while the mouse still works. I wonder if this is a solution to this problem or not since it seems quite naive.
This is not sufficient. One known vector is to emulate a USB network device that provides a nameserver via DHCP, but no default route,allowing the attacker to MitM chosen connections. And of course you have a plethora of different USB device types with default drivers that probably contain exploitable bugs.
Just speculating: this might mitigate some kernel level exploits but since its typically usb card <--> usb bus/controller <--> PCI bus, presumably hardware or kernel bugs elswhere in that stack could still be exploited. Interesting thought!
And if that malware can't liberate USB access, and still needs to read data (rather than just writing it), it could exploit the capacity for various devices to emit detectable EM radiation. The fake keyboard/mouse, being inside the Faraday cage, would be able to sense that radiation and extract data that the malware in its payload sends back to it.
In fact, all of this would work equally well with a PS/2 port.
Too easy to have that undone by a security update later. Better to physically disable the ports (fill them with epoxy for example). Much more foolproof and easy to verify.
> You could quite easily hide a USB mass storage device inside a mouse
AFAIK one could mitigate something like this by really restrictive udev rules only allowing certain usb drivers on certain usb ports (like no usb msc on the port dedicated for keyboard only).
Personally? PC gets locked in a box with some sort of venting. Keyboard / Mouse are plugged in by IT and no one unauthorized has physical access to the PC itself.
If they're serious enough about finding 0 days and exploits to the USB or OS to load this shit any physical access to the box itself is off limits.
This is why you need defense in depth: physical seals on components, either protecting cables or keeping them clearly visible where someone can notice tampering, and – above all – having the physical space setup to strictly limit someone's ability to bring arbitrary objects in or spend time alone with sensitive hardware.
Consider what someone with the time, skill, and access to do that could also do without that: opening the case and directly installing some sort of device, planting a camera which records you typing passwords in (“oops, left my cellphone sitting out. Won't happen again!”), planting a radio receiver which opens up all sorts of side channel attacks, installing a passive network tap, etc.
A guard with a metal detector and strict limits on what you can bring into the building or what tools you can use inside is going to do a better job preventing all of those.
You can mitigate the exploit against standard mass storage drivers, yes, but there are other ways. It appears in this case the host was compromised (so able to override the drivers).
If a userland program can get at the raw HID interface, that can also be used for exfiltration to a tailored device.
I meant, using a physically compromised keyboard that records LED transitions set by the host, since the context was USB devices that look like normal keyboard or mice but actually contain storage.
And they had every login for the network it was found on:
"The library was masquerading as a Windows password filter, which is something administrators typically use to ensure passwords match specific requirements for length and complexity. The module started every time a network or local user logged in or changed a password, and it was able to view passcodes in plaintext."
This was a network authentication module on a domain controller. It's intercepting every low level token used to authenticate a network transaction, including encryption keys.
If security has been penetrated that far you are already owned.
What really scares me are things that can live in firmware; not just on mass storage drives but also in host system firmware. We've let too many dragons breed in dark places in the name of Digital Restrictions Management.
Part of what makes ProjectSauron so impressive is its ability to collect data from air-gapped computers. To do this, it uses specially prepared USB storage drives that have a virtual file system that isn't viewable by the Windows operating system. To infected computers, the removable drives appear to be approved devices, but behind the scenes are several hundred megabytes reserved for storing data that is kept on the air-gapped machines. The arrangement works even against computers in which data-loss prevention software blocks the use of unknown USB drives.
Okay first, it probably doesn't get information from air gapped computers without being plugged in, so let's quit with the voodoo right now. You guys are discounting the possibility of idiocy.
Second, making partitions that windows doesn't see is trivially easy. I went out of my way to buy a 128gb flash drive nearly 10 years ago at great expense, it had a 4gb fat 32 partition which is what Windows would see.
It had an 16gb Linux partition with 8gb of that being an encrypted partition
I installed a bootloader that allowed it to be switched to if plugged in when any computer was starting up
"making partitions that windows doesn't see is trivially easy"
Are we talking "partitions Windows wont mount because they aren't FAT/NTFS" or "partitions that literally do not show up to Windows Disk Management because the disk itself is showing a different capacity. EG: A 16GB USB reporting only 8GB, regardless of the OS installed"
A big chunk of space would take some work, but if you only needed a few KB there is slack space (at least a handful of sectors) on the end of every USB drive that doesn't align with partition sizes. I've used it before to store data on how many times my reformatting tool was used on the disk.
This seems trivial to me. Heck, you could practically make it full out remote exec and grab output from airgapped machines if USB keys were moved between them frequently enough. Serialize and encrypt tiny blob with command, do the same for the output and dump it back on the same USB drive or the next one plugged in, send the data out the next time it's on an internet connected machine... I don't see any challenge or skill involved here. Good post-exploitation malware is often more about doing simple things right than about doing impressive things though I suppose. Having the exploit that allows this attack to happen is the impressive part.
Obviously that's a tremendous pain to work with, because you're limited to PS/2 keyboards and mice (etc etc), but given that there's no way of authenticating USB devices and they've already been used in various attacks, a serious airgap protocol has to ban USB ports.
You could quite easily hide a USB mass storage device inside a mouse, or with a bit more work have an unmodified mouse with a spare Flash area used for data exfiltration.
(Firewire is even worse, and Thunderbolt lets you onto the PCI bus)