Breaking the Secure Safe

The final barriers you might need to bypass to associate with the wireless network are 802.1x-based authentication and higher layer VPNs. Attacking 802.1x and VPNs requires prior knowledge of the involved protocol's structure and operation. We strongly suggest reading Chapters 10 and 13 to learn more about 802.1x/EAP and Chapter 14 to review common VPN protocols before trying to understand the attacks we describe here.

Crashing the Doors: Authentication Systems Attacks

If the 802.1x implementation protecting the attacked network is using EAP-TLS, EAP-TTLS, or EAP-PEAP (reviewed in the Defense part of the book), the cracker might be out of luck and have to resort to DoS, social engineering, or wired side attacks against the certificate server or authority. There are theoretical investigations into possible man-in-the-middle attacks against tunneled authentication protocols—see "The Compound Authentication Binding Problem" IETF draft at http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-02.txt. Only time will tell if practical implementations of such attacks will come into existence. In a few cases, EAP-TTLS might be set to use older authentication methods such as MS-CHAP. These methods are vulnerable to an attack should the attacker manage to insert himself or herself into the tunnel.

An improved dictionary attack or plain old brute-force approach can be taken against Cisco EAP-LEAP because it employs user passwords, not host certificates. The EAP-LEAP dictionary attack improvement, first presented by Joshua Wright at Defcon 11, represents a formidable threat to WLANs that depend on LEAP security features. The main principle behind the attack is EAP-LEAP using MS-CHAPv2 in the clear to authenticate users. Thus, it inherits several MS-CHAPv2 flaws including plaintext user names transmission, weak challenge/response DES key selection, and an absence of salt in the stored NT hashes. Let us take a closer look at how the LEAP challenge/response operates. First, the authenticator (access point) sends a random 8-bit challenge to the supplicant (client host). The supplicant uses an MD4 hash of the authentication password to generate three different DES keys. Each of these keys is used to encrypt the challenge received and the ciphertext (3 x 64 = 192 bits in total) is sent back to the authenticator as a response. The authenticator checks the response and issues an authentication success or failure frame back to the supplicant, depending on the result.

Unfortunately, five nulls are consistent in every LEAP challenge/response exchange, making the third DES key weak. Because the challenge is known, calculating the remaining two DES keys takes less than a second. The trouble is that the third flawed DES key allows calculating the last two bits of the NT hash, leaving only 6 bytes to brute-force or run against a dictionary. That should not be difficult, because MD4 is fast, resource-economical, and insecure.

The attack against EAP-LEAP implemented by Joshua Wright in his Asleap-imp tool is as follows:

• Calculate a large list of MD4-hashed passwords.

• Capture EAP-LEAP challenge/response frames.

• Extract challenge, response, and username.

• Use the response to calculate the last two bits of the MD4 hash.

• Run the dictionary attack against the hash taking the two known last bits into account.

Another tool that uses the same attack against EAP-LEAP and was posted to the public domain is Leap. Check out the detailed description of leapcrack, leap, and Asleap-imp use in Chapter 6.

EAP-MD5, the original (and fallback) implementation of EAP, is vulnerable to man-in-the-middle attacks against the AP because there is no AP/server-to-host authentication. A rogue access point placed between the EAP-MD5 supplicant and the RADIUS server can easily snatch the user credentials sent to the authentication server and even authenticate users employing false credentials. To perform such an attack, the cracker might install RADIUS on the rogue AP host and direct user traffic to this illicit RADIUS server. An alternative path is to employ the HostAP hostapd daemon-supported minimal coallocated authentication server. This server requests the identity of the wireless client and will authorize any host capable of sending a valid EAP Response frame. No keys are required and any client can authenticate. This is not the functionality you would like to employ in a real-world access point, but for a man-in-the-middle attack in the process of penetration testing it is really what the doctor ordered. To start hostapd with the authentication server capability, use the hostapd -xm wlan0 command. When the hostapd authentication server is enabled, clients not supporting 802.1x will not be able to send data frames through the rogue AP.

Finally, there is a whole spectrum of DoS attacks against various implementations of EAP:

• DoS attacks based on flooding with EAPOL-Start frames. A cracker can try to crash the access point by flooding it with EAPOL-Start frames. The way to avoid this attack is to allocate limited resources on receipt of an EAPOL-Start frame.

• DoS attacks based on cycling through the EAP Identifier space. A cracker can bring down the access point by consuming all EAP Identifier space (0–255). As the EAP Identifier is required to be unique within a single 802.1x port only, there is no reason for an AP to lock out further connections once the Identifier space has been exhausted. Nevertheless, some access points do just that.

