> If you're designing an airgapped system, this is literally the first thing you should be worried about after ensuring that the system is actually airgapped.

And next time if some other airgapped vuln is reported, that will be literally the first thing people should be worried about! God, people are so stupid, if only they would just do literally the first things they should be worried about.

Good point re. Windows’s default configuration being less secure due to file extensions being hidden. This is another manifestation of the continuous tax paid for Windows’s insane level of backward compatibility. I think the root cause is that Microsoft thinks files ending in .EXE are ugly (but they don’t want to stop using this convention, which I don’t think is strictly required by the kernel or filesystem, but would probably break other things in the OS and 3rd party tools), so they hide that and all other file extensions (which maybe they also think are ugly, but I don’t see an alternative since files with multiple data streams are not handled well for interchange). Not sure why the default isn’t just to hide the extension of executable files, though I think this is more trouble than it is worth, for the reasons demonstrated by this attack.

I would also consider disabling USB ports in air-gapped systems. You can still buy PS/2 keyboards and mice. Server and maybe some workstation motherboards still have PS/2 ports (and there are PS/2 PCI cards). For sneakernet file transfer you can allow use of an SD card. That way, if you see a USB cable or other device in an air-gapped environment, it should be an immediate red flag.

I feel like secure computing environments should be modified to show file extensions at the beginning in order to mitigate human laziness.

The first thing I configure on a new Windows installation is the awful file explorer defaults.

For that matter, would they ever need to move anything executable? Seems to me on Linux they could have just set up a preemptive `chmod -x` of everything copied in from the drive.

How about a USB "MITM" device that presents itself as a serial port to the OS when the user connects a USB storage device.

The user would then use a terminal emulator to connect to something like a BBS[1] where they could browse files, and download or upload files to the connected USB storage device using XMODEM[2] like in the good old days.

edit: It could of course also filter the files, for example not list any executable files, and prevent transfer of executable files based on scanning their contents.

The MITM device would be implemented using a microcontroller with signed firmware, and careful design to prevent a connected USB device to do shenanigans like voltage glitching. This would include using isolated DC-DC and isolated data lines ala like this[3].

The MITM would only interact with the storage device class. If the connected device presents itself as more, say a keyboard, it would just ignore those.

The user must be prevented from bypassing the MITM device, though this could be done through physical means.

[1]: https://en.wikipedia.org/wiki/Bulletin_board_system

[2]: https://en.wikipedia.org/wiki/XMODEM

[3]: https://ez.analog.com/ez-blogs/b/engineerzone-spotlight/post...

Back in a day I've made proof of concept of animated QR codes using fountain codes - txqr. [1] Since then I received a bunch of requests to make into an actual cross-platform app, but never could find the time for this hobby project. I guess I should revive this project and make an usable open-source app.

https://divan.dev/posts/animatedqr/

This is probably a decent use case for plain old serial. Interface via application defined TTY.

On the other hand no matter the transport you’re probably going to get owned by well known vulnerabilities in any software processing data from the internet-connected side, if you’re using the air gap as an excuse to avoid patching or otherwise caring about secure coding practices.

bunnie is trying to solve this sort of problem with Precursor: https://www.bunniestudios.com/blog/2020/introducing-precurso...

Any device without a screen is somewhat useless here, especially for crypto, because you want to see what you are signing before you sign it.

I'm imagining a "secure slate" you can carry between the computers, a tiny tablet with a camera, e-ink display, and replaceable batteries. It does nothing but snap a picture of a QR code and then (if error checking is OK) reproduces it on its own durable display. Add a write-protection switch that doubles as a cover on the camera-lens, and have it auto-blank when not in use.

So you'd snapshot its QR code, hand-carry the slate to air-gapped Computer B, press a button to wake it up, brandish the "copied" QR code in front of B's camera, etc. Maybe even take one and (with careful labeling) put it into a safe, depending on how long you plan to store it.

