31–40 of 57 posts
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…
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 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…
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…
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?
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
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. 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.…
So is clearing your browser cache sufficient to be sure that any possible PoisonTap infection has been removed?
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)
Earlier quoted context omitted.
> 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.…
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.
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…
That dhcp is running and assigning addresses while the computer is locked, it the issue IMO.
That is impressive. And scary. But if your box's physical security has been compromised, you're already screwed in any case.
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.