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

Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

github.com

Post reply on HN
Print view View original

111–120 of 140 posts

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#111

Post by cpach »

TheAceOfHearts wrote: post #80
throwasehasdwi wrote: post #15

I'm not sure why this is amazing enough to make the first page but W/E it's HN :). Just so less informed are aware, this has been feasible for maybe 7 years (since GPU calculation became possible). Just so nobody freaks out, this is cracking weak passwords, not broken WPA. I have myself cracked countless WiFi passwords when security testing. It's easy if the passwords are bad, which is maybe 90% of the time for home…

In your opinion, is setting up a RADIUS server and using WPA2-Enterprise worth it for a consumer? I'm pretty paranoid, and also think it could be an insightful experience to tinker around with networking tools. Any advice for what constitutes a strong or weak password in this context?

~15 random characters (printable ASCII of course) should be enough for a WPA2 password.

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#112

Post by icebraining »

poizan42 wrote: post #89
djsumdog wrote: post #81

Earlier quoted context omitted.

Most captive portal routers don't block DNS (because they use iptables rules to handle authentication). That's why you can use iodine to proxy TCP-over-DNS on such APs. So if you just had an open access point, unless you provided no DNS servers except over VPN, people would still be able to use your AP.

Presumably you want to reply to DNS requests for a hostname for your captive portal. You might try to just use a raw ip address, but then you can't use https. So then you have the problem that you can't just reply with a fake answer for other domains due to caching. E.g. Windows caches negative responses for 5 minutes, which would be a pretty bad experience for your customers. I guess you might be able to just fail t…

You just reply to any DNS request with your own server's IP, which accepts any HTTP requests with a redirection to the captive portal. The replies can have low TTLs to avoid the caching problem.

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#113

Post by icebraining »

sasebot wrote: post #108
amenghra wrote: post #106

Earlier quoted context omitted.

The difference between an access point and HTTPS on a web server is that the access point doesn't have an identity to tie the key exchange. You can sprinkle DH here and there to incrementally improve things but it's not going to be bullet proof against active man-in-the-middle attacks. With things like Lets Encrypt, having each access point own a short lived certificate becomes possible and you can then bootstrap a s…

>>>The difference between an access point and HTTPS on a web server is that the access point doesn't have an identity to tie the key exchange. You can sprinkle DH here and there to incrementally improve things but it's not going to be bullet proof against active man-in-the-middle attacks. ??? Isnt the MAC address an identity for the AP ? I always had a doubt about HTTPS . Say Im connecting through a proxy server to a…

??? Isnt the MAC address an identity for the AP ?

No, just an address. To be an identity, there must be some way for the AP to demonstrate that it is the right owner of that MAC, otherwise any router can simply copy the MAC.

HTTPS sites do this by getting a CA to vouch for them (in the form of a digitally signed certificate). Tor sites do this by having their address being a representation of their public key, and proving they have the corresponding private key.

I always had a doubt about HTTPS . Say Im connecting through a proxy server to a website. The exchange of keys for HTTPS connection happens through this proxy server, means it can capture those and decrypt the connection whenever it wants , right ? Thanks for your reply.

No, thanks to Diffie-Hellman[1], you can exchange keys with a remote server over a non-secure channel in a way that anyone listening can't figure out the key.

Of course, this happens after the server has proven it is who it says it is, by using one of the methods above. Otherwise, the proxy could pretend to be the server, and exchange keys itself with you.

[1] https://security.stackexchange.com/questions/45963/diffie-he...

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#114

Post by kees99 »

djsumdog wrote: post #81
kees99 wrote: post #71

Earlier quoted context omitted.

WEP, WPA, WPA2... why keep reinventing the same wheel? Each new iteration inevitable turns out to be less-than-perfect and keep adding more and more complexity and overhead - for one, join/leave times keep increasing, up to a point where we have a separate standard (802.11r) just to get back pre-WPA roaming speeds (at cost of even more protocol complexity overhead). Here's crazy idea: Why not run open network + IPSEC…

Most captive portal routers don't block DNS (because they use iptables rules to handle authentication). That's why you can use iodine to proxy TCP-over-DNS on such APs. So if you just had an open access point, unless you provided no DNS servers except over VPN, people would still be able to use your AP.

Newer captive portals (FON with latest firmware for example) are blocking iodine by being clever about which request to answer (bunch of A and AAAA with some of responses being CNAMEs, which are quickly followed by resolution of just received answers to A/AAAA), and which to block (bunch of NULL queries or "dangling" CNAMEs that are not followed by A/AAAA).

That being said - that's a bit over the top. The only reason I wouldn't want my AP to be open and unfiltered is - I don't want any junk being sent out which is attributable to me (by IP), and which I have no control over. Iodine, being a tunnel will only transport to "guest"'s server and go into the wider Internet with their server's IP.

If somebody is in enough of a squezze to jump over that sort of hoops, and there're no costs/risks for me - let them have it. I'm fine with that.

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#115

Post by icebraining »

shpx wrote: post #98
freeflight wrote: post #94

Earlier quoted context omitted.

