NOTE : The first few minutes may be random ; so please wait atleast for 5 minutes(may be lesser)before getting a steady stream; And please dont allow any network activity than these scans

here is how i did :

192.168.2.134 was used to do scans on 192.168.2.155; the scan parameter was "hping -r -V 192.168.2.155"(IDLE SCAN window). I obtained the open tcp 139 on the zombie 192.168.2.155 from an nmap scan done earlier.

192.168.2.149 was used to do a icmp scan on 192.168.2.155; "ping -n 99999 192.168.2.155"; this was occassional noice i needed for the test(hit cntl ^C when you have enough noice).

192.168.2.155 was the victim;the idle terminal; There were no visible network communication(all applications were closed to make it a strict non-noice environment).

this whole network was interconnected by a switch.

configurations: although i did it on a variety of configurations having windows 2k, winxp with sp2 ; I have unfortunately due to lack to time, I only documented this particular intance ;(.

192.168.2.155 was a winxp sp2 with latest updates.(zombied host)

192.168.2.134 was a ubuntu breezy.(attacker's machine)

192.168.2.149 was a win2k.(target host)

wait the first few minutes till the noise get cleared.

now you get a stable clear stream/channel!!.

now i introduce a little "noise" to observe the communication pattern

here you can see the noise "reflected" in the idle scan

here you can observe the "noise" ending as i pressed ctl^C at the 192.168.2.149!!!

Patch discussion :

"http://kernel.org/git/?p=linux/kernel/git/torvalds/

linux-2.6.git;a=commitdiff_plain;h=1a55d57b107c3e06935763905dc0fb235214569d;

hp=6a534ee35cfd02f60e99d301b9ac446ea11a9cfd"

This is an article i wrote and got published in www.hackthissite.org. Its about the notorious IDLE/DUMB scan.

from "http://www.hackthissite.org/articles/read/439"

hy people,

i read lost of articles, bugtraq, full disclosure, ISN.. well i have been new to hackthissite. I just wanted to inform you people that one of my all time favourite vulnerability..is back with a vengeance!!I think many of you might have already discovered it, for those who havent here is the brief:

Idle scan is a technique of a successful(very much) spoofed port scanning. It works because of a vulnerability in the implementation of the ipid field of the tcp packets. This infamous vulnerability was present in all the major OS'es of its time!. Lets see what it was in its originality:

when ever ip packets were sent, the ipid field would be incremented by a "constant" value. This acted like a signal to the attacker, about whether any packet transfer(communication) was taking place b/w the "idle"(this network device "usually" only communicates to the attacker, so it is idle w.r.t other devices on the network(say a server in an office at midnight(odd hours), only used for remote logins!!). this could be exploited, if i spoofed a tcp SYN communication using hping to a remote victim(the system i am pen-testing), the remote victim will send replies(SYN/ACK or RST) to the spoofed id(idle device). By just monitoring the ipid field of the idle device, i could tell if the communication from the victim to the idle device was a RST or a SYN/ACK(RST will mean that idle device will have no change in ipid,coz no communication will take place; if SYN/ACK then ipid will change as there will be communication b/w idle device and victim)... and if the answer is RST, we know that th port is closed and if it is SYN/ACK the port is open! ofcourse if it is filtered it wont work.. but atleast its untraceable.. as long as the idle device is "really" "dumb".. hence it is called IDLE/DUMB scan.

Now coming back, as we know, since linux kernel-2.4.8 the ipid has been made 0, so that this vuln is nullified and BSD made it a random number(since windows==freebsd, its also random ). But

it happens that this ipid0 was not cleanely implemented!..

root@debian:~# hping -SA -c 1 xx.yy.zz -p 80

HPING xx.yy.zz (eth0 a.b.c.d): SA set, 40 headers +

0 data bytes

len=46 ip=a.b.c.d ttl=59 DF id=48842 sport=80 flags=R seq=0 win=0

rtt=57.4 ms

try the SA flag, ICMP, UDP

by the way, there is a patch but not sure how many systems out there have it done(;))!!

########################################

Thanx to all the bugtraq guys for pointing this out

"

Marco Ivaldi

to bugtraq

More options Mar 14

Hello Bugtraq,

I've recently stumbled upon an interesting behaviour of some Linux kernels

that may be exploited by a remote attacker to abuse the ID field of IP

packets, effectively bypassing the zero IP ID in DF packets countermeasure

implemented since 2.4.8 (IIRC)........"

"