33

How to find out that a NIC is in promiscuous mode on a LAN?

AviD
  • 72,138
  • 22
  • 136
  • 218
LanceBaynes
  • 6,149
  • 11
  • 60
  • 91
  • 1
    Probably a better candidate for superuser.com? – AviD May 07 '11 at 22:30
  • It's also worth looking at the network hardware. If you monitor for unexpected networking equipment and port activity then you should be able to see these devices appear. – Ormis May 18 '11 at 14:02
  • Also, does anyone know of a way to do this via wlan? I don't see how it would be possible unless the viewing device was forced to associate, possibly because of encryption. – Ormis May 18 '11 at 14:06
  • 2
    It is possible to create a "receive only" network cable, used by someone with their device in promiscuous mode it wouldn't be possible to detect. http://www.infosecwriters.com/hhworld/hh9/roc/node3.html – Stephen Paulger May 25 '11 at 11:22
  • 1
    Waybackmachine link, since the original seems to have been deleted: https://web.archive.org/web/20150415194325/http://www.infosecwriters.com/hhworld/hh9/roc/node3.html – domen Jun 03 '15 at 13:14

5 Answers5

34

DNS test - many packet sniffing tools perform IP address to name lookups to provide DNS names in place of IP addresses. To test this, you must place your network card into promiscuous mode and sends packets out onto the network aimed to bogus hosts. If any name lookups from the bogus hosts are seen, a sniffer might be in action on the host performing the lookups.

ARP Test - When in promiscuous mode the driver for the network card checks for the MAC address being that of the network card for unicast packets, but only checks the first octet of the MAC address against the value 0xff to determine if the packet is broadcast or not. Note that the address for a broadcast packet is ff:ff:ff:ff:ff:ff. To test for this flaw, if you send a packet with a MAC address of ff:00:00:00:00:00 and the correct destination IP address of the host. After receiving a packet, the Microsoft OS using the flawed driver will respond while in promiscuous mode. Probably it happens just with the default MS driver.

Ether Ping test - In older Linux kernels when a network card is placed in promiscuous mode every packet is passed on to the OS. Some Linux kernels looked only at the IP address in the packets to determine whether they should be processed or not. To test for this flaw, you have to send a packet with a bogus MAC address and a valid IP address. Vulnerable Linux kernels with their network cards in promiscuous mode only look at the valid IP address. To get a response, an ICMP echo request message is sent within the bogus packet leading to vulnerable hosts in promiscuous mode to respond.

Maybe there are more, the DNS test for me is the most reliable

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
VP.
  • 1,043
  • 1
  • 11
  • 12
26

@vp gave the theory, I will give some tools.

For use in Linux systems:

  • SniffDet: This one employs 4 different tests: ICMP test, ARP test; DNS test and also a LATENCY test (which VP01 didn't mention). The tool is recently updated and I recommend it.

Also:

  • nmap: There is an NSE script for nmap called sniffer-detect.nse which does just that.
  • nast: It detects other PC's in promiscuous mode by doing the ARP test.
  • ptool: Does ARP and ICMP test. Last commit was on 2009.

For Windows systems:

  • Cain & Abel can do a promiscuous scan using many types of ARP tests.
  • Promqry and PromqryUI Microsoft tools for this purpose too, but I'm not really sure how they work.

As for general detection techniques, there's also another one, called honeypot detect. Details about the latency test and the honeypot technique can be found in sniffdet's documentation.

Pablo A
  • 123
  • 5
john
  • 10,968
  • 1
  • 36
  • 43
15

You can't guarantee that you'll be able to detect it.

For example, you can easily make a read-only ethernet cable by looping the TX+ (pin 1) and TX- (pin 2) of the sniffing computer, then set TX+ (pin 1) to RX+ (pin 3 of the sniffer) and TX- (pin 2) to RX- (pin 6 of the sniffer). It will then be impossible for the sniffing computer to affect any data traffic on the network.

It may be possible to detect a voltage drop or RF emissions (along the lines of Van Eck phreaking), but I'm not aware of any COTS hardware that will detect it.

Jon Bringhurst
  • 263
  • 1
  • 6
  • 1
    Nice. And of course there are ways to modify the configuration or software on the snooping system to prevent it from sending any packets also. E.g. a simple iptables rule set should do it on Linux. – nealmcb May 18 '11 at 19:38
  • 1
    @nealmcv http://www.askapache.com/security/sniffing-on-ethernet-undetected.html – john May 19 '11 at 12:18
2

While it may not always be possible to identify if the local network is promiscuously sniffing the local network traffic -- it may be possible to crash most or all packet capture applications doing so.

Check out Samy's http://samy.pl/killmon.pl script for a starting point. Realize that most applications working in 2011 are vulnerable to at least a DoS crash attack, even if the crash isn't vulnerable as a memory access violation (or a read/write exception that leads to a buffer overflow).

atdre
  • 18,885
  • 6
  • 58
  • 107
2

I believe there is a tool that reliably detects this by looking at the difference in ping response times. The tool sends pings and at the same time send a large number of pings to the same IP address but with a different MAC addresses.

The tool works because cards in promiscuous mode will be returning all traffic to the CPU thus when there is a lot of packets hitting the CPU this will slow the response to genuine pings. A card in normal mode would be ignoring all packets with different MAC addresses so there would be no difference in the response time.

Someone insert the name of the tool

Stuart
  • 300
  • 1
  • 3