For completeness sake, this is probably the comic you are referencing: https://xkcd.com/936/

curl -s https://raw.githubusercontent.com/first20hours/google-10000-english/master/google-10000-english-no-swears.txt | shuf | head -n 4 | tr '\n' ' '; echo mine wear vacation mostly log2(10^16) = 53 bits of entropy or 300 years if your attacker can do a million guesses per second (the link says 1000 keys per second, but that's on the CPU). You could also use `cat /usr/share/dict/words` instead of the `curl`, which i…

Careful, shuf is not cryptographically safe by default! You need to pass --random-source=/dev/urandom to get a proper RNG.

https://www.gnu.org/software/coreutils/manual/html_node/Rand...

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#116

Post by kees99 »

hunter2_ wrote: post #91
poizan42 wrote: post #89

Earlier quoted context omitted.

Presumably you want to reply to DNS requests for a hostname for your captive portal. You might try to just use a raw ip address, but then you can't use https. So then you have the problem that you can't just reply with a fake answer for other domains due to caching. E.g. Windows caches negative responses for 5 minutes, which would be a pretty bad experience for your customers. I guess you might be able to just fail t…

Aside from custom root certs being installed, https is out either way, not only with IP address, right? HSTS makes that even more of a problem, and pinning makes even the custom root cert a problem. Captive portals seem like an increasingly fragile idea, except that OSes increasingly intervene appropriately.

State-of-art for captive portal handling is:

Step 1) For mobile device to make a request to a special URL that is known to respond with short 200/204, something like that:

  http://clients1.google.com/generate_204
  http://captive.apple.com/hotspot-detect.html
  http://www.msftconnecttest.com/connecttest.txt
...and bring up UI (sandboxed browser) if anything else than expected short 2xx was received.

Step 2) Mobile device reuse same cookies for the same portal second time around, so portal can recognize returning user and let them in without annoying with login prompt each time.

Assuming mobile device has a separate cookie jar for this, and captive portal is HTTPS with proper certificate, and doesn't try to break other people's SSL, that is pretty secure. Sure, this is not the most efficient protocol, but up-side is - it's open-ended. You can fit here anything from "press here if you agree to behave" to complete walled garden like hotspot on a train that shows you interactive map, schedule and transport connections available on the next stop along with small banner asking $1 for full internet access.

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#117

Post by shpx »

icebraining wrote: post #115
shpx wrote: post #98

Earlier quoted context omitted.

curl -s https://raw.githubusercontent.com/first20hours/google-10000-english/master/google-10000-english-no-swears.txt | shuf | head -n 4 | tr '\n' ' '; echo mine wear vacation mostly log2(10^16) = 53 bits of entropy or 300 years if your attacker can do a million guesses per second (the link says 1000 keys per second, but that's on the CPU). You could also use `cat /usr/share/dict/words` instead of the `curl`, which i…

Careful, shuf is not cryptographically safe by default! You need to pass --random-source=/dev/urandom to get a proper RNG. https://www.gnu.org/software/coreutils/manual/html_node/Rand...

Why does shuf implement its own random number generator? Why isn't /dev/urandom the default?

https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#118

Post by icebraining »

shpx wrote: post #117
icebraining wrote: post #115

Earlier quoted context omitted.

Careful, shuf is not cryptographically safe by default! You need to pass --random-source=/dev/urandom to get a proper RNG. https://www.gnu.org/software/coreutils/manual/html_node/Rand...

Why does shuf implement its own random number generator? Why isn't /dev/urandom the default? https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...

shuf is not a crypto tool, and the GNU coreutils are written to be cross-platform, even where /dev/urandom doesn't exist, or is unreliable. That's my guess, at least.

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#119

Post by poizan42 »

icebraining wrote: post #112
poizan42 wrote: post #89

Earlier quoted context omitted.

Presumably you want to reply to DNS requests for a hostname for your captive portal. You might try to just use a raw ip address, but then you can't use https. So then you have the problem that you can't just reply with a fake answer for other domains due to caching. E.g. Windows caches negative responses for 5 minutes, which would be a pretty bad experience for your customers. I guess you might be able to just fail t…

You just reply to any DNS request with your own server's IP, which accepts any HTTP requests with a redirection to the captive portal. The replies can have low TTLs to avoid the caching problem.

The common web browsers caches DNS responses irrespective of their TTL values, which may be for as long as 30 minutes[0].

[0]: http://www.zytrax.com/books/dns/info/minimum-ttl.html

Re: Crack WPA/WPA2 Wi-Fi Routers with Aircrack-Ng and Hashcat

#120

Post by c3833174 »

nictrix wrote: post #105

The DSL provider in my area sets up customer's wireless networks with their home or mobile phone number as the password. If you know that number or can look it up in public records then you're in. If you can't find it maybe use a dictionary pertaining to the area code of phone numbers and then you're in. When the protocol changes to something more secure, the ISP's customer will still be as insecure as they always we…

That's not as bad as deriving password and SSID (Provider-$generated_number) from the MAC address, it didn't take much for somebody to reverse the algorithm from the bootloader and make various programs to calculate the few possible password from SSID
Post reply on HN