File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / hping2 / docs / SPOOFED_SCAN.txt
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Feb 21 22:11:37 2012 UTC (13 years, 1 month ago) by misho
Branches: hping2, MAIN
CVS tags: v2_0_0rc3p7, v2_0_0rc3p5, v2_0_0rc3p4, v2_0_0rc3p0, v2_0_0rc3, HEAD
hping2

    1: The following is the original posting to bugtraq
    2: about spoofed/indirect/idle scan method. See
    3: the HPING2-HOWTO for more informations.
    4: 
    5: antirez
    6: 
    7: ---
    8: 
    9:   Hi,
   10: 
   11:         I have uncovered a new tcp port scan method.
   12:         Instead all others it allows you to scan using spoofed
   13:         packets, so scanned hosts can't see your real address.
   14:         In order to perform this i use three well known tcp/ip
   15:         implementation peculiarities of most OS:
   16: 
   17:           (1) * hosts reply SYN|ACK to SYN if tcp target port is open,
   18:             reply RST|ACK if tcp target port is closed.
   19: 
   20:           (2) * You can know the number of packets that hosts are sending
   21:             using id ip header field. See my previous posting 'about the ip
   22:             header' in this ml.
   23: 
   24:           (3) * hosts reply RST to SYN|ACK, reply nothing to RST.
   25: 
   26: 
   27:         The Players:
   28: 
   29:           host A - evil host, the attacker.
   30:           host B - silent host.
   31:           host C - victim host.
   32: 
   33:         A is your host.
   34:         B is a particular host: It must not send any packets while
   35:           you are scanning C. There are a lot of 'zero traffic' hosts
   36:           in internet, especially in the night :)
   37:         C is the victim, it must be vulnerable to SYN scan.
   38: 
   39:         I've called this scan method 'dumb host scan' in honour of host
   40:         B characteristics.
   41: 
   42: 
   43:         How it works:
   44: 
   45:         Host A monitors number of outgoing packets from B using id iphdr.
   46:         You can do this simply using hping:
   47: 
   48: #hping B -r
   49: HPING B (eth0 xxx.yyy.zzz.jjj): no flags are set, 40 data bytes
   50: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2 ms
   51: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=1 ttl=64 id=+1 win=0 time=75 ms
   52: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=2 ttl=64 id=+1 win=0 time=91 ms
   53: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=3 ttl=64 id=+1 win=0 time=90 ms
   54: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=4 ttl=64 id=+1 win=0 time=91 ms
   55: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=5 ttl=64 id=+1 win=0 time=87 ms
   56: -cut-
   57: ..
   58: .
   59: 
   60:         As you can see, id increases are always 1. So this host have the
   61:         characteristics that host B should to own.
   62: 
   63:         Now host A sends SYN to port X of C spoofing from B.
   64:         (using hping => 0.67 is very easy, http://www.kyuzz.org/antirez)
   65:         if port X of C is open, host C will send SYN|ACK to B (yes,
   66:         host C don't know that the real sender is A). In this
   67:         case host B replies to SYN|ACK with a RST.
   68:         If we send to host C a few of SYN it will reply to B with a few
   69:         of SYN|ACK, so B will reply to C a few of RST... so
   70:         we'll see that host B is sending packets!
   71: 
   72: .
   73: ..
   74: -cut-
   75: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=17 ttl=64 id=+1 win=0 time=96 ms
   76: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=18 ttl=64 id=+1 win=0 time=80 ms
   77: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=19 ttl=64 id=+2 win=0 time=83 ms
   78: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=20 ttl=64 id=+3 win=0 time=94 ms
   79: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=21 ttl=64 id=+1 win=0 time=92 ms
   80: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=22 ttl=64 id=+2 win=0 time=82 ms
   81: -cut-
   82: ..
   83: .
   84: 
   85:         The port is open!
   86: 
   87:         Instead, if port X of C is closed sending to C a few
   88:         of SYN spoofed from B, it will reply with RST to B, and
   89:         B will not reply (see 3). So we'll see that host B is not sending
   90:         any packet:
   91: 
   92: .
   93: ..
   94: -cut-
   95: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=52 ttl=64 id=+1 win=0 time=85 ms
   96: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=53 ttl=64 id=+1 win=0 time=83 ms
   97: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=54 ttl=64 id=+1 win=0 time=93 ms
   98: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=55 ttl=64 id=+1 win=0 time=74 ms
   99: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=56 ttl=64 id=+1 win=0 time=95 ms
  100: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=57 ttl=64 id=+1 win=0 time=81 ms
  101: -cut-
  102: ..
  103: .
  104: 
  105:         The port is closed.
  106: 
  107:         All this can appear complicated to perform, but using two sessions
  108:         of hping on Linux virtual consoles or under X makes it more simple.
  109:         First session listen host B: hping B -r
  110:         Second session send spoofed SYN: hping C -a B -S
  111: 
  112:         Sorry if my english is not so clear.
  113:         However this posting is not adequate to describe exaustively
  114:         this scan method, so i'll write a paper on this topic, specially
  115:         about how to implement this in a port scanner (i.e. nmap), and
  116:         about players characteristics and OS used.
  117: 
  118: happy new year,
  119: antirez

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>