[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Plug-and-play sanitization of USB thumb drives

By Nathan Willis
December 17, 2014

Malware is a nasty problem for all computer users, and there are countermeasures available (such as scanning email attachments) to help neutralize malware threats in many common tasks. But there are certain vocations that regularly require people to do risky things like accept a USB flash drive from a veritable stranger. Reporters exchanging information with alleged NSA whistleblowers in dark alleyways is the most dramatic example, but hardly the only one—consider, for example, how many flash drives of unknown provenance are exchanged or handed out at software conferences over the course of the year.

The safe approach to reading the contents of an untrusted flash drive is to only open it on a read-only, live-CD system (not connected to the Internet) and to scan and sanitize the files it contains before opening any of them. But doing this correctly can be arduous while on the road and tricky for those who are not technically inclined. This is where the CIRCLean project comes in: CIRCLean is a minimalist Debian system that turns the Raspberry Pi into an automated USB drive sanitization box.

CIRCLean is a project hosted by the Computer Incident Response Center Luxembourg (CIRCL), which is Luxembourg's national Computer Emergency Response Team (CERT). The goal is to provide a simple method for users to extract the important contents from an untrusted USB flash drive, filtering out any viruses, spyware, and other potentially hazardous hidden payloads—while not endangering the main system, such as the user's laptop.

CIRCLean accomplishes this by turning a Raspberry Pi into single-purpose, black-box tool. The user plugs the untrusted "source" USB drive into one USB port on the Pi, plugs their own "target" USB drive into another port, and only then plugs the Pi into a power source. The Pi boots up (mounting the root filesystem read-only), processes the contents of the source drive, saves sanitized versions of the files onto the target drive, then shuts down. At present, the main threats targeted by the tool are malicious macros embedded in office documents (which are naturally more of a concern for Windows and Mac users) and PDFs with hidden executables (which, at least in theory, can contain JavaScript or even arbitrary executable PostScript code).

No monitor or input devices are required: CIRCLean can provide either of two possible feedback mechanisms to let the user know that the sanitization is complete. The first is through an LED attached to the GPIO headers on the Pi: when the LED is blinking, the process is still working; when the LED switches off, the sanitization is complete and the machine has shut down. Alternatively, the system can play MIDI music over the Pi's audio-out port; again, when the music stops, the process is complete.

The system is built on top of Raspbian (the Raspberry Pi distribution based on Debian), and even includes a subtle security measure intended to evade detection. At boot time, if the OS detects that the only USB devices attached are two mass-storage devices, it launches the CIRCLean sanitization process. If any other combination of USB devices is attached, it boots into the standard Raspbian desktop.

How it works

The genesis of the idea evidently came from security consultant Maya Bonkowski, who spoke to the Raspberry Pi blog in August. Bonkowski said that the Pi was chosen as the hardware platform because of its portability and price. Traveling with a second laptop might be the obvious solution for some journalists or activists that need to sanitize strange USB sticks, she said, but a second laptop can attract suspicion (as well as being bulky). Notably, the Pi also comes without built-in wireless connectivity, which makes it easier to use without worrying about the network.

Bonkowski wrote the first version of the code in 2012 (calling it KittenGroomer), after which Raphaël Vinot took over as lead developer and moved the project to CIRCL. Vinot's code is available on GitHub (still under the name KittenGroomer) and is still the main development branch. CIRCL's official stable branch has been rebranded as CIRCLean. The last update was in October 2014, which added support for NTFS drives and included a handful of security fixes (two Bash vulnerabilities were fixed and the user account that processes the files was removed from sudoers).

The software in the repository is a suite of shell scripts designed to be run on a Raspbian system. The scripts create the necessary user account, install the package dependencies, and sets up the required startup scripts. CIRCL also provides pre-built SD card images for those not interested in installing the software manually.

The goal of the sanitation step is to identify risky file formats and strip out any potentially hazardous content like macros or embedded executables. Currently, the code focuses on four specific file types: "office" documents (meaning word processor, spreadsheet, and presentation files), PDFs, auto-run files, and archive files. Auto-run files are risky for the obvious reason: they execute unknown code. The other three file types can encapsulate hidden executable content even while presenting other, seemingly innocuous (or even valuable) content to the user.

CIRCLean uses Poppler to convert PDFs to HTML documents and LibreOffice to convert office files to PDFs, which are then converted to HTML by Poppler. Archive files are uncompressed with 7-Zip, then their contents are processed file-by-file, and the results placed into a new archive file on the target drive. Auto-run files on the source drive are simply ignored; all other document types are copied without conversion. Executables, although not converted, are renamed, with DANGEROUS both prepended and appended to the original file name.

That is a relatively short list of file types to sanitize, but it accounts for the largest threats (particularly in the Windows world). There are also ways for image and multimedia files to contain malware, of course. Bonkowski said on the Raspberry Pi blog that there were already other tools that can convert such media files to safe formats before opening them—but it is nonetheless a curious omission. There are also issues open on GitHub to deal with other file types, such as Java, which in early versions of CIRCLean was not correctly treated as an executable file type (although one might well ask whether it is ever a good idea to run Java code supplied by a stranger).

As a practical matter, it may be more of a problem that CIRCLean's file-conversion step could lose important information if, for example, the LibreOffice conversion is imperfect. With undocumented proprietary file formats—particularly with recent revisions—even LibreOffice occasionally fails to understand some obscure structures.

The known issues include the fact that images are not extracted from PDF files—only text—and that only the first page of a multi-page spreadsheet is properly converted to HTML. On this latter point, however, the project notes that this should be enough to determine whether or not the contents of the file is interesting enough to follow-up on and, if so, that can be done later when additional precautions can be taken.

A similar case could be made for not sanitizing other less-common formats—Photoshop macros, for example. But the biggest omission at this point seems to be the handling of HTML files and email, which can contain active content as well as links to remote content that could be used to track the user. And HTML is widespread enough as a document format to be plausible content on a USB stick (perhaps converted by Microsoft Word).

The correct approach for the user would be to only open HTML documents in an offline browser with JavaScript deactivated; perhaps that is well-known enough these days that a special tool is not required. After all, the Edward Snowden and Wikileaks stories of the past few years have the raised the profile of a number of valuable security tools like Tor and TAILS.

There are still areas where CIRCLean can be improved. For example, there is an issue open to deal with BadUSB-style attacks, in which a thumb drive mimics another device type (such as a keyboard) with malicious intent. Vinot has indicated one possible solution already: blacklisting all non–mass-storage USB kernel modules. Without USB HID support in the kernel, a malicious drive cannot mimic a keyboard. In an email, Vinot described a few other ideas, such as converting PDFs to the more restrictive PDF/A format before converting them to HTML.

CIRCLean serves a purpose distinct from both of those projects; its ideas may influence them in interesting ways, but the niche it fills is important, too: that of a file-sanitization appliance that works quickly and simply. One report cited on the CIRCLean site notes that up to 66% of USB keys in the wild may contain malware—so it is hard to be too careful.

Index entries for this article
SecurityMalware
SecurityVirus scanning


to post comments

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 5:20 UTC (Thu) by Thue (guest, #14277) [Link] (3 responses)

> The safe approach to reading the contents of an untrusted flash drive is to only open it on a read-only, live-CD system

This is not really safe. Both hard disks and USB devices built into your computer may have non-volatile storage where malware can permanently install itself. And neither hard disks or USB drives seem to have much security preventing the flashing of their firmware with malware.

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 17:31 UTC (Thu) by flussence (guest, #85566) [Link] (2 responses)

Don't forget the BIOS - modern PCs have sufficiently bloated and buggy firmware that you can hide all kinds of nasty stuff right on the motherboard with little effort.

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 18:05 UTC (Thu) by nix (subscriber, #2304) [Link]

As soon as anything can get into a high enough privilege level, it has megabytes of otherwise-inaccessible RAM, too -- the SMRAM. (God and firmware vendors alone know what that's used for on non-malware-infested systems.)

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 18:21 UTC (Thu) by raven667 (subscriber, #5198) [Link]

uEFI SecureBoot is at least trying to at least provide some mechanism to prevent bogus code from living in the motherboard firmware but it's reach is limited.

PDF to HTML

Posted Dec 18, 2014 6:54 UTC (Thu) by brouhaha (subscriber, #1698) [Link] (4 responses)

I haven't tried PDF-to-HTML conversion with Poppler, but I've never been happy with any of the other PDF-to-HTML converters I've seen. I think it's great that CIRCLean is doing something about it, and I'm not trying to criticize their work, but it does seem possible to do better.

As far as I've seen, all the PDF exploits are either embedded Javascript, or malformed PDF data structures or images. I've always thought that adding Javascript to PDF was a horrible mistake. PDF was originally, by design, a non-scriptable file format, and should have stayed that way.

In the past I've written a few programs that generate PDF, and one that consumes it, so I'm somewhat familiar with the structure of PDF files, though not with recent extensions. It should be possible, and not even exceptionally difficult, to strip Javascript out of PDF files, without having to convert them into a non-PDF format. It also shouldn't be too difficult to validate that the PDF and embedded images, fonts, etc. are well-formed, and strip out any malformed constructs that could break PDF viewers that aren't coded sufficiently defensively.

Another possible approach would be a PDF-to-PDF renderer. It wouldn't specifically seek out bad stuff in the input file, but it would be designed to only be able to write valid PDF constructs with no Javascript to its output file.

PDF to HTML

Posted Dec 18, 2014 8:48 UTC (Thu) by mjthayer (guest, #39183) [Link]

Couldn't this sort of thing be done at least to some extent on a normal system too? Windows and OS X have, if I remember correctly, a feature for marking files from the Internet and USB sticks as "untrusted" until the user tells them otherwise, and preventing normal applications from opening them. Following similar logic, the sanitiser application could be made the default for untrusted files.

(And of course, while the article was not about BadUSB, there have also been lots of ideas about dealing with that. Not enabling unknown devices by default seems like a good start, and perhaps a graphical dialogue box showing the user a picture of their computer and where the device is plugged in, so that they can confirm it is what it claims to be.)

PDF to HTML

Posted Dec 18, 2014 16:19 UTC (Thu) by anselm (subscriber, #2796) [Link] (1 responses)

It should be possible, and not even exceptionally difficult, to strip Javascript out of PDF files, without having to convert them into a non-PDF format. It also shouldn't be too difficult to validate that the PDF and embedded images, fonts, etc. are well-formed, and strip out any malformed constructs that could break PDF viewers that aren't coded sufficiently defensively.

That sounds like a job for Ghostscript.

PDF to HTML

Posted Dec 22, 2014 7:37 UTC (Mon) by kleptog (subscriber, #1183) [Link]

Indeed. I've used ghostscript to postprocess PDFs generated from other sources to do things like resample images and subset embedded fonts, mostly to make the resulting PDF smaller and load faster. But as a side-effect it'll toss out any scripts and other crap lurking in there.

This actually rerenders the PDF to PDF, which seems safer then trying to strip stuff out.

PDF to HTML

Posted Dec 18, 2014 18:06 UTC (Thu) by nix (subscriber, #2304) [Link]

This was what the PDF/A reference at the end of the article was talking about. It looks quite well-suited for this application.

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 11:16 UTC (Thu) by sasha (guest, #16070) [Link] (1 responses)

> and even includes a subtle security measure intended to evade detection. At boot time, if the OS detects that the only USB devices attached are two mass-storage devices, it launches the CIRCLean sanitization process. If any other combination of USB devices is attached, it boots into the standard Raspbian desktop.

So, if the evil USB device reports that it is a keyboard, the Pi boots into desktop, and the USB "keyboard" can type any evil words it has into a friendly desktop system? I'm afraid I completely miss the point.

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 12:15 UTC (Thu) by sasha (guest, #16070) [Link]

I should read the article to the end before commenting:
> there is an issue open to deal with BadUSB-style attacks, in which a thumb drive mimics another device type (such as a keyboard) with malicious intent.

Another approach

Posted Dec 18, 2014 12:34 UTC (Thu) by falor (guest, #100004) [Link] (8 responses)

Sorry for the tangently related point but:

Wouldn't it be a good idea to have an optional mode where users are prompted before registering inserted USB devices? The desktop could show the device's information (brand, model number), *and* the USB class(es) that it is trying to register as.

So if you stick a USB key into your laptop, and it tries to register itself as a keyboard, you'd see something like: "Detected USB Device: USB Keyboard from <USB stick manufacturer>. Do you want to use this device?". And you'd most likely quickly click "No".

I don't know if desktop environments would be able to do this on their own, or would need extra help from the kernel... but either way it doesn't sound like something that should be terribly hard to implement.

Another approach

Posted Dec 18, 2014 14:05 UTC (Thu) by tshow (subscriber, #6411) [Link] (6 responses)

No, your eyes would read as far as "Detected USB Device" and you'd think "stupid thing, of course I want it, I plugged it in, didn't I?" and you'd hit YES every time without reading the rest. 99.95% of the time, you'd be right.

So it's just a cognitive speed bump that messes up your workflow, while making security actively worse by training you to click "yes" on security dialogs without reading them. It's basically a security tripwire that throws false positive alarms almost 100% of its active time.

Microsoft did an extensive field study of this for us; UAC. While they had ulterior motives (mostly it was an attempt to stop software installers from dumping files in OS directories by making that action pop up annoying dialogs), we know from the result that all it really did was train users to recognize the dialogs and hit "yes" without reading them.

Another approach

Posted Dec 19, 2014 0:34 UTC (Fri) by flussence (guest, #85566) [Link] (2 responses)

People don't like reading.

Give them a screenful of visually-distinct icons depicting recently-connected device classes, and tell them to click the one matching what they just plugged in. It takes (hopefully) a deliberate act of cognitive dissonance to screw that approach up.

Another approach

Posted Dec 27, 2014 0:26 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

So now I have to decrypt a screenful of icons, and hope that the designer's depiction of "visually-distinct icons" happens to be comprehensible as matching particular USB device classes without a considerable amount of puzzling -- no matter what culture I come from.

Given the history of icon-driven interfaces, I am not at all confident.

Another approach

Posted Dec 27, 2014 2:09 UTC (Sat) by cesarb (subscriber, #6266) [Link]

> So now I have to decrypt a screenful of icons, and hope that the designer's depiction of "visually-distinct icons" happens to be comprehensible as matching particular USB device classes without a considerable amount of puzzling -- no matter what culture I come from.

Well, a keyboard is easy, a mouse could be represented by a traditional wired three-button mouse, and a joystick by a relatively modern PS or XBOX controller form factor.

It's with dongles that you have to get creative. Visually, one can't distinguish a flash drive from for instance a bluetooth or wifi dongle, their physical form factor is just too similar. Bluetooth and wifi have their standardized logos; as for a flash drive, how about a high-density 5¼ floppy disk drive with the write-protect notch uncovered? ;-)

Another approach

Posted Dec 20, 2014 1:27 UTC (Sat) by rahvin (guest, #16953) [Link] (2 responses)

To effectively execute a badUSB attack the malware in question would need to register TWO devices, one the USBFlash, and two the USBkeyboard/whatever. Because that Keyboard device is worthless without the malware on the flash portion. It would be rather trivial to insert the proposed user question when two new USB devices attempt to register within a very short period of each other.

The chances of encountering such a question in normal usage would be very small. As a result you make your warning nice and scary and I would bet this badUSB attack is mitigated quite well.

Another approach

Posted Dec 20, 2014 9:42 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (1 responses)

Are you quite sure that bad guys can't install malware from your keyboard unless they bring a flash drive?

For example, suppose that for some reason you wanted to install some malware _right now_ would you have to go get a flash drive? Wouldn't you just go to installsomemalware.example.com and thump enter at the confirm step?

Also, the "two devices appeared at once" phenomenon occurs every time I plug my keyboard (which has a mini-hub for a mouse) into the laptop. If I plugged a flash drive into the keyboard (I don't but I can imagine someone might have a good reason) they'd even see your "scary" combination of a new keyboard and a flash drive.

Measures thrown together to defeat a poorly understood ill but without enough thought for the rest of us remind me of that Greg Egan short which ends "ADULTERERS! SODOMITES! MOTHERS BREAST FEEDING INFANTS OVER THE AGE OF FOUR WEEKS! REPENT AND BE SAVED . . ."

Another approach

Posted Dec 20, 2014 12:03 UTC (Sat) by cesarb (subscriber, #6266) [Link]

> Are you quite sure that bad guys can't install malware from your keyboard unless they bring a flash drive?

http://samy.pl/usbdriveby/

"USBdriveby is a device you stylishly wear around your neck which can quickly and covertly install a backdoor and override DNS settings on an unlocked machine via USB in a matter of seconds. It does this by emulating a keyboard and mouse, blindly typing controlled commands, flailing the mouse pointer around and weaponizing mouse clicks."

Another approach

Posted Dec 18, 2014 15:14 UTC (Thu) by zuki (subscriber, #41808) [Link]

There's /sys/module/usbcore/parameters/authorized_default. Should be possible to add a gui to it...
(https://lwn.net/Articles/608585/).

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 20:14 UTC (Thu) by bronson (guest, #4806) [Link] (6 responses)

Do they use stock Raspbian? That thing takes AGES to boot. (I keep meaning to debootstrap a much leaner version but, when I've tried, I run out of time before producing anything interesting...)

> Notably, the Pi also comes without built-in wireless connectivity

Ha, first time I've seen that in the positive feature column. Presumably lack of built-in flash storage is also an asset.

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 21:45 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (5 responses)

Ages? Mine takes maybe 30 seconds (the wireless dongle is by far the longest part though). Or do you mean for X? Mine just boots, sets up some networking then basically sits there.

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 22:41 UTC (Thu) by bronson (guest, #4806) [Link] (2 responses)

30 seconds just to boot and set up some networking? That seems like far too long to me. 934 MB also seems far too large.

I'd like just a super-minimal, super-quick base to build upon. No X, no libreoffice, ... Unfortunatey, all the 3rd party attempts I've found have been buggy or abandoned or both. How hard could it be? (famous last words)

Plug-and-play sanitization of USB thumb drives

Posted Dec 18, 2014 23:02 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Well, "ifup wlan0" takes up around 10-15 seconds there (can't use the networking service because if wireless fails, wired gets shut down too >.> ). I forget what Raspian base I used, but it's pretty bareboned.

Plug-and-play sanitization of USB thumb drives

Posted Dec 22, 2014 7:02 UTC (Mon) by jacmet (subscriber, #19734) [Link]

How minimal do you want it? With http://buildroot.org you can easily build a kernel+initramfs of a few MB booting in seconds

Plug-and-play sanitization of USB thumb drives

Posted Dec 22, 2014 12:17 UTC (Mon) by robbe (guest, #16131) [Link] (1 responses)

Well, the RPi explicitly has the BBC Micro and comparable home computers as its inspiration. Compared to an init time of <1 second, even 15 seem like much. On the other hand, continuing work on something would take ages on these vintage computers...

In the context of the article, 30 seconds is probably dwarfed by USB2.0 transfer times.

Does the Pi not support USB gadget mode? With it, a filter setup would be possible.

Plug-and-play sanitization of USB thumb drives

Posted Dec 22, 2014 18:07 UTC (Mon) by dlang (guest, #313) [Link]

no, the Pi does not support USB gadget mode.


Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds