I was recently on a wireless testing gig where I was faced with a relatively typical scenario: a corporate wireless network leveraging PEAP with MSCHAPv2 for authentication, and wireless clients that were configured to not check for a valid certificate when communicating with the RADIUS server.
My standard approach to this on Backtrack follows the one Robert Portvliet describes in his post Capturing and cracking a PEAP challenge/response with FreeRADIUS-WPE (go read it):
- Use hostapd to create a fake access point with the same SSID as the network we are targeting
- Use FreeRADIUS-WPE to act as a fake RADIUS server for our fake access point
- Get some clients to connect to you, and let FreeRADIUS-WPE perform its magic
- Grab the challenges and responses from the log file, and use asleap to brute force the users' passwords
Unfortunately, asleap didn’t like the challenge and responses I was feeding it, returning:
Could not recover last 2 bytes of hash from the
challenge/response. Sorry it didn't work out.
This is quite annoying, and seems to happen with certain WPA supplicants in certain situations. One of these situations seems to be when you have Windows clients authenticating against an Active Directory backed RADIUS server. That’s a pretty common situation.
The reason for this (from what I can understand) appears to be due to how the MSCHAPv2 protocol works, and how some supplicants don’t entirely follow the rules. A great write-up of the protocol components was written by Moxie Marlinspike a while back: Divide and Conquer: Cracking MS-CHAPv2 with a 100% success rate.
For our purposes, we only care about how the client sends the username to the RADIUS server: a Windows supplicant that thinks it’s authenticating against Active Directory will send its username as DOMAIN\user, but it will compute its response to the server challenge based on just the username. FreeRADIUS-WPE by default doesn’t know this, and will assume that DOMAIN\ is part of the username. What we end up with is a challenge and a response that are computed using two different usernames.
So how do you get FreeRADIUS to handle this quirk with EAP clients? In /usr/local/etc/raddb/modules/mschap, add the following:
with_ntdomain_hack = yes
This activates extra code in FreeRADIUS-WPE that strips the domain name off the username before doing its challenge/response computation, providing values that asleap can use.