PoisonTap – Exploits locked computers over USB(github.com)
github.com
PoisonTap – Exploits locked computers over USB
https://github.com/samyk/poisontap
56 comments
A powered-down machine with full disk encryption is reasonably safe against physical access, I still hope?
Unless USB keylogger is present which will log the disk encryption password when user is unaware of it...
I've already seen lockable boxes around computer ports on some older model workstations. Combine that with some tamper proofing on the keyboard, and you've probably bought yourself a little more security against any intruder who has limited time with physical access.
Not if you can get access twice. A variety of "evil maid" style attacks exist. For example, imagine I replace your FDE's bootloader with a version that appears identical, except it also logs your passphrase. Then I come back, read the passphrase, decrypt, and win.
For scarier thoughts, imagine I know how to control the Intel Management Engine, and attack that instead. That's not covered by FDE.
For scarier thoughts, imagine I know how to control the Intel Management Engine, and attack that instead. That's not covered by FDE.
You have a few mitigations that aren't listed here, but it's really moot because physical access is still game over.
First, the GRSecurity patchset contains a kernel-level USB whitelist, so you can whitelist only known USB devices. A targeted attacker could attempt to spoof an existing/whitelisted USB device, but it does significantly harden the USB attack surface:
1. https://wiki.gentoo.org/wiki/Allow_only_known_usb_devices
Clearly this only helps Linux people. For those using Linux/BSD/macOS, There's also usbkill, a Python-based antiforensic tool that just kills the computer if a device is inserted/removed that isn't on its whitelist: https://github.com/hephaest0s/usbkill
While this won't stop Samy's box from starting to do its thing, it will at least shut the computer off and mitigate some of the potential damage. usbkill is in the Homebrew repositories for macOS as well. If you have fully encrypted disks and strong passphrases, this is still going to ruin somebody's day trying to use this device.
First, the GRSecurity patchset contains a kernel-level USB whitelist, so you can whitelist only known USB devices. A targeted attacker could attempt to spoof an existing/whitelisted USB device, but it does significantly harden the USB attack surface:
1. https://wiki.gentoo.org/wiki/Allow_only_known_usb_devices
Clearly this only helps Linux people. For those using Linux/BSD/macOS, There's also usbkill, a Python-based antiforensic tool that just kills the computer if a device is inserted/removed that isn't on its whitelist: https://github.com/hephaest0s/usbkill
While this won't stop Samy's box from starting to do its thing, it will at least shut the computer off and mitigate some of the potential damage. usbkill is in the Homebrew repositories for macOS as well. If you have fully encrypted disks and strong passphrases, this is still going to ruin somebody's day trying to use this device.
> First, the GRSecurity patchset contains a kernel-level USB whitelist, so you can whitelist only known USB devices. A targeted attacker could attempt to spoof an existing/whitelisted USB device, but it does significantly harden the USB attack surface:
Actually, the GRSecurity patchset includes a toggle to disable all new usb devices after boot. The whitelist mechanism you're referring to relies only on udev (no kernel patching needed). You can even whitelist by driver to, e.g., allow all usb storage devices by default.
Actually, the GRSecurity patchset includes a toggle to disable all new usb devices after boot. The whitelist mechanism you're referring to relies only on udev (no kernel patching needed). You can even whitelist by driver to, e.g., allow all usb storage devices by default.
For completeness, if you happen to use Qubes, you can configure a VM specifically for talking to USB devices that would prevent this from affecting the rest of the system.
I think that USB is not the issue here, because you could simply do the same with a Raspberry Pi 1-3 and the Ethernet port.
That dhcp is running and assigning addresses while the computer is locked, it the issue IMO.
That dhcp is running and assigning addresses while the computer is locked, it the issue IMO.
The takeaway for me is that you can program a Raspberry Pi Zero to be a USB device (not just host). I wonder if it can do both at the same time...
I sometimes think about building a "USB Condom". There already exist devices that only pass through the power lines, if you want to charge a phone from a dubious plug. However, I would go a step further and try to support data. For example, I would emulate a USB pen drive (with a FAT32 file system), and then mirror the contents of an attached drive. If the attached drive is malicious, it cannot easily attack the host.
I sometimes think about building a "USB Condom". There already exist devices that only pass through the power lines, if you want to charge a phone from a dubious plug. However, I would go a step further and try to support data. For example, I would emulate a USB pen drive (with a FAT32 file system), and then mirror the contents of an attached drive. If the attached drive is malicious, it cannot easily attack the host.
You wish to build your own USB condom because you want to be absolutely, 100% sure it's built without any kind of backdoor and you don't trust anyone else to do this for you?
Because otherwise you can just get one at e.g. http://int3.cc/products/usbcondoms
I have had one for years (a no-name one, not the one I linked)
Because otherwise you can just get one at e.g. http://int3.cc/products/usbcondoms
I have had one for years (a no-name one, not the one I linked)
No, the one you linked to is just charge-only.
I wish to build - or I wish someone would build - a USB condom that passes through USB stick drives, by reading files on one side, and emulating a filesystem on the other.
It's not because I want to be 100% there is no backdoor. Rather I want a minimum of safety when I have to access a USB stick given to me by a stranger.
(Speaking of building your own, simple power-only USB condoms - like you linked to - are actually pretty easy to make. They have been used to teach (SMD) soldering at CCC events, hackerspaces and the like.)
I wish to build - or I wish someone would build - a USB condom that passes through USB stick drives, by reading files on one side, and emulating a filesystem on the other.
It's not because I want to be 100% there is no backdoor. Rather I want a minimum of safety when I have to access a USB stick given to me by a stranger.
(Speaking of building your own, simple power-only USB condoms - like you linked to - are actually pretty easy to make. They have been used to teach (SMD) soldering at CCC events, hackerspaces and the like.)
Hm, this sounds like a software-based solution right? But if you have software only letting certain data pass, couldn't the same software just be run by the main device instead of an intermediate one?
Two reasons speak for a separate hardware for that purpose:
1: conventional computers have no mechanism to indicate what you expect from a USB device, and you can't ask for confirmation that the user wanted to plug in a keyboard, because the user might need that keyboard to confirm hits intention
2: the USB software stack can be attacked at many layers, including firmware, generic OS code and the OS-chosen driver. That software stack varies depending on OS, motherboard, BIOS version, installed drivers etc. A hardware device can provide protection invariant from those factors
1: conventional computers have no mechanism to indicate what you expect from a USB device, and you can't ask for confirmation that the user wanted to plug in a keyboard, because the user might need that keyboard to confirm hits intention
2: the USB software stack can be attacked at many layers, including firmware, generic OS code and the OS-chosen driver. That software stack varies depending on OS, motherboard, BIOS version, installed drivers etc. A hardware device can provide protection invariant from those factors
Just what wongarsu said.
I don't know from the top of my head about USB, but for FireWire there was a hack that allowed a malicious device to access all memory (read-write). Basically, a new device is placed on the DMA bus (for speed reasons) with no authentication and can do whatever it wants. There is a proof of concept that unlocks OS X, Windows, and a popular Linux desktop.
There was a USB bug where you could infect some USB controllers with mal-firmware that would spread like a worm! I believe the NSA was actively using this, but I might be mixing things up.
With a condom, a malicious device would have to take over two pieces of hardware, not just one. This is one advantage of a hardware solution.
The other advantage is, if there is an exploit in the USB filter software, the malware lands in my condom (hihi). It would likely have to be adapted to work on it and to move to my PC (the condom is ARM, has no network besides USB, can have a read-only file system, ...).
I don't know from the top of my head about USB, but for FireWire there was a hack that allowed a malicious device to access all memory (read-write). Basically, a new device is placed on the DMA bus (for speed reasons) with no authentication and can do whatever it wants. There is a proof of concept that unlocks OS X, Windows, and a popular Linux desktop.
There was a USB bug where you could infect some USB controllers with mal-firmware that would spread like a worm! I believe the NSA was actively using this, but I might be mixing things up.
With a condom, a malicious device would have to take over two pieces of hardware, not just one. This is one advantage of a hardware solution.
The other advantage is, if there is an exploit in the USB filter software, the malware lands in my condom (hihi). It would likely have to be adapted to work on it and to move to my PC (the condom is ARM, has no network besides USB, can have a read-only file system, ...).
I agree
I wonder if a viable method for securing USB devices would be a pairing step, similar to how bluetooth keyboards work. Most input devices are USB-based, which means we can't require confirmation for every device, but we could require OS confirmation for most of them, and do a pairing step for input devices. Like click these visual targets / type in this key sequence.
This wouldn't fully solve this problem, but it might just help protect me from people plugging devices into my machine while it's locked, and could even alert me that the device I thought was just charging has reported itself as a keyboard, despite looking nothing like one.
This wouldn't fully solve this problem, but it might just help protect me from people plugging devices into my machine while it's locked, and could even alert me that the device I thought was just charging has reported itself as a keyboard, despite looking nothing like one.
It seems like another mitigation missing from their list is "modify your DHCP client to reject over-broad subnet masks" where the cutoff is probably something like /20.
Additionally you could reject any DHCP lease for a subnet that purports to overlap with the address range of any other directly connected network.
Additionally you could reject any DHCP lease for a subnet that purports to overlap with the address range of any other directly connected network.
I almost immunized my Win10 _by accident_ thanks to paranoia about blocking W10 spying.
>netsh advfirewall firewall show rule name=all
…
Rule Name: Core Networking – Dynamic Host Configuration Protocol (DHCP-In)
———————————————————————-
Enabled: Yes
Direction: In
Profiles: Domain,Private,Public
Grouping: Core Networking
LocalIP: Any
RemoteIP: LocalSubnet
Protocol: UDP
LocalPort: 68
RemotePort: 67
Edge traversal: No
Action: Allow
Rule Name: Core Networking – Dynamic Host Configuration Protocol (DHCP-Out)
———————————————————————-
Enabled: Yes
Direction: Out
Profiles: Domain,Private,Public
Grouping: Core Networking
LocalIP: Any
RemoteIP: LocalSubnet
Protocol: UDP
LocalPort: 68
RemotePort: 67
Edge traversal: No
Action: Allow
Couldn't the USB device identify itself as multiple devices over the same port? Similar to a hub. It could then give a /20 to each device.
It could, there's a limit of 127 USB devices though so it couldn't cover a large percentage of the address space that way. It might be enough to still cover some major sites of interest.
Or, don't automatically issue dhcp requests until the interface is explicitly configured to do so.
I don't have a Pi to test with but I imagine keeping the associated kernel module(s) (assuming I have the right ones) unloaded would mitigate this entirely:
kextunload /System/Library/Extensions/AppleUSBEthernet.kext
and maybe this one. I don't know if this would impact using your phone as a usb hotspot but it might so keep that in mind:
kextunload /System/Library/Extensions/AppleUSBNetworking.kext
and this one but I'm pretty sure it is in fact required for usb tethering so keep that in mind if you use that:
kextunload /System/Library/Extensions/AppleUSBEthernetHost.kext
I don't remember if they reload on reboot or not but if needed you can reload them with kextload.
Edit: This is for OS X/macOS by the way. And I wish I had a Pi to test with because this is very cool. We owe people that release stuff like this a big thanks because they took it from an idea to implementation and then the big step of creating a usable, shareable project which goes a long way toward increasing awareness.
kextunload /System/Library/Extensions/AppleUSBEthernet.kext
and maybe this one. I don't know if this would impact using your phone as a usb hotspot but it might so keep that in mind:
kextunload /System/Library/Extensions/AppleUSBNetworking.kext
and this one but I'm pretty sure it is in fact required for usb tethering so keep that in mind if you use that:
kextunload /System/Library/Extensions/AppleUSBEthernetHost.kext
I don't remember if they reload on reboot or not but if needed you can reload them with kextload.
Edit: This is for OS X/macOS by the way. And I wish I had a Pi to test with because this is very cool. We owe people that release stuff like this a big thanks because they took it from an idea to implementation and then the big step of creating a usable, shareable project which goes a long way toward increasing awareness.
It's long past time that USB security is taken seriously.
By default anything stuck into a USB port should be sandboxed and various integrity checks need to be performed before access is allowed.
By default anything stuck into a USB port should be sandboxed and various integrity checks need to be performed before access is allowed.
You can't blame the USB ports entirely... I mean, yes, it's insane he can force requests that trick your machine into dumping unencrypted cookies, but remember this intercepts and modifies unencrypted traffic, which any packet sniffer or upstream provider (router, ISP, et al) can already see/modify.
So even if you follow Samy's recommendation of putting cement on your USB ports, [0] you're still vulnerable to injection and interception.
Moral of the story: encrypt all the things.
[0]: https://github.com/samyk/poisontap#desktop-security
So even if you follow Samy's recommendation of putting cement on your USB ports, [0] you're still vulnerable to injection and interception.
Moral of the story: encrypt all the things.
[0]: https://github.com/samyk/poisontap#desktop-security
> It's long past time that USB security is taken seriously.
You mean, before we started using USB for charging...?
It wouldn't be hard at all to make a convincing looking power adapter with something like PoisonTap baked in.
You mean, before we started using USB for charging...?
It wouldn't be hard at all to make a convincing looking power adapter with something like PoisonTap baked in.
You can protect both devices from each other with a USB condom [1] which only connects the power pins. This should be the solution for trying to charge from untrusted slots, or for when an untrusted device wants to charge from you.
[1] http://syncstop.com/#faq-original
[1] http://syncstop.com/#faq-original
Know of any USB condoms that can filter for device types? Given BAD USB type of exploits there really no easy way for me to know that when I stuck my USB stick in the printer at the library it wasn't reprogrammed to be a keyboard or something else and when I then go plug it into my computer it now powns my computer
> By default anything stuck into a USB port should be sandboxed
Yes, suppose you have a mac mini and you plug in USB keyboard, oops it's sandboxed and does not work.
Yes, suppose you have a mac mini and you plug in USB keyboard, oops it's sandboxed and does not work.
I think the idea is that if a second "keyboard" is plugged in while the machine is locked/asleep, it shouldn't work. Even for the scenario where you dump $BEVERAGE into your keyboard, forcing a hard reboot to be able to plug in another keyboard (and log back in) doesn't seem unreasonable.
I remember the "good ol' days" when you could reasonably build a monolithic Linux kernel with support for loadable modules disabled. Just compile in whatever you needed for your hardware and leave out the other 90% that you didn't need.
It was a decent (but not very popular) defense against rootkits and attackers being able to dynamically load kernel modules and would also prevent something like this (unless you had the necessary drivers compiled in).
It was a decent (but not very popular) defense against rootkits and attackers being able to dynamically load kernel modules and would also prevent something like this (unless you had the necessary drivers compiled in).
What's stopping you from doing it now?
I've been using CONFIG_MODULES=n for years without issue. It can be annoying when you need to use some obscure driver, filesystem or protocol on a one off basis and have to do an emergency recompile just for that, but that's rare (for me at least), and otherwise it's perfectly usable.
I've been using CONFIG_MODULES=n for years without issue. It can be annoying when you need to use some obscure driver, filesystem or protocol on a one off basis and have to do an emergency recompile just for that, but that's rare (for me at least), and otherwise it's perfectly usable.
This could be done: we need a common git repo with a config for each kernel version per laptop; eg. config-4.4.30 for ThinkPad X200, which only includes the required drivers for the laptop itself.
That sounds great but I remember installing Linux on a Mac and even then it wasn't consistent exactly which drivers should have been used as there were variations depending on the date of purchase. Macs are probably a lot more consistent than the majority of laptops.
That is impressive. And scary.
But if your box's physical security has been compromised, you're already screwed in any case.
But if your box's physical security has been compromised, you're already screwed in any case.
> But if your box's physical security has been compromised, you're already screwed in any case.
There's a gradient to the screwage, however.
For example, I've encrypted my disk, so someone would need to steal my computer and then try bruteforcing it with some new-fangled graphics card.
With this insanity, I risk someone stealing my unencrypted traffic with a plug-and-play device any time I get up from my desk to pee. Then again, they can already do that with Wireshark.
There's a gradient to the screwage, however.
For example, I've encrypted my disk, so someone would need to steal my computer and then try bruteforcing it with some new-fangled graphics card.
With this insanity, I risk someone stealing my unencrypted traffic with a plug-and-play device any time I get up from my desk to pee. Then again, they can already do that with Wireshark.
not just unencrypted - traffic for any website that doesn't use HSTS. All they need to do is intercept a single HTTP page and then they can modify it to contain iframes to their favorite sites over http, and any site without HSTS can then be owned.
Hopefully though everyone sets the secure flag on important cookies... I wouldn't bet on it, but I suspect it may be more common than HSTS.
I can't help but feel in the majority of cases fleeting access should not be a problem for a modern operating system.
Lets say you are working in an office and get up to go the loo. You lock your work station. You are expecting that your locked computer will mean that a visitor cannot gain access to it in the few minutes you are away.
They could steal the computer, they could destroy it but slipping something into the port of a locked computer shouldn't give them this sort of access.
I feel that we can do better.
Lets say you are working in an office and get up to go the loo. You lock your work station. You are expecting that your locked computer will mean that a visitor cannot gain access to it in the few minutes you are away.
They could steal the computer, they could destroy it but slipping something into the port of a locked computer shouldn't give them this sort of access.
I feel that we can do better.
Absolutely. This can be better. But it can't be much better.
I wonder if this could be combined with some of the (relatively) recent issues w/ LastPass and/or 1Password, where the application and password credentials were accessible via 127.0.0.1 (which is apparently required for the browser extensions to work)?
If so -- assuming the user is logged in to {1Password|LastPass} -- just plug this in to their PC after they walked away from their desk and wait for all of their saved credentials to be stolen!
If so -- assuming the user is logged in to {1Password|LastPass} -- just plug this in to their PC after they walked away from their desk and wait for all of their saved credentials to be stolen!
This attack can be mitigated in Windows using group policy:
https://technet.microsoft.com/en-us/library/cc731387(WS.10)....
A hardware-oriented attack vector that completely unravels the carefully conceived schemes of the application layer's software-oriented security that sits on top of it.
And USB at the heart of it. My old friend, USB.
Why am I not surprised?
And USB at the heart of it. My old friend, USB.
Why am I not surprised?
Previously:
"PoisonTap, a $5 tool that invades password-protected computers"
https://news.ycombinator.com/item?id=12966673
"PoisonTap, a $5 tool that invades password-protected computers"
https://news.ycombinator.com/item?id=12966673
Almost everything said on that page is already feasible with basic network spoofing. Sure, the hardware hack is cool and allows a bit more but nothing extraordinary.
So is clearing your browser cache sufficient to be sure that any possible PoisonTap infection has been removed?
sounds like it, but given usb plug-n-play I'm sure you could make a more persistent version.
And also clearing your cache won't invalidate all your web sessions that they could have stolen. You'll want to find every site you were logged into, and explicitly log out. Otherwise those stolen cookies will still be valid, unless the website does some sort of channel-id thing to bind cookies to the particular computer (which I'm not sure is possible beyond experimental browser features, and certainly is not common practice)
And also clearing your cache won't invalidate all your web sessions that they could have stolen. You'll want to find every site you were logged into, and explicitly log out. Otherwise those stolen cookies will still be valid, unless the website does some sort of channel-id thing to bind cookies to the particular computer (which I'm not sure is possible beyond experimental browser features, and certainly is not common practice)
It's not often you see exploits that reference RuPaul's Drag Race. I, for one, am all for it.
Does using SRI (https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) defeat a portion of this attack?
A small portion. (It’s listed in the mitigations.) Use HTTPS anyway, though.
so thinking about the attack: would it be feasible for OSes to only allow USB input devices to be attached while the computer is locked? It seems like it should be unnecessary to install usb network devices while the computer is locked.
FileVault plus running 'pmset destroyfvkeyonstandby' in Terminal should prevent this.
Destroying the FileVault key should encrypt the disk, likely stopping things from running while asleep. I haven't tested this though.
On OS X when I plug in a new USB based Ethernet device, the first thing it does is pop up a dialog asking me if I want to enable/configure the device... is the device already configured at that time?
Does it ask for a password to enable it? If not the device and also emulate a keyboard to press enter to confirm the dialog.
Any idea where is the list of approved devices is. I'd like to clear my list and then plugin some devices and see if it asks.
Any idea where is the list of approved devices is. I'd like to clear my list and then plugin some devices and see if it asks.
I run as a non-administrator account, so this may be different if the user has administrator privileges.
But here is what happens:
1. I plug in the new device
2. Dialog box pops up letting me know a new network interface was detected (and to open network preferences to configure the device). The device does show up as en6, it is disabled and there is no network activity.
3. I can click Cancel or open Network Preferences
4. Click to open Network Preferences
5. I have to click the lock, and authenticate as an administrative user
6. I have to click the +
7. I have to select the new network interface by name from the drop-down
8. I have to click OK
9. I have to click Apply
At that point the network interface is brought "up", and it does a DHCP request, and I can use it.
So there are 8 steps to take AFTER plugging in the device before it can start siphoning off any and all of my data. It's not as plug and go as it is made out to be.
----
After adding a device, you can remove it from the list of devices in Network Preferences, and that resets that dialog box letting you know there is a new device.
But here is what happens:
1. I plug in the new device
2. Dialog box pops up letting me know a new network interface was detected (and to open network preferences to configure the device). The device does show up as en6, it is disabled and there is no network activity.
3. I can click Cancel or open Network Preferences
4. Click to open Network Preferences
5. I have to click the lock, and authenticate as an administrative user
6. I have to click the +
7. I have to select the new network interface by name from the drop-down
8. I have to click OK
9. I have to click Apply
At that point the network interface is brought "up", and it does a DHCP request, and I can use it.
So there are 8 steps to take AFTER plugging in the device before it can start siphoning off any and all of my data. It's not as plug and go as it is made out to be.
----
After adding a device, you can remove it from the list of devices in Network Preferences, and that resets that dialog box letting you know there is a new device.
shouldn't the OS pause the running of programs when you've locked your computer, and when you log in say something like "hey you've plugged a new device in while you were locked out, are you sure you want to resume all you programs"
[1] https://en.wikipedia.org/wiki/Samy_Kamkar [2] https://hn.algolia.com/?query=tptacek%20"physical%20access"&...