• DoS attacks against clients based on sending premature EAP Success frames. The IEEE 802.1x standard enables a client to avoid bringing up its interface if the required mutual authentication is not completed. This allows a well-implemented supplicant to avoid being tricked by a rogue authenticator AP flooding with premature EAP Success frames.

• DoS attacks against clients based on spoofing EAP Failure frames. The EAP specification requires supplicant clients to be able to use alternative indications of successful or failed 802.1x authentication. Thus, a well-implemented supplicant should not be fooled by a cracker flooding the network with EAP Failure frames. A supplicant that receives EAP-Failure frames from a rogue authenticator outside of the legal 802.1x exchange should ignore the frames. Not all supplicant clients possess such capability. If the proper authenticator AP wishes to remove the supplicant client, it would follow the EAP failure by the deassociation frame. There is nothing to stop attackers from imitating such a situation. File2air is the current tool of choice to launch such attacks.

• DoS attacks using malformed EAP frames. An example of such an attack is a FreeRADIUS 0.8.1 crash caused by an EAP TLS packet with flags 'c0' and with no TLS message length or TLS message data. This attack was reported at http://www.mail-archive.com/freeradius-users@lists.cistron.nl/msg15451.html.

How about practical implementations of these attacks? Unfortunately, there is no Nemesis or Wnet-style custom frame-generation toolkit for 802.1x/EAP at the time of writing. As mentioned earlier, you can always try to create your EAP frames in binary and send them using File2air. Besides, QA Cafe has released a commercial EAP-testing Linux suite they call EAPOL (http://www.qacafe.com/eapol/). You can only run EAPOL using Cisco Aironet 350 cards. A demo version of the suite, which includes binaries for Red Hat and Debian distribution, is available for download from the QA Cafe Web site. Here is the description of all tests supplied by the demo version of EAPOL as stated at http://www.qacafe.com/eapol/test-summary-demo.htm#4:

Authenticator sends EAPOL packets to supplicant's unicast MAC address:

Description:

  step 1. Send EAPOL-Logoff to place controlled port in

  unauthorized state

  step 2. Send EAP-Start to initiate authentication

  step 2. Wait for EAPOL packet from Authenticator (up to txWhen

  seconds)

  step 3. Verify destination MAC address is supplicant's MAC

  address



  Reference: IEEE Std 802.1X-2001

  Section 7.8 EAPOL Addressing



  NOTE: The authenticator should be in the CONNECTING state after the EAPOL-Logoff

/EAPOL-Start packets are sent by the supplicant.

Basic case of authenticator-initiated authentication:

Description:

  step 1. Send EAPOL-Logoff to place controlled port in

  unauthorized state

  step 2. Initiate ICMP Ping on LAN port to Trusted host

  step 3. Continue ping attempts for 120 seconds

  step 4. Verify authentication occurs for the configured type

  step 5. Verify ICMP ping to Trusted host



  Reference: IEEE Std 802.1X-2001

  Section 8.4.2.1 Authenticator initiation

Basic case of supplicant-initiated authentication:

Description:

  step 1. Send EAPOL-Logoff to place controlled port in

  unauthorized state

  step 2. Send EAPOL-Start to initiate authentication process

  step 3. Verify authentication occurs for the configured type

  step 4. Verify ICMP ping to trusted host



  Reference: IEEE Std 802.1X-2001

  Section 8.4.2.2 Supplicant initiation

Authenticator sends EAP Failure after supplicant sends EAP-Logoff:

Description:

  step 1. Send EAPOL-Logoff to place controlled port in

  unauthorized state

  step 2. Wait up to 15 seconds for EAP Failure packet from

  Authenticator



    Reference: IEEE Std 802.1X-2001

    Section 8.5.4.4 Disconnected

Authenticator sends EAP Failure if identity is unknown:

Description:

  step 1. Configure the supplicant to use unknown identity

  step 2. Send EAP-Start

  step 3. Wait for EAP Identity request

  step 4. Respond with unknown identity

  step 5. Verify an EAP Failure is received



  Reference: IEEE Std 802.1X-2001

  Section 8.5.8.6 FAIL



  NOTE: This test uses the Identity 'badUserName' which must not

  be a valid user name on your Backend authentication server.

The test summary of the full EAPOL suite gives an idea of how many possible DoS attacks against the EAP do exist. The summary can be viewed at http://www.qacafe.com/eapol/test-summary.htm. The EAPOL setup for wireless 802.1x authentication testing needs a Linux machine with one Ethernet and wireless interface. One interface of the EAPOL-running host is the 802.1x supplicant interface connected to the authenticator device (access point). The second interface must be connected to the trusted part of the device (access point Ethernet port) or network that does not require 802.1x authentication (wired LAN into which the tested AP is plugged). EAPOL is a lab testing suite for wireless security software and protocol developers, beta testers, and security consultants, not a canned "script kiddie" DoS tool. However, because the information about attacks exists "in the wild," we expect that hacked-up Xsupplicant clients and HostAP-based authenticators implementing the attacks described are under development in the hacker community and will surface soon.

To summarize, the main problem of EAP frames is the same with the 802.11 management and control frames: lack of proper authentication and integrity protection (secure checksums).

Tapping the Tunnels: Attacks Against VPNs

Attacks on higher layer VPNs is hardly a wireless-specific topic that surely deserves a book of its own. Here we can only provide some directions for a security professional or enthusiast to follow in his or her future research into it. Point-to-Point Tunneling Protocol (PPTP) and various IPSec implementations are the most common VPN solutions encountered. PPTP took a heavy battering from the security community and multiple tools have built-in options to attack PPTP tunnels. Anger is one such tool:

arhontus:~# ./anger -- h



usage: anger [ -v ] [ -d device ] output1 [ output2 ]



Write sniffed challenge/responses to output1.

If output2 is given it will perform an active attack on

PPTP connections and write the password hashes to output2.



     -d    Device to open for sniffing.

     -v    Some diagnostics.

As the documentation packaged with the tool states, Anger is a PPTP sniffer and attack utility. It sniffs PPTP MS-CHAP challenge/response packets and outputs them in a format suitable for feeding to the infamous L0phtcrack password cracking program. Anger implements an active attack against the MS-CHAPv1 password change protocol. When the sniffer detects a PPTP client attempting to log in using MS-CHAPv1, it fakes a password change command from the server. If the deceived user follows the dialog to change his or her password, Anger logs the hashes of the current password as well as the hashes of the new password chosen. These hashes can be given to L0phtcrack to crack the password or be used with a hacked-up PPP client for use with the Linux PPTP client to log onto the network. There are other utilities implementing the PPTP password change attack besides Anger, such as deceit by Aleph One (http://packetstormsecurity.nl/new-exploits/deceit.c).

After the publication and exploitation of flaws in the MS-CHAP protocol, Microsoft released a new version of MS-CHAP. This new version is not vulnerable to the password change attack. It does not perform a challenge/response authentication based on the weak LM hashes, and possesses the capability of server authentication. Microsoft has added a number of new steps to the response-to-challenge generation and implemented SHA1 hashing. However, the sniffer can still precompute hashes, and L0phtcrack does not require any changes to handle MS-CHAPv2 cracking.

The latest versions of Anger support sniffing MS-CHAPv2 challenge/response packets. The outlines for MS-CHAPv2 have the LM hash set to all zeros, as it is not available. Unfortunately, it is not possible to use the command-line version of L0phtcrack to crack MS-CHAPv2 entries because it does not attempt to get the NT response via a dictionary attack, unless there is an LM response present. However, you can use the Windows GUI version of L0ptcrack to crack the MS-CHAPv2 entries. In such a case, you must disable the cracking of the LM hash and enable cracking of the NT hash in the L0ptcrack options panel because L0phtcrack will not recognize the all-zeros LM response field as invalid and will still try to crack it. Replacing this field with something else leads to a parsing error.

Ettercap possesses a whole collection of plug-ins written to sniff PPTP tunnels, decapsulate traffic, and get user log-in passwords:

H03_hydra1  1.1   -- PPTP: Gets the passwords

H04_hydra2  1.0   -- PPTP: Decapsulates connections

H05_hydra3  1.0   -- PPTP: Forces renegotiation

H06_hydra4  1.0   -- PPTP: Forces PAP authentication

H07_hydra5  1.0   -- PPTP: Tries to force cleartext

H08_hydra6  1.0   -- PPTP: Forces chapms from chapmsv2

If you use PPTP on your WLAN, you should know how disruptive these plug-ins can be if PPTP is the only or best defensive measure standing between the cracker and WLAN traffic. If your interest in PPTP security lies beyond trying a few of the underground attack tools available, recommended reading includes "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)" by Bruce Schneier and Dr. Mudge (http://www.counterpane.com/pptpv2-paper.html) and a follow-up to this paper published by Team Teso (http://www.team-teso.net/releases/chap.pdf).

The main prerequisite to attacking IPSec VPNs is understanding how IPSec works. Without such an understanding, the discussion here makes little sense. Skip to Chapter 14 to learn more about the workings of the IPSec protocol and you will see that actually there is no such thing as an attack against IPSec; there are only attacks against specific IPSec modes or implementations. IPSec implementations that have known security problems such as buffer overflows or man-in-the-middle attack susceptibilities include the following:

• Cisco VPN Client 3.5

• Cisco VPN Client 1.1

• SafeNet/IRE SoftPK and SoftRemote

• PGPFreeware 7.03 - PGPNet

• WAVEsec

To poke around the IPSec-protected LAN use IKEProber.pl by Anton T. Rager or Ike-scan by Roy Hills. IKEProber and Ike-scan are Internet Key Exchange (IKE) packet manglers written to discover and fingerprint IKE-running hosts. The command syntaxes of both tools is as follows:

arhontus:~# ./ike-scan -h

Usage: ike-scan [options] [hosts...]

Hosts are specified on the command line unless the --file option is specified.



Options:



--help or –h  Display this usage message and exit.



--file=<fn> or -f <fn>

     Read hostnames or addresses from the specified file instead of from the command line.

 One name or IP address per line.  Use "-" for standard input.



--sport=<p> or -s p     Set UDP source port to <p>, default=500, 0=random.

     Some IKE implementations require the client to use UDP   source port 500 and will not

 talk to other ports. Note that superuser privileges are normally required to use nonzero

 source ports below 1024.  Also only one process on a system may bind to a given source

 port at any one time.



--dport=<p> or -d p

     Set UDP destination port to <p>, default=500. UDP port 500 is the assigned port

 number for ISAKMP and this is the port used by most if not all IKE implementations.



--retry=<n> or -r n     Set total number of attempts per host to <n>, default=3.



--timeout=<n> or -t n

     Set initial per-host timeout to <n> ms, default=500. This timeout is for the first

 packet sent to each host. Subsequent timeouts are multiplied by the backoff factor which

 is set with backoff.



--interval=<n> or -i <n>

     Set minimum packet interval to <n> ms, default=75. This controls the outgoing

 bandwidth usage by limiting the rate at which packets can be sent.  The packet interval

 will be greater than or equal to this number and will be a multiple of the select wait

 specified with --selectwait.  Thus --interval=75 –selectwait=10 will result in a packet

 interval of 80 ms. The outgoing packets have a total size of 364 bytes (20 bytes IP hdr +

 8 bytes UDP hdr + 336 bytes data) when the default transform set is used, or bytes if a

 custom transform is specified.  Therefore for default transform set: 50 = 58240bps, 80 =

 36400bps and for custom transform: 15 = 59733bps, 30 = 35840bps.



--backoff=<b> or -b <b>   Set timeout backoff factor to <b>, default=1.50.

     The per-host timeout is multiplied by this factor after each timeout.  So, if the

 number of retrys is 3, the initial per-host timeout is 500 ms and the backoff factor is 1

.5, then the first timeout will be 500 ms, the second 750 ms and the third 1125 ms.



--selectwait=<n> or -w <n>

     Set select wait to <n> ms, default=10. This controls the timeout used in the select

(2) call. It defines the lower bound and granularity of the packet interval set with --

 interval. Smaller values allow more accurate and lower packet intervals; larger values

 reduce CPU usage.  You don't need to change this unless you want to reduce the packet

 interval close to or below the default select wait time.



--verbose or -v

     Display verbose progress messages. Use more than once for greater effect:

     1 - Show when hosts are removed from the list and when packets with invalid cookies

 are received.

     2 - Show each packet sent and received.

     3 - Display the host and backoff lists before scanning starts.



--lifetime=<s> or -l <s>

     Set IKE lifetime to <s> seconds, default=28800. RFC 2407 specifies 28800 as the

 default, but some implementations may require different values.



--auth=<n> or -m <n>

     Set auth. method to <n>, default=1 (preshared key). RFC defined values are 1 to 5. 

 See RFC 2409 Appendix A.



--version or -V

     Display program version and exit.



--vendor=<v> or -e <v>

     Set vendor id string to MD5 hash of <v>. Note: this is currently experimental.



--trans=<t> or -a <t>

     Use custom transform <t> instead of default set. <t> is specified as enc,hash,auth,group.

     e.g., 2,3,1,5.  See RFC 2409 Appendix A for details of which values to use.For

 example, --trans=2,3,1,5 specifies Enc=IDEA-CBC, Hash=Tiger, Auth=shared key, DH Group=5

     If this option is specified, then only the single custom transform is used rather

 than the default set of 8 transforms.  As a result, the IP packet size is 112 bytes rather

 than the default of 364.



--showbackoff[=<n>] or -o[<n>]

     Display the backoff fingerprint table. Display the backoff table to fingerprint the

 IKE implementation on the remote hosts. The optional argument specifies time to wait in

 seconds after receiving the last packet, default=60. If you are using the short form of

 the option (-o) then the value must immediately follow the option letter with no spaces, e

.g. -o25 not -o 25.



--fuzz=<n> or -u <n>     Set pattern matching fuzz to <n> ms, default=100.

     This sets the maximum acceptable difference between the observed backoff times and

 the reference times in the backoff patterns file.  Larger values allow for higher variance

 but also increase the risk of false positive identifications.



Report bugs or send suggestions to ike-scan@nta-monitor.com

See the ike-scan homepage at http://www.nta-monitor.com/ike-scan/



arhontus:~# perl IKEProber.pl

ikeprober.pl V1.13 -- 02/14/2002, updated 9/25/2002

By: Anton T. Rager - arager.com



Usage:

-s SA [encr:hash:auth:group]

-k x|auser value|user value [KE repeatedX

     times|ascii_supplied|hex_supplied]

-n x|auser value|user value [Nonce repeatedX

     times|ascii_supplied|hex_supplied]

-v x|auser value|user value [VendorID

     repeatedX|ascii_supplied|hex_supplied]

-i x|auser value|user|rawip value [ID

     repeatedX|ascii_supplied|hex_supplied|Hex_IPV4]

-h x|auser value|user value [Hash

     repeatedX|ascii_supplied|hex_supplied]

-spi xx [SPI in 1byte hex]

-r x [repeat previous payload x times]

-d ip_address [Create Init packet to dest host]

-eac [Nortel EAC transform - responder only]

-main [main mode packet instead of aggressive mode - logic

     will be added later for correct init/respond]

-sa_test 1|2|3|4 [1=86400sec life, 2=0xffffffff life, 3=192

     group attribs, 4=128 byte TLV attrib]

-rand randomize cookie

-transforms x [repeat SA transform x times]

Use these tools to discover vulnerable IPSec implementations on LAN, download appropriate exploit code, compile it, and give it a try.

WAVEsec mobile IPSec implementation is exploitable with kraker_jack from the AirJack suite:

arhontus:~# ./kracker_jack

Kracker Jack: Wireless 802.11(b) MITM proof of concept (with a bite).



Usage: ./kracker_jack -b <bssid> -v <victim mac> -C <channel number> [ -c <channel number> ]

V <victims ip address> -s <server mac>  -S <server ip address>

[ -i <interface name> ] [ -I <interface name> ] [ -e <essid> ]

n <netmask> -B <broadcast address>



-a:  number of disassociation frames to send (defaults to 7)

-t:  number of deauthentication frames to send (defaults to 0)

-b:..bssid, the mac address of the access point (e.g.,

     00:de:ad:be:ef:00)

-v:  victim mac address

-V:  victim's ip address

-s:  wavesec server mac address

-S:  wavesec server ip address

-B:  network broadcast address

-n:  netmask address

-c:  channel number (1-14) that the access point is on, defaults to current

-C:  channel number (1-14) that we're going to move them to

-i:  the name of the AirJack interface to use (defaults to aj0)

-I:  the name of the interface to use (defaults to eth1)

-e:  the essid of the AP

If you want to find more on how kracker_jack performs a man-in-the-middle attack against WAVEsec, check out Abaddon's Black Hat briefings presentation at http://802.11ninja.net/bh2002.ppt.

As a less specific attack against IKE, you can try IKECrack, which works against IKE phase 1 aggressive mode and MD5_HMACs only. IKECrack (ikecrack-snarf-1.00.pl on the site) is a Perl script that takes a pcap-format file as an input and attempts a real-time brute-force of the PSK.

Finally, a desperate attacker can resort to DoS attacks against IPSec, perhaps to force the system administrator to bring down the IPSec tunnel for a while to determine what went wrong. If there is mission-critical traffic on the wireless link, the attacker's hope is that it will be allowed to pass unprotected while the network administration is searching for the source of the IPSec tunnel failure. A cracker can try to stop ISAKMP for IPSec traffic with a H09_roper Ettercap plug-in (likely to work only against the aggressive IKE mode). Less specific attacks such as flooding UDP port 500 on IKE-running hosts can also be launched. There is a report (http//:www.securiteam.com/windowsntfocus/6N00G0A3FO.html) that continuous flooding of UDP 500 port on a Windows 2000 machine with large (more than 800 bytes) UDP packets can use all available CPU cycles and lock up the targeted machine.