Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PoisonTap – Exploits locked computers over USB

github.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: PoisonTap – Exploits locked computers over USB

#41

Post by nine_k »

niftich wrote: post #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]…

A powered-down machine with full disk encryption is reasonably safe against physical access, I still hope?

Re: PoisonTap – Exploits locked computers over USB

#43

Post by rasz_pl »

caf wrote: 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.

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
Basically I only allow DHCP from LocalSubnet. Of course according to Microsoft LocalSubnet : “The keyword localsubnet, which includes all addresses that are on the local computer’s current subnet.” but how the hell does your computer know “local computer’s current subnet” BEFORE it receives its IP from DHCP server??? Hmm, I think Ill just hardcode this to private subnet (192.168.0.0/16).

Re: PoisonTap – Exploits locked computers over USB

#45

Post by pulse7 »

nine_k wrote: post #41
niftich wrote: post #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]…

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...

Re: PoisonTap – Exploits locked computers over USB

#46

Post by qwertyuiop924 »

SilkRoadie wrote: post #40
qwertyuiop924 wrote: post #4

That is impressive. And scary. But if your box's physical security has been compromised, you're already screwed in any case.

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 th…

Absolutely. This can be better. But it can't be much better.

Re: PoisonTap – Exploits locked computers over USB

#47

Post by goda90 »

pulse7 wrote: post #45
nine_k wrote: post #41

Earlier quoted context omitted.

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.

Re: PoisonTap – Exploits locked computers over USB

#48

Post by arantius »

nine_k wrote: post #41
niftich wrote: post #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]…

A powered-down machine with full disk encryption is reasonably safe against physical access, I still hope?

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.

Re: PoisonTap – Exploits locked computers over USB

#50

Post by collyw »

pmlnr wrote: post #32
jlgaddis wrote: post #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…

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.
Post reply on HN