Bugtraq mailing list archives
Re: Denial of service attack against tcpdump
From: dr () DURSEC COM (Dragos Ruiu)
Date: Wed, 3 May 2000 13:28:25 -0700
On Tue, 02 May 2000, bretonh () PARANOIA PGCI CA wrote:
There is a way to disable tcpdump running on a remote host. By sending a carefully crafted UDP packet on the network which tcpdump monitors, it is possible, under certain circonstances, to make tcpdump fall into an infinite loop. tcpdump interprets UDP packet from or to port 53 as DNS traffic. Consequently, tcpdump attempts to retreive information (such as domain names in this case) in DNS queries and replies and display it. However, domain names in DNS packets use a compression scheme to avoid multiple occurences of a domain name in the same packet. This scheme uses jumps to a particular offset in the packet. If this jump offset is set to its own location and if a program trying to decompress the domain name does not have any type of counter or strategy to avoid infinite loops, then the program will jump to the same offset in the packet over and over again.
This all points to another reason to always run tcpdump with "tcpdump -n" err... quiet mode as you called it. Another serious drawback to allowing tcpdump (or any sniffer as a matter of fact) to look up DNS addresses is that it allows evil haxors to immediately identify the security machines/probes on the network by either passive monitoring and detection of the lookups or by penetrating the name daemons (or the DNS server that hosts it) and looking at the logs. DNS logs can be fascinating sources of info.... This information will immediately highlight what should be the evil haxor's next most important target. :-) There are some sniff type programs (ntop and iptraf from memory) that implement a separate thread/proc to do the DNS lookups and cache some of the results. This can be a way to mitigate the security machine DNS "beaconing" to a degree, but they are still vulnerable to the following sniffer detection algorithm: 1. Inject packet to strangedest.net 2. Look for any machine doing a DNS lookup to strangedest.net This is particulalry useful if you already control strangedest.net. The moral of the story is that where tcpdump is concerned "-n" is a very nice option. cheers, --dr -- dursec.com / kyx.net - we're from the future http://www.dursec.com learn kanga-foo from security experts: CanSecWest - May 10-12 Vancouver Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD Lance Spitzner/Sun, Fyodor Yarochkin/KALUG, Max Vision/whitehats.com
Current thread:
- Re: pam_console bug, (continued)
- Re: pam_console bug Benjamin Smee (May 03)
- Re: pam_console bug Michal Zalewski (May 04)
- Re: pam_console bug Benjamin Smee (May 03)
- Re: Wemilo daedalus (May 02)
- Possible issue with Cisco on-line help? Fernando Montenegro (May 02)
- Re: Possible issue with Cisco on-line help? Fernando Montenegro (May 04)
- Re: Possible issue with Cisco on-line help? Lisa Napier (May 09)
- Re: Possible issue with Cisco on-line help? Fernando Montenegro (May 04)
- 4ward:It's a blue world! deepquest () NETSCAPE NET (May 02)
- Denial of service attack against tcpdump bretonh () PARANOIA PGCI CA (May 02)
- Re: Denial of service attack against tcpdump antirez (May 03)
- Re: Denial of service attack against tcpdump Sebastian (May 03)
- Re: Denial of service attack against tcpdump Dragos Ruiu (May 03)
- Re: Denial of service attack against tcpdump Gerald Combs (May 03)
- "ILOVEYOU" virus analysis Steve Wolfe (May 04)
- 2.2.14 Kernel exec/open bug (?) The Cr0W (May 05)
- Re: Denial of service attack against tcpdump Hugo.van.der.Kooij () CAIW NL (May 09)
- glibc resolver weakness antirez (May 02)
- Re: glibc resolver weakness Bennett Todd (May 03)
- Re: glibc resolver weakness Valdis.Kletnieks () VT EDU (May 03)
- Re: glibc resolver weakness Andrew Brown (May 03)
- Cayman 3220-H DSL Router DOS cassius () HUSHMAIL COM (May 05)
- Fun with UltraBoard V1.6X rudi carell (May 03)
(Thread continues...)