You could do something similar with a camera and thermal-paper printer, but then the physical artifact needs to be reliably destroyed by manual effort, as opposed to auto-erasure.

This is interesting. Another use for such a secure machine would be to enter text, eg highly controversial blog entries or erotic stories. Then any common computer or phone with a camera can be used to transfer the text using 2D barcodes.

This would be a bit slow: say a barcode. If we assume a single barcode can hold 1500 characters (text twice as long as your comment), a blog entry may need 4-5 barcodes. Not undoable.

Such a machine would not have a camera, WiFi, BT, or any input or output mechanism of any kind.

Why would a QR be more safe from containing malware than another medium like USB drive?

Is it just that the amount of data it holds is more constrained?

I think you're describing WalletConnect without knowing it exists.

Punchcards would be better. QR relies on machine vision. The camera would be running its own code.

That said, cameras are more of a commodity.

QR and typing: see TOTP tokens!

> For many years I've just viewed all of my devices as possibly compromised.

so you consider that someone may be reading and possibly modifying data on any computer/phone you own, okay

> It's one of the reasons I've been very down on cryptocurrencies in general

but you are willing to have form of money that is only accessible via said computer/phone that someone can read and use as if he was you?

how does it work? how's this not a contradiction?

Isn't it easier to just type in what you need?

People had drawn and quartered Microsoft because of simple access elevation prompts (UAC) in Vista, let alone a granular permissions system. It had to be dumbed down significantly over the years to be widely accepted.

People have been doing the same for Apple when it tried to bring explicit app permissions to MacOS. https://tidbits.com/2024/08/12/macos-15-sequoias-excessive-p...

I would imagine these tools use exploits in the existing executables to deliver the payload, and then - if I understand correctly, use scripting/interpreted languages (Python) to run the operation.

So, even if you’d need admin confirmation to run each new binary, it wouldn’t help - because no new binaries are executed, just python with a new set of scripts.

And, correct me if I’m wrong, but preventing os from running new scripts would be virtually impossible.

It used to be you could put a file called autoplay on a USB drive and it would get executed on insertion.

The US has a history of major data breaches by low rank IT security personnel throughout multiple branches of the government. A security monoculture is not necessarily a great approach on the balance of things.

My understanding from the description of the attack is that it didn't rely on any vulnerability in USB, only social engineering made possible by the Windows UI.

About 20 years ago, I was setting up a shared PC at my university. I googled for a way in Windows XP (via registry or group policy) to only let specific programs run. I added stuff like explorer.exe, iexplore.exe, winword.exe, acroread.exe, and a few others.

Fast forward a few years, and the computer was still running great. The desktop and downloads folders were full of messengers, "flash players" and other malware - but all binaries were throwing cryptic error. Since no one in IT was around or cared, nobody figured out how to edit the allow list. The computer was deemed half-broken. But when neighboring PCs were completely infested, this one could still open, edit, and print office docs flawlessly.

It felt like a magic fix for shared Windows PC security.

Since 2008 or so all US government computers on SIPR block USB storage devices are unless they are on an approved list. Autorun is disabled.

Physical security is another big factor, there is a long checklist for a SCIF that at some level takes into account TEMPEST type threats that mitigate many attacks on air gapped systems.

And none of these things are the default on commercial software because users want it to be frictionless. They want software to install right away when you plug in a usb drive, etc.

Well none of them are selling a security product.

There is basically no security focused pc hardware, aside from maybe raptor systems which isn’t really the same ilk.

Off the top of my head, a lot of these devices and hardware were scam traps by LEO.

I’d go on a limb and say this isn’t a problem anyone actually wants to solve.

To my understanding, none of that would have been relevant here. Users copied the executable (disguised as a folder) from the external media (which was one of their own devices, and would have been in the "set of allowed devices" under such a scheme) which was a perfectly normal input device (not some BadUSB hack). It probably wouldn't be hard to get a malware launcher appear "signed", either. Even if we disallow self-signing, the launcher only needs to be a wrapper to start Python (which can be supplied alongside). Such wrappers are provided by Python[1]. I don't know if these are signed normally, but it seems pretty easy to imagine.

