Live data from Hacker News

PoisonTap – Exploits locked computers over USB

github.com

11–20 of 57 posts

Re: PoisonTap – Exploits locked computers over USB

#13
Another fine exploit by Samy [1]. At the risk of sounding like a killjoy, once the attacker has physical access to a machine, let alone plugs in their own device, you can usually abandon all security hope [2]. But that entirely notwithstanding, the techniques presented in this exploit are actually quite clever, and they conspire to make for a nasty set of scenarios. Kudos to him for raising awareness once again!

[1] https://en.wikipedia.org/wiki/Samy_Kamkar [2] https://hn.algolia.com/?query=tptacek%20"physical%20access"&...

Re: PoisonTap – Exploits locked computers over USB

#15

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

Yes, suppose you have a mac mini and you plug in USB keyboard, oops it's sandboxed and does not work.

Re: PoisonTap – Exploits locked computers over USB

#16
post #7

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.

Or, don't automatically issue dhcp requests until the interface is explicitly configured to do so.

Re: PoisonTap – Exploits locked computers over USB

#17
post #7

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.

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.

Re: PoisonTap – Exploits locked computers over USB

#18
post #17
post #7

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.

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.

Re: PoisonTap – Exploits locked computers over USB

#19
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!

Re: PoisonTap – Exploits locked computers over USB

#20
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).

Post reply on HN