6 ms·

CIRCLean – USB key sanitizer

82 points by adulau 10y ago

fluxsauce 10y ago
> The code runs on a Raspberry Pi (a small hardware device), which also means it is not required to plug the original USB key into a computer. This may be splitting hairs, but a Raspberry Pi is a computer. From https://www.raspberrypi.org/ https://www.raspberrypi.org/ > The Raspberry Pi is a tiny and affordable computer that you can use to learn programming through fun, practical projects. The actual project page - https://github.com/CIRCL/Circlean https://github.com/CIRCL/Circlean
ckastner 10y ago
This seems a bit misleading to me. From README.md: This project aims to be useful when you get/find a USB key that you can't trust, and you want to look at its contents without taking the risk of plugging it into your computer directly. Its method of operation is given as: The content of the untrusted key will be copied or/and converted to the second (blank) key following these rules (based on the mime type as determined by libmagic) This process does not make the key trustworthy. From the BadUSB intro: Once reprogrammed, benign devices can turn malicious in many ways, including: 1. A device can emulate a keyboard and issue commands on behalf of the logged-in user [...] 2. A modified thumb drive or external hard disk can [...] boot a small virus, which infects the computer’s operating system prior to boot. Assuming that the first USB stick can infect the second USB stick, CIRClean will not protect you against these attacks.
- leni536 10y ago
  They can mitigate against badUSB by only whitelisting the generic USB mass storage class driver. No keyboard, no mouse, etc... I am not confident they do this though.
  - A1kmm 10y ago
    Looks like they don't, but they turn off usbhid on that particular port: https://github.com/CIRCL/Circlean/blob/master/circlean_fs/root_partition/etc/udev/rules.d/50-blockhid.rules https://github.com/CIRCL/Circlean/blob/master/circlean_fs/ro... However, that could be bypassed if the USB key acted like a USB hub with a keyboard attached. If you do get a keyboard working, it looks like you can just log in with raspberry / raspberry and then full privileged access since sudo from the raspberry user, and /dev/kmem from root is enabled. That would allow arbitrary content to be copied on to the user supplied USB, and depending on the device, possibly firmware reprogramming.
    - leni536 10y ago
      Huh, at least it seems that they care about this attach vector. Blacklisting seems to be the wrong approach.
  - lucb1e 10y ago
    > They can mitigate against badUSB by only whitelisting I'd say just don't run a graphical environment or, if you do, lock it. With a normal password, good luck to the USB thumb drive that pretends to be a keyboard. As for booting, well, don't have it in there at boot time. As for malware in the files itself -- I don't think that's the point of this project. It says "if you don't trust the transport medium (i.e. USB)", it's not about the contents.
- jaclaz 10y ago
  But it's the assumption that is in itself inaccurate. Case #1 is about a modified firmware of the USB controller in the USB stick, case #2 assumes that a boot is initiated from the USB stick. What the Circlean thingy does is more similar to an antivirus, it examines the contents (files) on the USB stick filesystem and only copies to the second stick those files of known type, according to the given rules. Whether this is effective against everything is another thing, of course. Only "plain" files are directly copied, other supported ones are analyzed and converted, some more detiled info is here: https://github.com/CIRCL/Circlean/blob/master/README.md https://github.com/CIRCL/Circlean/blob/master/README.md The thing is not really "new": https://news.ycombinator.com/item?id=8216853 https://news.ycombinator.com/item?id=8216853
  - leni536 10y ago
    No, I think the assumption is entirely correct. If you can't trust a USB stick's contents then you probably can't trust its controller itself. But your OS doesn't have to say "Oh, you are a keyboard? Here, open a terminal and type arbitrary commands." It can say "Sorry, I only talk to USB mass storage class devices."
    - ckastner 10y ago
      What about the pre-boot phase, before the OS is loaded?
      - leni536 10y ago
        1. You can avoid inserting anything before the OS boots up. 2. You can disable booting from USB in the BIOS. However I think you can't disable keyboards there, so a badUSB device can potentially enter the bios, enable USB booting then infect the machine by booting into the virus. Disabling USB booting and setting a strong BIOS password can be safe, I would still prefer the first option though.
        ckastner 10y ago
        Agreed, but in this specific case, CIRCLean depends on the keys being inserted before boot (see steps 2 - 4).
- JohnStrange 10y ago
  Not necessarily, it should be possible to do this correctly, although I doubt this specific device does so. The device itself needs to be hardened against USB attacks, otherwise it would be pointless, of course. Then it copies the contents of the malicious USB stick into a buffer storage, analyses the buffer and cleans up the documents on it, and then it unmounts the first device, mounts the second device and copies the contents of the buffer to it. If it also allows for write-protection, then it might be interesting for forensic work. (AFAIK, USB write protectors cost a few hundred bucks, and maybe this device is the cost range.) The crucial question is, of course, how well the device is hardened against targeted attacks. Just using some seemingly secure Linux won't suffice.
