Host Fingerprinting with SinFP

I tried SinFP today. It's a host fingerprinting tool by Patrice Auffret, owner of the cat. The SinFP feature I find interesting is its lack of using odd packets (a la Nmap) to discover remote operating systems.

I tried installing SinFP using CPAN on FreeBSD 6.0, but I got the following errors.

cpan> install Net::SinFP
CPAN: Storable loaded ok
LWP not available
Fetching with Net::FTP:
ftp://archive.progeny.com/CPAN/authors/01mailrc.txt.gz
Going to read /usr/local/cpan/sources/authors/01mailrc.txt.gz
LWP not available
Fetching with Net::FTP:
ftp://archive.progeny.com/CPAN/modules/02packages.details.txt.gz
Going to read /usr/local/cpan/sources/modules/02packages.details.txt.gz
Database was generated on Sun, 21 May 2006 09:26:33 GMT
HTTP::Date not available

There's a new CPAN.pm version (v1.87) available!
[Current version is v1.7602]
You might want to try
install Bundle::CPAN
reload cpan
without quitting the current session. It should be a seamless upgrade
while we are running...

LWP not available
...edited...
Running install for module Net::SinFP
Running make for G/GO/GOMOR/Net-SinFP-1.01.tar.gz
LWP not available
Fetching with Net::FTP:
ftp://archive.progeny.com/CPAN/authors/id/G/GO/GOMOR/Net-SinFP-1.01.tar.gz
CPAN: Digest::MD5 loaded ok
LWP not available
Fetching with Net::FTP:
ftp://archive.progeny.com/CPAN/authors/id/G/GO/GOMOR/CHECKSUMS
Checksum for /usr/local/cpan/sources/authors/id/G/GO/GOMOR/Net-SinFP-1.01.tar.gz ok
Scanning cache /usr/local/cpan/build for sizes
x Net-SinFP-1.01/
x Net-SinFP-1.01/lib/
x Net-SinFP-1.01/lib/Net/
x Net-SinFP-1.01/lib/Net/SinFP/
x Net-SinFP-1.01/lib/Net/SinFP/DB/
x Net-SinFP-1.01/lib/Net/SinFP/DB/SystemClass.pm
...edited...
t/01-use....Can't locate DBIx/SQLite/Simple.pm in @INC (@INC contains:
/usr/local/cpan/build/Net-SinFP-1.01/blib/lib /usr/local/cpan/build/Net-SinFP-1.01/blib/arch
/usr/local/lib/perl5/5.8.8/BSDPAN /usr/local/lib/perl5/site_perl/5.8.8/mach
/usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/5.8.8/mach /usr/local/lib/perl5/5.8.8 .) at
/usr/local/cpan/build/Net-SinFP-1.01/blib/lib/Net/SinFP.pm line 72.
Compilation failed in require at t/01-use.t line 4.
BEGIN failed--compilation aborted at t/01-use.t line 4.
t/01-use....dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/01-use.t 2 512 1 2 200.00% 1
Failed 1/1 test scripts, 0.00% okay. 1/1 subtests failed, 0.00% okay.
*** Error code 2

Stop in /usr/local/cpan/build/Net-SinFP-1.01.
/usr/bin/make test -- NOT OK
Running make install
make test had returned bad status, won't install without force

That's no good. Next I tried downloading the tar.gz archive, which did work.

orr:/usr/local/src# fetch http://umn.dl.sourceforge.net/sourceforge/sinfp/SinFP-1.01-6.tar.gz
SinFP-1.01-6.tar.gz 100% of 2524 kB 470 kBps
orr:/usr/local/src# tar -xzvf SinFP-1.01-6.tar.gz
x SinFP-1.01-6/
x SinFP-1.01-6/LICENSE
x SinFP-1.01-6/LICENSE.Artistic
x SinFP-1.01-6/Makefile
x SinFP-1.01-6/dbi/
x SinFP-1.01-6/dbi/DBI-1.50/
x SinFP-1.01-6/dbi/DBI-1.50/Changes
...edited...
orr:/usr/local/src# cd SinFP-1.01-6
orr:/usr/local/src/SinFP-1.01-6# make
cd dbi && GOMOR_PATH=/usr/local/sinfp perl Makefile.PL && make install
...edited...
Manifying ../blib/man3/Net::Write.3
Manifying ../blib/man3/Net::Write::Layer4.3
orr:/usr/local/src/SinFP-1.01-6# make install
cd dbd-sqlite && GOMOR_PATH=/usr/local/sinfp make install
...edited...
Installing /usr/local/sinfp/bin/sinfp.pl
Installing /usr/local/sinfp/bin/np-anon-pcap.pl
Writing /usr/local/sinfp/lib/auto/gomor/.packlist
FreeBSD: Registering installation in the package database
Appending installation info to /usr/local/lib/perl5/5.8.8/mach/perllocal.pod
if [ ! -d /usr/local/sinfp/bin ]; then mkdir /usr/local/sinfp/bin; fi
if [ ! -d /usr/local/sinfp/db ]; then mkdir /usr/local/sinfp/db ; fi
rm -rf /usr/local/sinfp/bin/*
cp gomor/Net-SinFP-*/sinfp.pl /usr/local/sinfp/bin/
cp gomor/Net-SinFP-*/np-anon-pcap.pl /usr/local/sinfp/bin/
cp gomor/Net-SinFP-*/sinfp.db /usr/local/sinfp/db/