All the technical "hacking" happened on the non-air-gapped side, so that that computer would put malware onto the USB with a deceptive presentation (an .exe with an icon to look like a folder and with the same name as an expected folder, while the actual folder was hidden). The rest is social engineering (and Windows not showing the .exe extension).

[1]: `pip3.exe` is an example; it's hard-coded to run the Pip module from `site-packages`, but `pip.py` could be replaced. More to the point, these wrappers are automatically created by Setuptools, to run an arbitrary script specified in the build process, from a "stub" included with Setuptools. (All of this is to work around the lack of support for shebangs, of course.) I don't know if Setuptools can or does sign these wrappers. Probably not.

We recently started enforcing a policy of scanning external media before letting it be usable by the system and the time it takes for MBAM to scan a flash drive takes so long it's driven the most complaints of any IT policy change we've made. Some people are just so latched on to that floppy disk lifestyle that the only change to their workflow in decades has been what part of the computer they put their storage in.

These are all standard security requirements for NATO accredited systems. The human drive for convenience and perhaps a bit darker, to rebel against rules, will always serve as pathways to compromise. And in the case of a powerful hostile actor, bribing someone.

>* disallow anything other than input devices for USB

I think that will greatly reduce the ability to get work done. It's my understanding that the workflow for using these specific airgapped computers involved moving USB thumb drives between computers.

> disallow anything other than input devices for USB

Now you're making me wonder if keyboard firmware could be an attack vehicle.

Most of your list is done inside ATMs and other full-custom secure hardware already.

This was described in the original post[1].

> It is probable that this unknown component finds the last modified directory on the USB drive, hides it, and renames itself with the name of this directory, which is done by JackalWorm. We also believe that the component uses a folder icon, to entice the user to run it when the USB drive is inserted in an air-gapped system, which again is done by JackalWorm.

[1] https://www.welivesecurity.com/en/eset-research/mind-air-gap...

There are many ways. A simple way is to simulate a USB hub with an input device and a usb drive. You use the input device to execute whatever is on the drive. Another way is to identify as a device whose driver has some vulnerability. Windows auto-installs that driver, then you exploit it.

How do they get these USB sticks to execute code, though?

The reporting requirements only come into force 21 months after CRA is enacted, apparently.

https://ec.europa.eu/commission/presscorner/detail/en/qanda_...

No. If you're going to go thru the effort of air gapping, it should be clear that you need to prevent adversaries from getting physical access as well

Yes. https://www.techtarget.com/whatis/definition/air-gapping

I still use floppy drives and don't have to worry about something I plug into my USB port being more than meets the eye.

The standard is to put superglue into the ports.

In my experience it doesn’t stop admins connecting an “offline Root CA” to the WiFi network to install their entire suite of server management software — none of which are functional without an active network connection.

Yes, my plan was to physically remove the wifi adapter daughter card. They exposed the CA to gigabytes of third-party software before I turned up to do the setup. Yes, I warned them not to even take the computer out of the box.

Offline anything just breaks people’s brains.

“How do we keep the anti-virus pattern file up to date?”

“You don’t.”

Reminds me of this ticket [0]. No matter how hard you try to tell people things, sometimes you just can't.

[0] https://github.com/reactjs/react.dev/issues/3896

It's unclear to me why you believe this is relevant here. This attack indeed uses different tooling, and a completely different attack vector (social engineering via the presentation of a malicious executable in the GUI, as opposed to an auto-run exploit).

I don't think so.

> Next, the infected computer infects any external drives that get inserted. When the infected drive is plugged into an air-gapped system, it collects and stores data of interest. Last, when the drive is inserted into the Internet-connected device, the data is transferred to an attacker-controlled server.

This implies the ability to turn a common USB drive into a vector for malware.