partycoder 10y ago
Not all USB keys can be sanitized. e.g: USB Killer
- flipp3r 10y ago
  Though it's probably cheaper/better to destroy a CIRCLean than to destroy something else
- leni536 10y ago
  One can carefully short its terminals first then pry open the enclosure. Too much capacitors is a no-no.
_pmf_ 10y ago
Keep in mind that it is completely feasible for the µC to activate malicious payloads only after the n-th usage. Kind of like a PS3 exploit worked, albeit not on the descriptor layer, but the MSC layer.
trqx 10y ago
How about sharing the output via WiFi / Bluetooth? That seems quite risky tho, once the device is infected, that would be like washing all your dishes with the toilet sponge. What is the goal of having to reboot at each cycle?
- striking 10y ago
  To guarantee, in theory, that there isn't any contamination between two different flash drives. But in practice, I'm pretty sure that with the right privileges you could just write to the SD card...
  - mbreese 10y ago
    Isn't there also a physical switch on the SD card to mark it as write-protected? I'm sure that could be bypassed, but it would make it more difficult to hide the contamination.
    - XorNot 10y ago
      The physical switch is entirely software implemented.
      - undersuit 10y ago
        Also for Raspberry Pis the connection pin the switch relies on is un-wired.
JulianMorrison 10y ago
What even is the use case for USB sticks these days? Compared to just putting the files in Dropbox. If I found a USB stick, I would just bin it.
- DanBC 10y ago
  Not everyone has decent Internet connectivity. You can dump a bunch of films and tv shows on a USB stick and use that with a cheap laptop for travelling.
- onirom 10y ago
  Owning your data and not letting any third parties its access
- adrianN 10y ago
  I can buy a USB stick with 32 gigs of memory for a couple of Euros and fill it in minutes. My friends can read the stick in minutes, without having to install software.
aymenim 10y ago
>plug a headset and listen to the music that is played during the conversion. When the music stops, the conversion is finished. Bad UX but I guess it works, I would have preferred an LED, on the Raspberry Pi GPIO ports to indicate ready, processing and finished.
- sleepychu 10y ago
  > If you have a Raspberry Pi with a diode, wait until the blinking stops
- deleted 10y ago
  [deleted]
sathackr 10y ago
> In the worst case, only the CIRCLean would be compromised, but not the computer reading the target (trusted) USB key/stick. If the CIRClean device is compromised, I don't see how the trusted USB stick, which is connected to the now compromised CIRClean, can be guaranteed to not be infected.

82 points by adulau 10y ago

> The code runs on a Raspberry Pi (a small hardware device), which also means it is not required to plug the original USB key into a computer. This may be splitting hairs, but a Raspberry Pi is a computer. From https://www.raspberrypi.org/ https://www.raspberrypi.org/ > The Raspberry Pi is a tiny and affordable computer that you can use to learn programming through fun, practical projects. The actual project page - https://github.com/CIRCL/Circlean https://github.com/CIRCL/Circlean

ckastner 10y ago

This seems a bit misleading to me. From README.md: This project aims to be useful when you get/find a USB key that you can't trust, and you want to look at its contents without taking the risk of plugging it into your computer directly. Its method of operation is given as: The content of the untrusted key will be copied or/and converted to the second (blank) key following these rules (based on the mime type as determined by libmagic) This process does not make the key trustworthy. From the BadUSB intro: Once reprogrammed, benign devices can turn malicious in many ways, including: 1. A device can emulate a keyboard and issue commands on behalf of the logged-in user [...] 2. A modified thumb drive or external hard disk can [...] boot a small virus, which infects the computer’s operating system prior to boot. Assuming that the first USB stick can infect the second USB stick, CIRClean will not protect you against these attacks.

leni536 10y ago
They can mitigate against badUSB by only whitelisting the generic USB mass storage class driver. No keyboard, no mouse, etc... I am not confident they do this though.
- A1kmm 10y ago
  Looks like they don't, but they turn off usbhid on that particular port: https://github.com/CIRCL/Circlean/blob/master/circlean_fs/root_partition/etc/udev/rules.d/50-blockhid.rules https://github.com/CIRCL/Circlean/blob/master/circlean_fs/ro... However, that could be bypassed if the USB key acted like a USB hub with a keyboard attached. If you do get a keyboard working, it looks like you can just log in with raspberry / raspberry and then full privileged access since sudo from the raspberry user, and /dev/kmem from root is enabled. That would allow arbitrary content to be copied on to the user supplied USB, and depending on the device, possibly firmware reprogramming.
  - leni536 10y ago
    Huh, at least it seems that they care about this attach vector. Blacklisting seems to be the wrong approach.
- lucb1e 10y ago
  > They can mitigate against badUSB by only whitelisting I'd say just don't run a graphical environment or, if you do, lock it. With a normal password, good luck to the USB thumb drive that pretends to be a keyboard. As for booting, well, don't have it in there at boot time. As for malware in the files itself -- I don't think that's the point of this project. It says "if you don't trust the transport medium (i.e. USB)", it's not about the contents.
