news aggregator

Links for 2006-05-19 [del.icio.us]

Infosec Daily - Tue, 23/05/2006 - 1:01am
Comment - TrackBack - del.icio.us via: KyleM.xwell [2006/05/20]

[no title]

Infosec Daily - Tue, 23/05/2006 - 1:00am
Host Fingerprinting with SinFP

The picture at left is what happens when you write a security tool without a logo, but you do post pictures of your cat.

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. Comment - TrackBack - del.icio.us via: TaoSecurity [2006/05/22]

Perl Is My… T-Shirt

Infosec Daily - Mon, 22/05/2006 - 10:47pm

Coast Guard Solicits Hollywood to Help with Movie Plot Threats

Infosec Daily - Mon, 22/05/2006 - 10:16pm

Really:

Trying to avoid a failure of imagination in its uncharted new role, the agency has even called in screenwriters from Hollywood to help sketch terrorism situations.

“The biggest change is that the Coast Guard has gone from being an organization that ran when the bell went off to being a cop on the beat at all times,” said Capt. Peter V. Neffenger, who recently gave up command of the port here for a position in Washington and who consulted with the screenwriters.

watched Hollywood’s output in recent years knows that screenwriters aren’t the most creative bunch of people on the planet. And anyway, they can have all of these ideas for free. Comment - TrackBack - del.icio.us via: Schneier on Security [2006/05/22]

A Holiday Without Booze - Victoria Day

Infosec Daily - Mon, 22/05/2006 - 10:01pm
Well, this is a long weekend in Canada. We celebrate the birthday of Queen Victoria. Victoria Day has been celebrated in Canada since May 24 was declared a holiday in 1845. This weekend is the first long weekend of the summer and it brings out campers and the party animals. This one weekend of the year has turned into such a mess. Less and less of the third Monday of recent Mays can be defined as in any way amusing. Drunks and fights and fires and car crashes should only be entertainment on video games. But its not, it is now become a reality. Comment - TrackBack - del.icio.us via: kuro5hin.org [2006/05/22]

Podsploiting

Infosec Daily - Mon, 22/05/2006 - 10:00pm

We released two new security advisories today, regarding the podcast-catching clients prodder and perlpodder.

Both are vulnerable to remote arbitrary command execution by a malicious server, which can append the commands to the URL of the multimedia files.

Interestingly, security advisories regarding podcast clients or servers are very rare, although everyone and his dog is podcasting at the moment. Either all the programs are very secure, or nobody is having a closer look at the software. Guess what we think is the case…

The advisories can be found at

Heise already has a news item about it.

Oh, and by the way: If you want to tell SecuriTeam about your new advisories and want to use their GPG-key, it is expired since 2004-07-22. Not that it matters for the notification about a public advisory, but a group working in the security field should be able to update their keys, one would think…

Comment - TrackBack - del.icio.us via: RedTeam [2006/05/22]

Interview with Luis Lavena

Infosec Daily - Mon, 22/05/2006 - 10:00pm
Syndicate content
design by Ixis IT