Re: Some thoughts from Defcon ...

["Andrew A. Vladimirov" <andrew () arhont com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rodrigo Rubira Branco wrote:
| Hi Andrew,
|
| I'm a Security Responser from Firewalls.com.br and likes to know more
| about your idea.
|
| Thank you,
|
| Rodrigo.
|
|

The general idea is to build port forwarding enumeration into nmap, e.g.
~  whatever the ports forwarded by the firewall are forwarded to the same
or different hosts. This is also related to finding out whether the
range of evaluated IP's belongs to the same or different hosts.

Lets say we have a host xxx.xxx.xxx.xxx which has ports 22 and 25 open.
~From the output of tcptraceroute or better lft (which would say
**   [firewall] the next gateway may statefully inspect packets )
you suspect that this host is a firewall which forwards these ports to
the sshd and sendmail behind it. Do the daemons run on the same or
different box ?

#hping2 xxx.xxx.xxx.xxx -c 5 -S -s 20 -p 22 --tcp-timestamp

- --- xxx.xxx.xxx.xxx hping statistic ---
5 packets tramitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 33.4/34.9/35.6 ms
HPING : S set, 40 headers + 0 data bytes
len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=0
win=5792 rtt=35.4 ms
~  TCP timestamp: tcpts=324757788

len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=1
win=5792 rtt=33.4 ms
~  TCP timestamp: tcpts=324757887
~  HZ seems hz=100
~  System uptime seems: 37 days, 14 hours, 6 minutes, 18 seconds

len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=2
win=5792 rtt=34.6 ms
~  TCP timestamp: tcpts=324757987
~  HZ seems hz=100
~  System uptime seems: 37 days, 14 hours, 6 minutes, 19 seconds

len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=3
win=5792 rtt=35.2 ms
~  TCP timestamp: tcpts=324758087
~  HZ seems hz=100
~  System uptime seems: 37 days, 14 hours, 6 minutes, 20 seconds

len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=4
win=5792 rtt=35.6 ms
~  TCP timestamp: tcpts=324758188
~  HZ seems hz=100
~  System uptime seems: 37 days, 14 hours, 6 minutes, 21 seconds

#hping2 xxx.xxx.xxx.xxx -c 5 -S -s 20 -p 25 --tcp-timestamp

- --- xxx.xxx.xxx.xxx hping statistic ---
5 packets tramitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 33.9/34.3/34.7 ms
HPING xxx.xxx.xxx.xxx (eth1 xxx.xxx.xxx.xxx): S set, 40 headers + 0 data
bytes
len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=0
win=5792 rtt=34.2 ms
~  TCP timestamp: tcpts=1663107403

len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=1
win=5792 rtt=34.7 ms
~  TCP timestamp: tcpts=1663107914
~  HZ seems hz=100
~  System uptime seems: 192 days, 11 hours, 44 minutes, 39 seconds

len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=2
win=5792 rtt=33.9 ms
~  TCP timestamp: tcpts=1663108426
~  HZ seems hz=100
~  System uptime seems: 192 days, 11 hours, 44 minutes, 44 seconds

len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=3
win=5792 rtt=33.9 ms
~  TCP timestamp: tcpts=1663108938
~  HZ seems hz=100
~  System uptime seems: 192 days, 11 hours, 44 minutes, 49 seconds

len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=4
win=5792 rtt=34.5 ms
~  TCP timestamp: tcpts=1663109450
~  HZ seems hz=100
~  System uptime seems: 192 days, 11 hours, 44 minutes, 54 seconds




Not only the uptime is different, but also the TCP timestamp
incrementation goes by a different step value (~ 100 and ~ 500). Perhaps
this incrementation step difference can be used for OS fingerprinting.
By the way, the incorrect (~ 500) tcpts increment machine is Red Hat 7.3
running vanilla kernel.

To verify what we see above by looking at TCP ISN's lets fire ISNProber:

#perl isnprober -n 10 -c xxx.xxx.xxx.xxx:22 xxx.xxx.xxx.xxx:25

- -- ISNprober / 1.02 / Tom Vandepoel (Tom.Vandepoel () ubizen com) --

Using eth1:xxx.xxx.xxx.xxx

Probing host: xxx.xxx.xxx.xxx on TCP port 22.
Probing host: xxx.xxx.xxx.xxx on TCP port 25.

Host:port           ISN            Delta
xxx.xxx.xxx.xxx:22    -265972978
xxx.xxx.xxx.xxx:25    -280890885     -14917907
xxx.xxx.xxx.xxx:22    -265633457     15257428
xxx.xxx.xxx.xxx:25    -280560606     -14927149
xxx.xxx.xxx.xxx:22    -265303477     15257129
xxx.xxx.xxx.xxx:25    -280220032     -14916555
xxx.xxx.xxx.xxx:22    -264962858     15257174
xxx.xxx.xxx.xxx:25    -279890905     -14928047
xxx.xxx.xxx.xxx:22    -264642219     15248686
xxx.xxx.xxx.xxx:25    -279559150     -14916931
xxx.xxx.xxx.xxx:22    -264303262     15255888
xxx.xxx.xxx.xxx:25    -279219096     -14915834
xxx.xxx.xxx.xxx:22    -263963523     15255573
xxx.xxx.xxx.xxx:25    -278878432     -14914909
xxx.xxx.xxx.xxx:22    -263623800     15254632
xxx.xxx.xxx.xxx:25    -278536914     -14913114
xxx.xxx.xxx.xxx:22    -263294106     15242808
xxx.xxx.xxx.xxx:25    -278219277     -14925171
xxx.xxx.xxx.xxx:22    -262963297     15255980
xxx.xxx.xxx.xxx:25    -277887876     -14924579

xxx.xxx.xxx.xxx:22     <> xxx.xxx.xxx.xxx:25     == [-]

Voila, 2 different hosts behind the firewall. Of course there are
more possible methods which are mentioned in the original letter and if
they can be combined and implemented in nmap that could've been cool.

Andrew

P.S.: I'll forward this reply to the list as well for anyone curious or
bored.

- --
Dr. Andrew A. Vladimirov
CISSP #34081, CWNA, CCNP/CCDP, TIA Linux+
Security Manager
Arhont Ltd - Information Security.

Web: http://www.arhont.com
Tel: +44 (0)870 44 31337
Fax: +44 (0)1454 201200
GPG: Key ID - 0x1D312310
GPG: Server - gpg.arhont.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/PBvtlOHkKR0xIxARAsbNAKD1pnxnEOlOuA0nJW1kuC9+BdvSqgCfZMPZ
THOt7g7Bj/312YoDDTmiJ9U=
=52Lr
-----END PGP SIGNATURE-----



---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).