This is misleading. When using WPA the client and access point perform mutual authentication. This means that if you don't know the password, you cannot set up a rogue access point that "copies the target access point's settings". Because you don't know the password! And if you'd use a random password, the client will refuse to connect to the rogue AP.
The tool is actually creating a second, unencrypted network. On Windows it will give you a warning that the configuration of the network has changed. On Android you'd have to manually reconnect to the unencrypted network. So their method doesn't automatically perform a man-in-the-middle attack. A decent setup will warn you about this. Sure, if a user ignores all OS warnings, connects to an unencrypted network anyway, and feels the need to type his password in random fields s/he never saw before, then this will work [3].
What would be more interesting is to jam the target network, using an actual jammer [1], and then perform a KARMA man-in-the-middle attack [2]. The idea is to listen for probe requests to unencrypted networks, and then clone that unencrypted network. In this case the user would automatically connect, making the attack more likely to succeed...
Or setup an exact replica of the targeted device's (WPA-protected) home AP, and then tunnel the raw encrypted 802.11 frames back to that AP over the Internet. Ta-da - your target now has absolutely seamless remote access to their own home Wi-Fi, with mutual authentication and end-to-end hardware accelerated AES encryption. :P
Only "drawback" (if you're of a malicious nature) is that you can't do any evil. The only thing you'll see is the raw encrypted Wi-Fi traffic, flowing straight through your "rogue AP" and into the Wi-Fi over IP tunnel. :)
Disclaimer: That's what http://anyfi.net does and I'm on the team that built it.
agree. However it is a crafty mix between a classic attack (the deauth-part) and social engineering (the password part).
The KARMA way is more elegant, however you still might have to crack the actuall pre-shared key. I'd put it in as another helpful tool that might ease your pentest approach, besides Reaver, maybe.
This was my thought, too - and those that do would recognize the fake control panel.
I think it's becoming more and more common for the PSK to come on a sticker from the all-in-one router/modem your ISP sends you. So, the user never sets a passphrase, never sees the control panel, and has the key ready to hand out by just looking at their "internet box." This attack is perfect for that.
If you bump into enough of these devices you'll learn that most use a limited keyspace for their encryption key. Case in point, the Motorola NVG510 used by AT&T Uverse HSI ADSL2+ (not to be confused with AT&T Uverse VDSL). They are all programmed with a SSID of ATT### and use a ten digit numerical PSK. As far as brute forcing them, it took my GeForce 550 three days to find the key of my test unit, and if I remember correctly five days to scan the entire keyspace. A newer and faster video card could have done it in hours.
If manufacturers stopped using fixed length keys for a particular product line and made use of the entire alphabet it would make this kind of exercise infeasible.
Using good passwords (i.e. alphanum, case sensitive, perhaps with some special characters) in end user deployment is a support nightmare. Imagine you are trying to tell such password to user over a phone on a support call. The 10 digit number sequence is unsafe but is easy to handle - people are used to phone numbers and account numbers.
A 10 digit number sequence has 33.2 bits of entropy. 3 diceware words has 38.7 bits of entropy. I don't think 10 numerical digits is easier to relay than 3 words. Although either would be far short of the ~90 considered fully secure, I think it's safe to say there are plenty of designs that would have been both safer and easier to use.
You do have a good point there. It could work for home/apartment building attacks.
I'm not sure how many people know about the WPS button most routers have now, but I've got several people using it. It's rather slick when it works (I've only had it fail on HP printers). Windows 8 actually tells them to press the button. I think Android could make this more blatant to spread adoption.
You select the network on your device and press the WPS button and a few seconds later it's synced. Never need the password again.
WPS makes stealing the WPA PSK as trivially easy as WEP. Basically, WPS protects the WPA key with a 7-digit PIN - cracking that PIN is enough to authenticate with the router and have it provide the encryption key.
It seems like this should be easy to defend against, but everything I've ever read about WPS says no one seems to be putting any such protections in place.
>WPS protects the WPA key with a 7-digit PIN - cracking that PIN is enough to authenticate with the router and have it provide the encryption key.
Not only that, but routers verify the first and second halves of the PIN separately. So instead of brute forcing in a keyspace of 10000000, you only need to find one number up to 10000, and a second number up to 1000. (The second half of the PIN is actually a 4-digit number as well, but the last digit is just a checksum digit.)
If it weren't for that issue, attacks would take months/years instead of minutes/hours.
Yes, Because it generates and unecrypted wifi with the same SSID as your access point. If you connect to that, it will server you the site and you enter your "password" wich is actually your WPA/WP2 Pre Shared Key.
If you want to be save against this special kind of attack, you could use a RADIUS-based authentification, where every user gets a certificate and Username/Password instead of one general shared key.
It is a little tricky, but if you are running a NAS from a vendor like synology or qnap you could use their RADIUS packages to set it up.
This looks really cool. However, when I first read the words "social engineering", I expected it to create another access point encrypted the same way, and get the code direct from the victim. This way seems less fool-proof.
Is my suggestion at all possible, or is the code transmitted while connecting useless unless you already have it? (Well it's not useless, as it can be brute-forced by aircrack-ng locally. I'm wondering if what's transmitted is like a hash of the passphrase, which isn't useful, or encrypted with a one time key sent by the access point, in which case my idea is much better.)
The code is never trasnmitted. The data is encrypted with the code and only the code on the other side can be used to decrypt it.
Most brute-force systems work by capturing packets to hard drive and then attempting to decrypt them offline. Or you can upload your captures to the cloud: https://www.cloudcracker.com/
What about setting up a WEP access point to impersonate the WPA one, then getting the password from that? Still seems more likely to work than what it's doing now.
You can attack WEP with active attack that defeats the encryption in a matter of seconds. The only thing you need to remember about WEP is just don't use it.
The key (nor a hash of the key) is sent over the air. It's a challenge. Since both sides should know the key they can challenge each other by saying things like "encrypt the word 'horse' using our secret key" ... then they can compare the result.
Your method sounds to me like a pretty standard PSK crack: deauth client, collect auth handshake, repeat until you have enough packets to crack the passphrase. But collecting enough packets to crack the PSK becomes more difficult as the number of clients disconnecting/reconnecting goes down and the complexity of the PSK goes up. If you're trying to connect to a home AP with a halfway-decent passphrase, it can take days (or weeks) to collect enough auth packets.
Man-in-the-middle, on the other hand, takes almost no time at all - just a gullible user with the passphrase. This method seems like it would be especially effective against most home APs, which is the same case that is less-than-ideal for the other method.
A bruteforce attack against the PSK handshake requires only a single handshake to be captured. There are no known techniques to speed up the attack if more handshakes are captured.
Man-in-the-middle attacks against WPA are not trivial at all. The client and access point perform mutual authentication. If you don't know the password, you can't put up an identical rogue access point. The passphrase is never explicitly included in the handshake, only in "protected" forms (in challenge/response messages).
Ah, you're right about only needing a single handshake. I don't make a habit of "security testing" wifi networks, but with WEP I seem to remember something about increasing the odds of your cracked key being correct based on the number of packets at your disposal. Anyway, I looked a little deeper and that's certainly not the case with WPA.
I didn't mean to imply that MitM is trivial, just that it's quicker than brute-force in many cases. And, I assumed the rogue AP was not doing true WPA encryption like the real AP, just enough to make it appear correct to get clients to connect so you can serve the fake control panel. If you need the passphrase to stand up the rogue AP, what is the point of this attack? You're not phishing for anything but the WPA key.
EDIT: just read your comment about how this actually works (that is, the "rogue" AP is just another unencrypted network.) That's actually really lame, and I withdraw my previous praise for this crack. ;)
I wondered why the deauth in step 1 works, it sure looks like that's one of the shortcomings in WPA and there is just no workaround - except going with WPA2.
It'll work against WPA2 as well, the link you provided is confusingly worded. There's currently no technical way of preventing deauth attacks as 802.11 management frames are always unencrypted / unsigned.
A bit off-topic - I have noticed that python is used way more on the hacker/security community than other scripting langs (Perl,Ruby), anyone know why?
From what I know, python is usually the first language that newbies get pointed to when they ask where to start. It's easy to read, understand, and has a ton of libraries.
Plus python is older, and I think gained more popularity than ruby (before rails came along).
They are about the same age, Python was more popular in the US/Europe prior to Rails catching on (which I guess contributes to it still being more used outside of web dev).
Isn't Python, in general, significantly more widely used than Perl and Ruby outside their narrow popularity domains (sysadmin for Perl, RoR web apps for Ruby)? Just a guess.
Neat idea, but why can't it spoof the Wifi authentication page/popup? Can't it dress up as a new device and try to connect to the wifi network, and then see what kinds of authentication page is returned by the router? Then just copy that.
Without the password, it can't quite MitM yet. It presumably makes sure that they user connects to it because it doesn't have WEP/WPA enabled, so the client OS automatically connects to the AP with the same name, but doesn't warn the user that WPA is no longer enabled. It can't spoof the WPA connection because it doesn't have the password yet.
The problem here is that most OSs (read: Windows) do warn the user that the encryption has changed. Android won't even recognize it as the same network, you have to remove the old one and then reconnect. So I'm not really sure about the feasibility of this attack.
Was that even the case a couple of years ago though? I seem to remember that this was a valid attack at least a couple of years ago. Maybe it was on OSX or iOS devices?
I don't see how this tests the security of a setup if it is relying on a user submitting the password themselves. There is no way to protect against your own or the stupidity of others.
I've never seen a password protected paid-wifi set up. Using arp and spoofing your Mac address is often enough to pretend you are an authenticated client to most of these systems.
When something calls itself a security tool it's usually assumed (if not explicitly stated) that it serves some purpose for assessing the security of something. Otherwise it is just a tool made for making attacks easier to perform, which is pretty frowned upon.
It's a proof-of-concept to illustrate that users will put their passwords anywhere they are asked to and click through any warnings that may appear on their screen.
It does not, but Kali is designed for pentesters, so it already contains a lot of dependencies. It's based on Debian, so with a little fiddling you should get it running on most other distributions.
You need, however, a wifi card capable of packet injection. Some of them need special drivers or patches, so it makes sense that the author uses a distribution for securtiy/pentesting.
The tool is actually creating a second, unencrypted network. On Windows it will give you a warning that the configuration of the network has changed. On Android you'd have to manually reconnect to the unencrypted network. So their method doesn't automatically perform a man-in-the-middle attack. A decent setup will warn you about this. Sure, if a user ignores all OS warnings, connects to an unencrypted network anyway, and feels the need to type his password in random fields s/he never saw before, then this will work [3].
What would be more interesting is to jam the target network, using an actual jammer [1], and then perform a KARMA man-in-the-middle attack [2]. The idea is to listen for probe requests to unencrypted networks, and then clone that unencrypted network. In this case the user would automatically connect, making the attack more likely to succeed...
[1] http://people.cs.kuleuven.be/~mathy.vanhoef/papers/acsac2014...
[2] http://www.theta44.org/karma/
[3] Perhaps I'm a bit cynical, but I suppose it might actually work some of the time... :(