Hello, Nikos! In few words: I demonstrate half-finished exploit of outdated MITM vulnerability in PEAPv0,v1: https://github.com/nartes/hostap-mitm-mschapv2-peapv1 - intermediate code; http://eprint.iacr.org/2002/163/ - vulnerability description. It is based on hostap code. To tell the whole story: There is MITM vulnerability in PEAPv0,v1 if cryptobinding is disabled. 1) The earliest mentioning belongs to the paper "Man-in-the-Middle in Tunneled Authentication Protocols", November 11, 2002, http://eprint.iacr.org/2002/163/ 2) The following draft describes mentioned protocol "draft-josefsson-pppext-eap-tls-eap-05.txt", September 2002, https://tools.ietf.org/pdf/draft-josefsson-pppext-eap-tls-eap-05.txt 3) The following draft desribes the latest version, i.e. PEAPv2 "draft-josefsson-pppext-eap-tls-eap-10.txt", 15 October 2004, https://tools.ietf.org/pdf/draft-josefsson-pppext-eap-tls-eap-10.txt 4) The key differences in respect to the vulnerability is the following: [2] (*10.txt, page10) As a result, where the NAS acts as a "passthrough" it does not have knowledge of the TLS master secret derived between the peer and the EAP server. In order to provide keying material for link-layer ciphersuites, the NAS obtains the master session key, which is derived from a one-way function of the TLS master secret as well as keying material provided by EAP methods protected within a TLS channel. This enables the NAS and EAP peer to subsequently derive transient session keys suitable for encrypting, authenticating and integrity protecting session data. However, the NAS cannot decrypt the PEAPv2 conversation or spoof session resumption, since this requires knowledge of the TLS master secret. [3] (*05.txt, page3) As a result, the NAS does not have knowledge of the TLS master secret derived between the EAP Peer and the backend authentication server, and cannot decrypt the PEAP conversation. In order to providing keying material for link-layer ciphersuites however, the NAS does obtain the master session keys, which are derived from the TLS master secret via a one-way function. In the [2], they added as well as keying material provided by EAP methods protected within a TLS channel. 5) The key idea is the absence of cryptobinding in [2] draft. And if the client doesn't verify cert of the server, then MITM behaviour allows to crack TLS, and proxy any internal Eap Authentication Protocol between the victim and the real server. It works only for those protocols who are unaware of being tunneled within TLS by PEAP. MSCHAPv2 is an example of such a one. 6) The following Presentation from Shmoocon2008 describes cracking of the TLS, then gathering password hashes, and their consequent bruteforcing with the help of asleap utility. http://www.willhackforsushi.com/presentations/PEAP_Shmoocon2008_Wright_Anton... But that's not the exact MITM with Proxying MSCHAPv2. It's just MITM and cracking collected passwords. 7.0) hostap implementation of PEAP protocol corresponds to [3] in many things. Particularly, if the cryptobinding is enabled, then the exploit doesn't work. The absence of server's cert verification doesn't help here. But still allows to obtain [1] behaviour. And to utilize the exploit we need the following casese: * Server: PEAPv1, Client: PEAPv1, Cryptobinding (on both sides): Any * Server: PEAPv0, Client: PEAPv1, or Server: PEAPv1, Client: PEAPv0, CryptobindingServer: NO_CRYPTOBINDING, CryptobindingClient: OPTIONAL or NO_CRYPTOBINDING The default config in hostap is: Server: PEAPv0, Client: PEAPv0 (but setting it to PEAPv1 will result in downgrading to the same PEAPv0, unless the client asks to force PEAPv1 with peapver=1) CryptobindingServer: OPTIONAL CryptobindingServer: CRYPTOBINDING The most interesting is that the server intiates cryptobinding. And having the client OPTIONAL value, doesn't raise any exception if the server has NO_CRYPTOBDING. 7.3) hostap project has the following option -DCONFIG_TESTING_OPTIONS which easily prints any incoming hashes as asleap command. That utility was used in Shmoocon2008 presentation [6]. I verified the option for MSCHAPv2 at least. 8) I decided to implement the exploit according to [1]. Here is the intermediate result: https://github.com/nartes/hostap-mitm-mschapv2-peapv1 I've implemented some kind of MITM protocol which is communicated between MITM Eap Peer and Eap Server. It carries all required information for proxying MSCHAPv2 packets between victim's Eap Peer and real Eap Server. To see what happens, run the follwing: $ git clone https://github.com/nartes/hostap-mitm-mschapv2-peapv1 $ cd hostap-mitm-mschapv2-peapv1/eap_example $ make eap_example $ ./eap_example | less Look for the 'MITM:' messages, they display actions of the attacker. To see default behaviour of eap_example: $ git checkout master $ make $ ./eap_example | less 9) I tried in [8] to do such patches, that are easily portable to hostapd and wpa_supplicant from eap_example. And keeping in mind that Linux and Android in particular are all using this software. There are many examples of real life server even now. And there are still those people who doesn't care for cert verification. Thus they are still under the risk. 10) I hope that commits' messages are informative. best regards, Siarhei Siniak