[FOSDEM] CfP for FOSDEM 2017 security devroom

[Siarhei Siniak]

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_Antoniewicz.pdf

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