That worked. Now I had a few new programs to try:

orr:/usr/local/src/SinFP-1.01-6# cd /usr/local/sinfp/bin/
orr:/usr/local/sinfp/bin# ls
np-anon-pcap.pl sinfp.pl
orr:/usr/local/sinfp/bin# ./sinfp.pl

-- SinFP - 1.01 --

Usage: sinfp.pl -i targetIp [-p openTcpPort] [-d device] [-f pcapFile]
[-I sourceIp] [-r retryNumber] [-t timeout] [-v]
[-m targetMac (for IPv6)] [-M sourceMac (for IPv6)]
[-s signatureFile]
[-4 | -6]
[-P] [-F filter]
[-H]
[-O]

-4: default, use IPv4 fingerprinting
-6: use IPv6 fingerprinting
-k: keep generated pcap file. Not by default.
-P: passive fingerprinting
-F: pcap filter for passive fingerprinting
-H: use HEURISTIC2 mode to match signatures
(mostly used as a human helper, or for passive OSFP)
-O: print only operating system

Let's try profiling a nearby Win XP SP2 box:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.3 -p 445
T1: B11111 F0x12 W16616 O0204ffff M1460
T2: B11111 F0x12 W17520 O0204ffff010303000101080a000000000000000001010402 M1460
T3: B11011 F0x04 W0 O0 M0
IPv4: EXACT/FULL: Windows: Microsoft: Windows: 2000 (2000 srv SP2)
IPv4: EXACT/FULL: Windows: Microsoft: Windows: XP (XP pro SP2)

Here is the traffic:

1. 16:04:36.260439 IP 192.168.2.5.52221 > 192.168.2.3.445: S 1284670681:1284670681(0) win 5840
2. 16:04:36.261074 IP 192.168.2.5.52221 > 192.168.2.3.445: S 1284670681:1284670681(0) win 5840
3. 16:04:36.261321 IP 192.168.2.3.445 > 192.168.2.5.52221: S 3314059019:3314059019(0) ack 1284670682
win 16616 mss 1460
4. 16:04:36.261385 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
5. 16:04:36.261439 IP 192.168.2.5.52222 > 192.168.2.3.445: S 1284670682:1284670682(0) win 5840
mss 1460,timestamp 1145389380 0,wscale 1,sackOK,eol
6. 16:04:36.261828 IP 192.168.2.5.52223 > 192.168.2.3.445: S 1284670683:1284670683(0) ack 1457354825
win 5840
7. 16:04:36.262164 IP 192.168.2.3.445 > 192.168.2.5.52221: S 3314059019:3314059019(0) ack 1284670682
win 16616 mss 1460
8. 16:04:36.262207 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
9. 16:04:36.262357 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
10. 16:04:36.269336 IP 192.168.2.5.52222 > 192.168.2.3.445: S 1284670682:1284670682(0) win 5840
mss 1460,timestamp 1145389380 0,wscale 1,sackOK,eol
11. 16:04:36.270075 IP 192.168.2.5.52223 > 192.168.2.3.445: S 1284670683:1284670683(0) ack 1457354825
win 5840
12. 16:04:36.275180 IP 192.168.2.3.445 > 192.168.2.5.52222: S 574001478:574001478(0) ack 1284670683
win 17520 mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK
13. 16:04:36.275252 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0
14. 16:04:36.275759 IP 192.168.2.3.445 > 192.168.2.5.52222: S 574001478:574001478(0) ack 1284670683
win 17520 mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK
15. 16:04:36.275805 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0
16. 16:04:36.275958 IP 192.168.2.3.445 > 192.168.2.5.52223: R 1457354825:1457354825(0) win 0
17. 16:04:36.276265 IP 192.168.2.3.445 > 192.168.2.5.52223: R 1457354825:1457354825(0) win 0
18. 16:04:36.276915 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0