jaclaz 10y ago
But it's the assumption that is in itself inaccurate. Case #1 is about a modified firmware of the USB controller in the USB stick, case #2 assumes that a boot is initiated from the USB stick. What the Circlean thingy does is more similar to an antivirus, it examines the contents (files) on the USB stick filesystem and only copies to the second stick those files of known type, according to the given rules. Whether this is effective against everything is another thing, of course. Only "plain" files are directly copied, other supported ones are analyzed and converted, some more detiled info is here: https://github.com/CIRCL/Circlean/blob/master/README.md https://github.com/CIRCL/Circlean/blob/master/README.md The thing is not really "new": https://news.ycombinator.com/item?id=8216853 https://news.ycombinator.com/item?id=8216853
- leni536 10y ago
  No, I think the assumption is entirely correct. If you can't trust a USB stick's contents then you probably can't trust its controller itself. But your OS doesn't have to say "Oh, you are a keyboard? Here, open a terminal and type arbitrary commands." It can say "Sorry, I only talk to USB mass storage class devices."
  - ckastner 10y ago
    What about the pre-boot phase, before the OS is loaded?
    - leni536 10y ago
      1. You can avoid inserting anything before the OS boots up. 2. You can disable booting from USB in the BIOS. However I think you can't disable keyboards there, so a badUSB device can potentially enter the bios, enable USB booting then infect the machine by booting into the virus. Disabling USB booting and setting a strong BIOS password can be safe, I would still prefer the first option though.
      - ckastner 10y ago
        Agreed, but in this specific case, CIRCLean depends on the keys being inserted before boot (see steps 2 - 4).
JohnStrange 10y ago
Not necessarily, it should be possible to do this correctly, although I doubt this specific device does so. The device itself needs to be hardened against USB attacks, otherwise it would be pointless, of course. Then it copies the contents of the malicious USB stick into a buffer storage, analyses the buffer and cleans up the documents on it, and then it unmounts the first device, mounts the second device and copies the contents of the buffer to it. If it also allows for write-protection, then it might be interesting for forensic work. (AFAIK, USB write protectors cost a few hundred bucks, and maybe this device is the cost range.) The crucial question is, of course, how well the device is hardened against targeted attacks. Just using some seemingly secure Linux won't suffice.

partycoder 10y ago

Not all USB keys can be sanitized. e.g: USB Killer

flipp3r 10y ago
Though it's probably cheaper/better to destroy a CIRCLean than to destroy something else
leni536 10y ago
One can carefully short its terminals first then pry open the enclosure. Too much capacitors is a no-no.

_pmf_ 10y ago

Keep in mind that it is completely feasible for the µC to activate malicious payloads only after the n-th usage. Kind of like a PS3 exploit worked, albeit not on the descriptor layer, but the MSC layer.

trqx 10y ago

How about sharing the output via WiFi / Bluetooth? That seems quite risky tho, once the device is infected, that would be like washing all your dishes with the toilet sponge. What is the goal of having to reboot at each cycle?

striking 10y ago
To guarantee, in theory, that there isn't any contamination between two different flash drives. But in practice, I'm pretty sure that with the right privileges you could just write to the SD card...
- mbreese 10y ago
  Isn't there also a physical switch on the SD card to mark it as write-protected? I'm sure that could be bypassed, but it would make it more difficult to hide the contamination.
  - XorNot 10y ago
    The physical switch is entirely software implemented.
    - undersuit 10y ago
      Also for Raspberry Pis the connection pin the switch relies on is un-wired.

JulianMorrison 10y ago

What even is the use case for USB sticks these days? Compared to just putting the files in Dropbox. If I found a USB stick, I would just bin it.

DanBC 10y ago
Not everyone has decent Internet connectivity. You can dump a bunch of films and tv shows on a USB stick and use that with a cheap laptop for travelling.
onirom 10y ago
Owning your data and not letting any third parties its access
adrianN 10y ago
I can buy a USB stick with 32 gigs of memory for a couple of Euros and fill it in minutes. My friends can read the stick in minutes, without having to install software.

aymenim 10y ago

>plug a headset and listen to the music that is played during the conversion. When the music stops, the conversion is finished. Bad UX but I guess it works, I would have preferred an LED, on the Raspberry Pi GPIO ports to indicate ready, processing and finished.

sleepychu 10y ago
> If you have a Raspberry Pi with a diode, wait until the blinking stops
deleted 10y ago
[deleted]

sathackr 10y ago

> In the worst case, only the CIRCLean would be compromised, but not the computer reading the target (trusted) USB key/stick. If the CIRClean device is compromised, I don't see how the trusted USB stick, which is connected to the now compromised CIRClean, can be guaranteed to not be infected.