4 ms·
Good thing they weren't complacent and they had the drive checked. It's appalling that this came from a police department, but it could happen with any drive so
by joshuapants 12y ago
Good thing they weren't complacent and they had the drive checked. It's appalling that this came from a police department, but it could happen with any drive someone gives you, accidentally or maliciously.
What's the best way to counteract this? Only plug foreign drives into a dedicated computer, probably running Linux, so you can scan it and copy the files you need before letting them touch other machines?
- xai3luGi 12y agoLinux isn't necessarily immune to USB malware. There are a lot of drivers for USB devices in Linux and any of them could have a bug. For example people only recently started doing fuzzing on filesystem drivers.
- nkozyra 12y agoAbsolutely. You want something ephemeral - meaning software AND hardware you can nuke. And even that isn't 100%. What's demonstrated in this article is extremely inelegant and clumsy. Truly malicious rootkits and the like are a bit more sophisticated.
- analog31 12y agoNowadays I check any drive that's been out of my house, after my spouse brought a virus home from her workplace. A dedicated Linux box, a quick booting distro on a trusted flash drive, or even a Raspberry Pi can be used for this purpose.
- morganvachon 12y agoI would second the Raspberry Pi, it would be more or less immune to malware that targets x86 land, even Linux based malware. Still, I'd not have it connected to the network and I would wipe the Pi's SD card afterward, just to be sure. Scripts can run on any architecture. The Pi doesn't have a BIOS or EFI on board, it uses a special partition on the SD card to POST from, so there's no worry of the device itself being infected.
- matteotom 12y agoIn that case, you might be better off using a MIPS based device (old router, maybe?), since ARM is gaining popularity.
- kbenson 12y agoFrom what I've heard recently, targetting ARM may be problematic because two ARM processors may not support the same features, or function the same way. Then again, maybe there's a low-end subset of ARM instructions that should work an any chip, similar to the instruction set for the i386?
- wtracy 12y agoThe Arm specification primarily focuses on the protected mode opcodes used by applications. This is why Arm application binaries are portable across machines. The real mode opcodes needed to bring up a kernel are a mess on Arm, with each manufacture using their own instruction set.
- pjc50 12y agoThis explanation is garbled. The opcodes are not fundamentally different (although more are added from ARMv6 to ARMv7 e.g. the Pi 1 to Pi 2 transition), and there isn't the X86 different set of "real mode" opcodes. What is different is the boot sequence and system register layout. On a PC you can write one bootloader that works across multiple systems because either the peripherals are at the same place or BIOS/UEFI code is provided to sort it out for you. This is not the case on ARM; uboot and devicetree are attempts to fix it.
- justincormack 12y agoYou can feature detect at runtime. And or pick a subset. It is complicated but workable.
- nitrogen 12y agoThe Pi doesn't have a BIOS or EFI on board, it uses a special partition on the SD card to POST from, so there's no worry of the device itself being infected. It might be possible for a malicious script that gains root access to replace the SD card firmware with something that looks clean on the Pi, but delivers malware when some conditions are met.
- joshuapants 12y agoRaspberry Pi does make a lot of sense. It's cheap enough, small, and doesn't consume much power so it's easy to have one around for this purpose.
- analog31 12y agoSince I got a couple of RPi's for fun, I've been thinking of uses for them, that would augment the security of my regular Windows PCs. I've set up a file backup method, where the RPi "pulls" files from my PC via my home network, but does not grant the PC read or write access. This is all just garden variety Linux commands, mounting the Windows share, and copying files from it. I think that my method is immune to "ransom ware" attacks. To cloak itself, the ransom-ware has to decrypt files when they are fetched, until it decides to lock you out.
- userbinator 12y agoDisabling AutoPlay and any other "automatically run a program when media is inserted" feature would be a good first step. Not running executable files (Windows users: unhide those file extensions!) that have no reason to be executable, and using AV software (or multiple, like those online services) to scan the files you are interested in is also a good idea. If you're really paranoid, do everything with a separate machine.
- w-ll 12y agoPeople have put little nano atmel's in usb drive cases that have emulated a virtual keyboard. Sending ~a few strokes could open command, download, and run an executable.