I would never have imagined that the term ‘air-gapped’ even includes systems that have had a usb device plugged into them that was ever plugged into a non-air-gapped system. If someone sent me confidential documents on a usb drive my first thought would be ‘damn there is probably all sorts of malware on this’. Also people forgetting to disable autorun on a windows machine with sensitive material on it… When I saw the headline I was expecting something much more sophisticated.
All the air-gapped systems and networks I’ve had the pleasure of working on all used CDs and DVDs as their method of data transfer. When we would ship air-gapped systems to particular customers, we would fill all USB ports with epoxy resin.
I’ve always been fascinated with air-gapped systems/networks so thanks for the post/background. Is there a reason why y’all don’t just ship systems without USB ports altogether, or is it cheaper to grab an off-the-shelf system and then airgap it rather than build a custom PC for that purpose?
In a lot of cases, they don’t actually epoxy the USB ports, they fit removable covers on them. It turns out that they’re actually useful for debugging purposes, as long as you can restrict their use to authorised people.
Back in the early Xen days, a certain three-letter agency looked at using direct device pass through of one NIC to an untrusted VM to avoid the need for separate computers for their secure and insecure networks. The idea was to have a separate NIC for the insecure network and run insecure machine as a VM. Even without VM escapes, they were concerned that you could establish a covert channel based on the interrupt latency of the insecure NIC and exfiltrate data.
My favourite air-gap side channel attack was a Tor node decloaking attack from Stephen Murdoch and friends. He discovered that the temperature change from a Tor node processing a lot of traffic was detectable from the thermal sensors in other machines in the same rack (and probably from other machines in nearby racks with more samples). If a nation-state adversary can buy space in the same co-located datacenter as your Tor node, then they can start to unpeel the onion.
Back in the early Xen days, a certain three-letter agency looked at using direct device pass through of one NIC to an untrusted VM to avoid the need for separate computers for their secure and insecure networks.
That’s really funny to learn. In the early VMware days (late 2000 or so) that same three-letter agency wanted us to partner with HP to deliver “NetTop”. The idea is to run SELinux on the host, and then use its restrictions to run multiple Windows VMs at different classification levels.
It didn’t pan out, since the NSA security team was able to send a half a bit per second or so of data from a cooperating process in the high security VM to a cooperating process in the unclassified VM by attaching and detaching virtual USB devices, and measuring the timing perturbations in the other VM. No doubt there were many other timing side channels they could have used.
There were running jokes for years internally along the lines of “Out for vacation all next week. If you need to reach me, simply plug and unplug virtual USB devices in the agreed upon pattern…”.
Not really at the same level, but when I did my thesis at a large Swedish telecommunications manufacturer in the late 90s I heard of someone bypassing the firewall by accessing a machine that wrote data from the WAN onto a hard drive, which was then read by the LAN interface, and vice-versa. Slow but if you want to access Slashdot, needs must.
Seems to me that it is also expedient to reinstall the OS, preferably with non-windows. I understand it depends what you are doing but if I would think about using raspberry pi or better yet, arduino. Then desolder any communication hardware from the board. You would have to use only self built or self programmed software so if you are doing anything more complicated than reading documents it could be an issue. This was another thing that surprised me about the article. If one is doing something this sensitive why would one trust a vendor installed OS? Or one with as commonly compromised as windows?
Fortunately for Israel, the folks working at the Iranian nuclear facility did not have the same mindset and plugged in a USB stick containing malware that infected the control systems of their centrifuges and destroyed them.
This is a very thought-provoking read for any security professional. One serious consideration for folks imagining how to build air-gapped systems: This document is aimed at a Windows-oriented world, and their recommendations are tailored towards Windows users. We should be suspicious of USB for air-gapped machines running Free Software, but we should not imagine FireWire, Thunderbolt, or other DMA-oriented expansion ports to be more secure options.
It’s worth noting that the threat model for most existing IOMMUs is to protect isolated software entities (VMs or processes, that have access to the device) from using devices to attack other software entities outside of their protection boundary. The devices are assumed to be trusted. Every device has an ID on the PCIe bus and can access only mappings that are granted to that device. That ID is in the packet sent over the bus and is 100% under the control of the device: a malicious device can impersonate any other device and can DMA to and from any memory that any device is allowed to access. If your device is allowed to use the Address Translation Extensions, then it is allowed to set a bit in the DMA packet saying ‘trust me, I am following the rules of the IOMMU, but I cached this translation, and it’s totally fine’ and completely bypass the IOMMU.
If your threat model is folks who can attach something to the machine, then you definitely don’t want them to have access to anything like ThunderBolt that encapsulates PCIe.
There are some proposals working their way through the PCIe SIG at the moment that improve this situation, giving end-to-end encryption to devices (so one device can’t impersonate another or snoop on traffic) and giving attestation of device identity so that you can restrict access to ATS to devices that the system trusts.
I would never have imagined that the term ‘air-gapped’ even includes systems that have had a usb device plugged into them that was ever plugged into a non-air-gapped system. If someone sent me confidential documents on a usb drive my first thought would be ‘damn there is probably all sorts of malware on this’. Also people forgetting to disable autorun on a windows machine with sensitive material on it… When I saw the headline I was expecting something much more sophisticated.
All the air-gapped systems and networks I’ve had the pleasure of working on all used CDs and DVDs as their method of data transfer. When we would ship air-gapped systems to particular customers, we would fill all USB ports with epoxy resin.
no data-diodes for inbound? (or if so, what COTS products have you found for that).
I’ve always been fascinated with air-gapped systems/networks so thanks for the post/background. Is there a reason why y’all don’t just ship systems without USB ports altogether, or is it cheaper to grab an off-the-shelf system and then airgap it rather than build a custom PC for that purpose?
In a lot of cases, they don’t actually epoxy the USB ports, they fit removable covers on them. It turns out that they’re actually useful for debugging purposes, as long as you can restrict their use to authorised people.
Back in the early Xen days, a certain three-letter agency looked at using direct device pass through of one NIC to an untrusted VM to avoid the need for separate computers for their secure and insecure networks. The idea was to have a separate NIC for the insecure network and run insecure machine as a VM. Even without VM escapes, they were concerned that you could establish a covert channel based on the interrupt latency of the insecure NIC and exfiltrate data.
My favourite air-gap side channel attack was a Tor node decloaking attack from Stephen Murdoch and friends. He discovered that the temperature change from a Tor node processing a lot of traffic was detectable from the thermal sensors in other machines in the same rack (and probably from other machines in nearby racks with more samples). If a nation-state adversary can buy space in the same co-located datacenter as your Tor node, then they can start to unpeel the onion.
That’s really funny to learn. In the early VMware days (late 2000 or so) that same three-letter agency wanted us to partner with HP to deliver “NetTop”. The idea is to run SELinux on the host, and then use its restrictions to run multiple Windows VMs at different classification levels.
It didn’t pan out, since the NSA security team was able to send a half a bit per second or so of data from a cooperating process in the high security VM to a cooperating process in the unclassified VM by attaching and detaching virtual USB devices, and measuring the timing perturbations in the other VM. No doubt there were many other timing side channels they could have used.
There were running jokes for years internally along the lines of “Out for vacation all next week. If you need to reach me, simply plug and unplug virtual USB devices in the agreed upon pattern…”.
Not really at the same level, but when I did my thesis at a large Swedish telecommunications manufacturer in the late 90s I heard of someone bypassing the firewall by accessing a machine that wrote data from the WAN onto a hard drive, which was then read by the LAN interface, and vice-versa. Slow but if you want to access Slashdot, needs must.
Yeah. We had some rather special requirements regarding all ports, not just USB. :-D
Using COTS is much cheaper and enabled us to more easily customize the system based on customer needs.
Seems to me that it is also expedient to reinstall the OS, preferably with non-windows. I understand it depends what you are doing but if I would think about using raspberry pi or better yet, arduino. Then desolder any communication hardware from the board. You would have to use only self built or self programmed software so if you are doing anything more complicated than reading documents it could be an issue. This was another thing that surprised me about the article. If one is doing something this sensitive why would one trust a vendor installed OS? Or one with as commonly compromised as windows?
Fortunately for Israel, the folks working at the Iranian nuclear facility did not have the same mindset and plugged in a USB stick containing malware that infected the control systems of their centrifuges and destroyed them.
How do they protect against malware in the BIOS, UEFI, and other firmware shipped on motherboard chips by the manufacturers?
This is a very thought-provoking read for any security professional. One serious consideration for folks imagining how to build air-gapped systems: This document is aimed at a Windows-oriented world, and their recommendations are tailored towards Windows users. We should be suspicious of USB for air-gapped machines running Free Software, but we should not imagine FireWire, Thunderbolt, or other DMA-oriented expansion ports to be more secure options.
It’s worth noting that the threat model for most existing IOMMUs is to protect isolated software entities (VMs or processes, that have access to the device) from using devices to attack other software entities outside of their protection boundary. The devices are assumed to be trusted. Every device has an ID on the PCIe bus and can access only mappings that are granted to that device. That ID is in the packet sent over the bus and is 100% under the control of the device: a malicious device can impersonate any other device and can DMA to and from any memory that any device is allowed to access. If your device is allowed to use the Address Translation Extensions, then it is allowed to set a bit in the DMA packet saying ‘trust me, I am following the rules of the IOMMU, but I cached this translation, and it’s totally fine’ and completely bypass the IOMMU.
If your threat model is folks who can attach something to the machine, then you definitely don’t want them to have access to anything like ThunderBolt that encapsulates PCIe.
There are some proposals working their way through the PCIe SIG at the moment that improve this situation, giving end-to-end encryption to devices (so one device can’t impersonate another or snoop on traffic) and giving attestation of device identity so that you can restrict access to ATS to devices that the system trusts.