What strikes me about this traffic is the fact that it is not incredibly unusual. Sure, the pattern is not normal (there's no reason for the scanning host to send a SYN ACK packet), but the average sys admin is not going to detect this sort of reconnaissance. Here's the pattern.

  1. Scanner: SYN

  2. Scanner: SYN

  3. Target replies: SYN ACK

  4. Scanner tears down: RST

  5. Scanner: SYN with options

  6. Scanner: unsolicied SYN ACK

  7. Target replies to SYN: SYN ACK

  8. Scanner tears down: RST

  9. Scanner tears down: RST

  10. Scanner: SYN with options

  11. Scanner: unsolicied SYN ACK

  12. Target replies to SYN: SYN ACK

  13. Scanner tears down: RST

  14. Target replies to SYN: SYN ACK

  15. Scanner tears down: RST

  16. Target replies: RST

  17. Target replies: RST

  18. Scanner tears down: RST


Here are a few other runs. First, against

richard@janney:~$ uname -a
Linux janney 2.4.27-3-686-smp #1 SMP Wed Feb 8 12:27:28 UTC 2006 i686 GNU/Linux

Linux on i386:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.7 -p 22
T1: B10111 F0x12 W5840 O0204ffff M1460
T2: B10111 F0x12 W5792 O0204ffff0402080affffffff4445414401030300 M1460
T3: B11110 F0x04 W0 O0 M0
IPv4: EXACT/FULL: GNU/Linux: OSS: Linux: 2.6.x (2.6.3)

Next,

richard@thornton:~$ uname -a
Linux thornton 2.6.8-2-32-smp #1 SMP Wed Aug 24 17:55:41 UTC 2005 parisc GNU/Linux

Linux on PA-RISC:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.15 -p 22
T1: B10111 F0x12 W5840 O0204ffff M1460
T2: B10111 F0x12 W5792 O0204ffff0402080affffffff4445414401030300 M1460
T3: B11110 F0x04 W0 O0 M0
IPv4: EXACT/FULL: GNU/Linux: OSS: Linux: 2.6.x (2.6.3)

Next, against the earlier Windows box, to a closed port:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.3 -p 22
T1: B11001 F0x14 W0 O0 M0
T2: B11001 F0x14 W0 O0 M0
T3: B11011 F0x04 W0 O0 M0
IPv4: unknown

Against www.freebsd.org:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 216.136.204.117 -p 80
T1: B11111 F0x12 W57344 O0204ffff M1460
T2: B11111 F0x12 W57344 O0204ffff010303000101080affffffff44454144 M1460
T3: B00000 F0 W0 O0 M0
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.7
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.9
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.10
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.11 (4.11-RELEASE)

Against one of the www.microsoft.com IPs:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 207.46.198.30 -p 80
T1: B11011 F0x12 W16384 O0204ffff M1460
T2: B11011 F0x12 W16384 O0204ffff010303000101080a000000000000000001010402 M1460
T3: B00000 F0 W0 O0 M0
IPv4: EXACT/FIREWALLED: Windows: Microsoft: Windows: 2000
IPv4: EXACT/FIREWALLED: Windows: Microsoft: Windows: 2003 (2003 SP1)

Give SinFP a try and let me know what you think as a comment here.

Incidentally, I am definitely not a "cat person." I am a dog person.

Comments

Anonymous said…
hi,
i downloaded SinFP-1.01-6 and when i tried to 'make' it is omitting following errors, is there any soultion for that.


make[1]: Leaving directory `/home/robot/tools/SinFP-1.01-6/dbi'
cd dbd-sqlite && GOMOR_PATH=/usr/local/sinfp perl -Mlib=../dbi-tmp/lib Makefile.PL && make
Checking installed SQLite version...
SQLite version must be at least 3.1.3. No header file at that
version or higher was found. Using the local version instead.
Warning: prerequisite DBI 1.21 not found.
Writing Makefile for DBD::SQLite
Writing Makefile for dbd-sqlite
make[1]: Entering directory `/home/robot/tools/SinFP-1.01-6/dbd-sqlite'
make[2]: Entering directory `/home/robot/tools/SinFP-1.01-6/dbd-sqlite/DBD-SQLite-1.12'
/usr/bin/perl /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.0/ExtUtils/typemap SQLite.xs > SQLite.xsc && mv SQLite.xsc SQLite.c
Cannot open 'SQLite.xsi': No such file or directory in SQLite.xs, line 72
make[2]: *** [SQLite.c] Error 1
make[2]: Leaving directory `/home/robot/tools/SinFP-1.01-6/dbd-sqlite/DBD-SQLite-1.12'
make[1]: *** [subdirs] Error 2
make[1]: Leaving directory `/home/robot/tools/SinFP-1.01-6/dbd-sqlite'
make: *** [build] Error 2


Thanks
Anonymous said…
There are some things that astonish me quite a bit.

1. Your tcpdump capture
There should not be redundant packets. In your capture, we can see two times the same SYN (1 and 2). So, two times the same RST ... it is bizarre to see these two SYNs sent nearly at the same time. Are you running under a vmware host to launch sinfp ?

2. A Linux 2.4.x flagged as a 2.6.x
If I understand correctly, your first test (after the Windows box) is targetted to a Linux 2.4.27-smp. And sinfp tells it is a 2.6.x. I have never seen that. Are you sure of your target ?

3. The test against www.freebsd.org
You appear to be running some sort of stateful inspection device in output of your network, because when I test www.freebsd.org, I got the response for test 3, and the signature matches fully (FULL, not FIREWALLED match).
Hi Gomor,

1. I ran SinFP on FreeBSD 6.0 on my laptop, not VMware. I just tried the same test twice more and got different results each time. Here are three pcaps for the tests against the Windows box from my laptop: win0.lpc - win1.lpc - win2.lpc

2. I am sure of the target.

3. I have a Linksys WRT54G connected to my cable modem. I will have to compare what I can see at the laptop with what the WRT54G allows out.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics