5

A very similar question was asked here but it didn't get any reply, so I'm going to ask a new question with some more insights.

The problem of the most common Evil Twin Attack is that the fake AP is unsecured and I've noticed that even with a deauth attack to the actual AP, the client won't connect automatically to the fake AP because of the different 802.1x configuration. The only way would be that the client connects of his own will.

I'm using hostapd to create the fake AP. So, how could I accept the request of authentication even if the passphrase of the client does not match the one set in the configuration file of the fake AP (hostapd.conf)?

Because the PSK generated from the fake AP would be different from the one generated by the client.

Improve this question
3
  • 1
    Why exactly you want to "accept" the authentication request? I you wan't it to completely connect to you like a MITM attack, you're also going to need a RADIUS server too.
    – Azteca
    Commented Mar 8, 2017 at 22:06
  • Because I don't know the passphrase used from the client.
    – loopOfNegligence
    Commented Mar 9, 2017 at 15:24
  • Then again you need to edit or create another question because you didn't say anything about the 802.1x encapsulation configuration, by passphrase you mean EAP-PSK? Because some don't even use a passphrase, you can use a certificate installed by the IT dept. on your device, or if you're inside a domain, the user/pass you're logged in with it's enough, no need to input anything. Enterprise configuration it's way different.
    – Azteca
    Commented Mar 9, 2017 at 17:50

2 Answers 2

Reset to default
3

I've already answered on how to clone AP (merge with the original on a wireless network list) in here I think.

If you're evil twin is an Open Network (waiting for the user to mistakenly selecting it manually from the network list), you would have to keep sending deauth frames until the reconnection time times-out.

If you want to automatically accept the request of authentication (which will be passed to the RADIUS-AAA server) from the client you need to have exactly the same settings on the AP.

  • Higher signal strength (There is a parameter that says which AP is better to connect "roaming aggressiveness")
  • Same ESSID (The name of the network the probe requests look for or the beacon the AP emits)
  • Encryption algorithm (WPA2, judging by the tag on your question)
  • The Cipher (CCMP)

Which roughly translates to this on the hostapd.conf (These are SOME parameters)

auth_server_addr=192.168.0.1         // RADIUS SERVER (Enterprise / 802.1x)
auth_server_port=1234                // RADIUS SERVER (Enterprise / 802.1x)
auth_server_shared_secret=verySecret // RADIUS SERVER (Enterprise / 802.1x)
wpa_key_mgmt=WPA-EAP                 // RADIUS SERVER (Enterprise / 802.1x)
ieee8021x=1                          // RADIUS SERVER (Enterprise / 802.1x)
wpa=2                                // Encryption Algorithm (WPA2)
wpa_pairwise=CCMP                    // Cipher (CCMP)
ssid=evilTwin                        // ESSID
rsn_preauth=1

Here's the link where I took this example from (for further knowledge too).

Now, this obviously will fail at some point because you need the RADIUS server, you're talking about 802.1x, so you also need to configure the eapol-config file (If you're using freeRADIUS) which changes everything when you choose one of the 22 supported EAP methods (EAP-PEAP, EAP-TTLS, EAP-TLS, EAP-MD5, EAP-FAST, etc.)

Because the PSK generated from the fake AP would be different from the one generated by the client.

The key used for data encryption is called PMK, and it's dervived from the TLS Masster Secret in EAP-TLS, here you can find some more infor specifically for EAP-TLS

I hope this answers your question because it's still missing what you want to achieve and everything about the RADIUS server.

Improve this answer
5
  • Exactly, but even with the same configuration, you need to know the passphrase. Same with WPA Personal. My request was basically "if the fake AP it's identical to the actual AP, but different passphrase, how can I still authenticate the client with a wrong passphrase? An user that deleted his message suggested that I would need to change the "puzzle" (probably he meant the MIC?). He understood what I meant, but even If I would be able to make my fake AP accept whatever response, how can I achieve to make the client to accept any response?
    – loopOfNegligence
    Commented Mar 9, 2017 at 15:38
  • @loopOfNegligence Again, it depends on the EAP configuration, for example, EAP-MD5 it's only one way authentication, so you can accept the user auth, and tell him everything is OK. He will try to authenticate and send you the MD5 hash with the user/password, and obviously you will deny him, because you don't have that user/pass, but you have captured the hash, which you can crack for user/password of that connection try. See? No passphrase at all in this configuration. Idk what puzzle Mr. E was talking about.
    – Azteca
    Commented Mar 9, 2017 at 19:00
  • If you have the right configuration and you don't have the auth (passphrase/user-pass/certificate) you can't authenticate him, it doesn't make sense at all, there's no way it can happen. Yes you can accept the user response, but he will not accept yours without the right auth. It's a basic security measure, it's the essence of the all EAP configurations, no auth, no connection. You can still fool him, but only to get the right auth (key, hash user-pass, whatever) AND THEN you may want to reconfigure to do the full evil-twin MITM attack.
    – Azteca
    Commented Mar 9, 2017 at 19:03
  • Exactly, so there is no way to make the client accepts whatever response receives from the fake AP. Yeah, but even if you capture the hash user-password there is no certainty that the dictionary attack would work and anyway would take too much time.
    – loopOfNegligence
    Commented Mar 10, 2017 at 17:39
  • @loopOfNegligence That's right, in most of the EAP configurations of Enterprise Wi-Fi. Well, MD5 Hash is long way dead, so in this special case you can brute force it and you will get the user/pass.
    – Azteca
    Commented Mar 10, 2017 at 21:53
0

The problem of the most common Evil Twin Attack is that the fake AP is unsecured and I've noticed that even with a deauth attack to the actual AP, the client won't connect automatically to the fake AP because of the different 802.1x configuration. The only way would be that the client connects of his own will.

So, how could I accept the request of authentication even if the passphrase of the client does not match the one set in the configuration file of the fake AP (hostapd.conf)?

The Evil Twin attack requires that you match the settings on the attacked network as closely as possible. So if the network you are attacking is using 802.1X authentication, you must use 802.1X authentication on your fake AP.

From there, you need to configure your fake AP as the NAS client to send authentication requests to a RADIUS server of your control. On your RADIUS server you would create a configuration that would return a RADIUS ACCEPT to any authentication attempt (the capability to do this and the actual implementation vary depending on the RADIUS server). It doesn't matter if you have the user's actual credentials because you aren't going to actually process the authentication but blindly accept it (this means you would be accepting false or incorrect credentials as well).

The trick would be faking the real network's authentication server's name and certificate. Depending on the configuration of the client, if you don't match both of those the client device will either not authenticate at all or will prompt the user for confirmation before authenticating.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .