Step 2: Associate to WLAN and Detect Sniffers

If someone is sniffing around, it is likely to be an IDS sensor or network monitoring tool of some sort(Snort). The first thing a sensible Black Hat would do is discover the IDS hosts and try to avoid them or bring them down. In fact, it is likely that after discovering what looks like an IDS sensor, an intelligent cracker might deassociate and leave. When performing a penetration test on a client's network, you should agree on the possibility of attacks against the IDS system with the network manager beforehand. You can discover devices in promiscuous mode by using the Ettercap hunter plug-in or any other free utilities including Sentinel, Sniffdet, and APD. Using Ettercap or APD is the fastest method of quick LAN sniffer discovery:

arhontus:~# ./apd



APD v1.1b : ARP Promiscuous Node Detection.

Written by: Dr.Tek of Malloc() Security

./apd [options]

Options:

-s addr : Start address.

-e addr : End address.

-d dev  : network device.

Both Sentinel and Sniffdet are more complex and reliable sniffer detectors that can use several detection methods simultaneously:

arhontus:~# ./sentinel



            [ The Sentinel Project: Remote promiscuous detection ]

                    [ Subterrain Security Group (c) 2000 ]



Usage:

  ./sentinel [method] [-t <target ip>] [options]

Methods:

  [ -a ARP test ]

  [ -d DNS test ] (requires -f (non-existent host) option

  [ -i ICMP Ping Latency test  ]

  [ -e ICMP Etherping test ]



Options:

  [ -f <non-existent host> ]

  [ -v Show version and exit ]

  [ -n <number of packets/seconds> ]

  [ -I <device> ]

arhontus:~# ./sniffdet --help

sniffdet 0.8

A Remote Sniffer Detection Tool

Copyright (c) 2002

   Ademar de Souza Reis Jr. <myself@ademar.org>

   Milton Soares Filho <eu_mil@yahoo.com>

Usage: ./sniffdet [options] TARGET

  Where:

  TARGET is a canonical hostname or a dotted decimal IPv4 address



  -i  --iface=DEVICE     Use network DEVICE interface for tests

  -c  --configfile=FILE  Use FILE as configuration file

  -l  --log=FILE         Use FILE for tests log

  -f  --targetsfile=FILE Use FILE for tests target

      --pluginsdir=DIR   Search for plug-ins in DIR

  -p  --plugin=FILE      Use FILE plug-in

  -u  --uid=UID    Run program with UID (after dropping root)

  -g  --gid=GID    Run program with GID (after dropping root)



  -t  --test=[testname]  Perform specific test

      Where [testname] is a list composed by:

        dns         DNS test

        arp         ARP response test

        icmp        ICMP ping response test

        latency     ICMP ping latency test



  -s  --silent           Run in silent mode (no output, only call

                       plug-in with results)

  -v  --verbose        Run in verbose mode (extended output)

  -h, --help           Show this help screen and exit

      --version        Show version info and exit



Defaults:

    Interface: "eth0"

    Log file: "sniffdet.log"

    Config file: "/etc/sniffdet.conf"

    Plugins Directory: "/usr/local/lib/sniffdet/plugins"

    Plugin: "stdout.so"

As you can see, in our wireless case Sniffdet is preferable, because it uses four different methods of sniffer detection, as opposed to apd, which was one of the first utilities available. Additionally, sniffdet can supply an IP list file as a target option to check the whole LAN for promiscuous devices with ease.

You can also analyze the network traffic to check if the IDS sensor-to-master or centralized logging traffic is present. Once the monitoring hosts are found, they can be put out of (sniffing) action using the killmon utility from Dasb0den Labs:

arhontus:~# perl killmon.pl

usage: killmon.pl <host to kill sniffs> <host with open port 80 [that host can sniff]>

Of course you want to sniff packets yourself (it's more addictive than caffeine!). Open your host's port 80 using netcat (nc -l -n -v -p 80) to stay in business. Alternatively, it is possible to use the Ettercap leech plug-in to isolate the IDS host from the rest of the LAN, try to obtain an administrative access on the IDS host, or bring it down with a DoS attack (easy if the host is on the WLAN). Such attacks against IDS sensors are likely not to go unmentioned, and for a cracker it is all about risk–benefit analysis, time, and luck. Will there be enough time between triggering the IDS and any action taken by the system administrator? Will this time be sufficient to penetrate one of the hosts on the LAN and plant a backdoor or launch a successful attack against a host on the Internet or other connected network? Can it be done without touching and triggering the IDS? Think about these considerations when planning your defenses and deploying the IDS; it helps to deploy it properly.