0x22bb
/
hacktricks
mirror of https://github.com/carlospolop/hacktricks.git
1
2
Fork 0
Code Releases Activity

GitBook: [master] one page modified

This commit is contained in:
CPol 2020-08-17 11:09:21 +00:00 committed by gitbook-bot
parent c7c3007875
commit 30fe103b0e
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
1 changed files with 22 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
pentesting/pentesting-network/wifi-attacks/README.md
View File

@ -396,6 +396,28 @@ Inside the "**Response, Identity**" packet, the **username** of the client will
![](../../../.gitbook/assets/image%20%28120%29.png)
### Anonymous Identities
\(Info taken from [https://www.interlinknetworks.com/app\_notes/eap-peap.htm](https://www.interlinknetworks.com/app_notes/eap-peap.htm)\)
Both **EAP-PEAP and EAP-TTLS support identity hiding**. In a WiFi environment, the access point \(AP\) typically generates an EAP-Identity request as part of the association process. To preserve anonymity, the EAP client on the user’s system may respond with only enough information to allow the first hop RADIUS server to process the request, as shown in the following examples.
* _**EAP-Identity = anonymous**_
> In this example, all users will share the pseudo-user-name “anonymous”. The first hop RADIUS server is an EAP-PEAP or EAP-TTLS server which drives the server end of the PEAP or TTLS protocol. The inner \(protected\) authentication type will then be either handled locally or proxied to a remote \(home\) RADIUS server.
* _**EAP-Identity = anonymous@realm\_x**_
> In this example, users belonging to different realms hide their own identity but indicate which realm they belong to so that the first hop RADIUS server may proxy the EAP-PEAP or EAP-TTLS requests to RADIUS servers in their home realms which will act as the PEAP or TTLS server. The first hop server acts purely as a RADIUS relay node.
>
> Alternatively, the first hop server may act as the EAP-PEAP or EAP-TTLS server and either process the protected authentication method or proxy it to another server. This option may be used to configure different policies for different realms.
In EAP-PEAP, once the PEAP server and the PEAP client establish the TLS tunnel, the PEAP server generates an EAP-Identity request and transmits it down the TLS tunnel. The client responds to this second EAP-Identity request by sending an EAP-Identity response containing the user’s true identity down the encrypted tunnel. This prevents anyone eavesdropping on the 802.11 traffic from discovering the user’s true identity.
EAP-TTLS works slightly differently. With EAP-TTLS, the client typically authenticates via PAP or CHAP protected by the TLS tunnel. In this case, the client will include a User-Name attribute and either a Password or CHAP-Password attribute in the first TLS message sent after the tunnel is established.
With either protocol, the PEAP/TTLS server learns the user’s true identity once the TLS tunnel has been established. The true identity may be either in the form _**user@realm**_ or simply _**user**_. If the PEAP/TTLS server is also authenticating the _**user**_, it now knows the user’s identity and proceeds with the authentication method being protected by the TLS tunnel. Alternatively, the PEAP/TTLS server may forward a new RADIUS request to the user’s home RADIUS server. This new RADIUS request has the PEAP or TTLS protocol stripped out. If the protected authentication method is EAP, the inner EAP messages are transmitted to the home RADIUS server without the EAP-PEAP or EAP-TTLS wrapper. The User-Name attribute of the outgoing RADIUS message contains the user’s true identity – not the anonymous identity from the User-Name attribute of the incoming RADIUS request. If the protected authentication method is PAP or CHAP \(supported only by TTLS\), the User-Name and other authentication attributes recovered from the TLS payload are placed in the outgoing RADIUS message in place of the anonymous User-Name and TTLS EAP-Message attributes included in the incoming RADIUS request.
### EAP-Bruteforce \(password spray\)
If the client is expected to use a **username and password** \(notice that **EAP-TLS won't be valid** in this case\), then you could try to get a **list** a **usernames** \(see next part\) and **passwords** and try to **bruteforce** the access using [**air-hammer**](https://github.com/Wh1t3Rh1n0/air-hammer)**.**