exploit the possibilities

p0fspoof.txt

p0fspoof.txt
Posted Feb 14, 2006
Authored by poplix | Site tripp.dynalias.org

A paper discussing passive OS fingerprinting and spoofing OpenBSD pf "os" rulesets.

tags | spoof
systems | openbsd
MD5 | 76d3abde5584b498d8c1a5bcc06a4495

p0fspoof.txt

Change Mirror Download
TRIPP Traffic Rewriter for Ip (v4) Packets

http://tripp.dynalias.org - poplix@papuasia.org

date: 02-13-2006


Passive OS fingerprint spoofing and how to authenticate connections to OpenBSD pf:

Rewriting tcp/ip headers can be useful to change the non standard tcp/ip
stack behavior in order to spoof your os to programs that perform analisys
of the headers values to identify oss. This well known method to
passively fingerprint oss is based on the analisys of those tcp/ip headers
fields that are vendor specific such as tcp options, window size, ttl, ecc.
There are several programs out there that implements this tecnique:
p0f, ettercap, OpenBSD pf, ecc but deciveing this kind of programs can
result in waste of time. In fact it's well known that packets header can be
easily forged or manipulated so os fingerprinting (ospf) is used for
statistics, performance improvements or similar only.
But this is not the point: is possible to use osfp spoof in conjunction with
OBSD pf as an alternative to port knocking. Port knocking is useful to
increase stealthness of the internet servers, but it requires additional
software to run on those systems increasing security risks. Using ospf
spoof is possible to have stealthness using the native OBSD kernel code
only.
As mentioned above OpenBSD pf has a builtin passive os fingerprinter
that can be used in pf rules, an example can be:

pass in proto tcp from any os "Windows 2000"

This rule allows packets from any Windows 2000 machine.
With this feature is possible to block all incoming packets except those
that come from a specific operating system.
The idea is to use os fingerprints as a key. An user can invent a specific
sequence of header values that will identify his fake os, add it to
fingerprints database and use it in the firewall.
The result is an OBSD machine that is totally stealth to port scans but
the owner can log into it using his specific set of header values.


I wish to propose an alternative to port knocking that uses the native
OpenBSD's pf code only. The idea is to use the pf's passive os
fingerprinter to authenticate initial SYN packets.
With a tool (or kernel patch) able to rewrite packets header is possible
to use a specific sequence of header fields as a key to validate packets.

I've tested this tecnique with a tool I'm writing that is capable of
rewriting outgoing (and incoming) packets, but maybe fragroute with some
modifications can do the same.


The Test:

I've a linux box capable of setting arbitrary header values (using
tripp) so I choosed a set of tcp/ip headers fields that are not listed
in osfp database and then I added this sequence naming it "poplix".

I added the invented os fingerprint to pf os databese by inserting
this line to /etc/pf.os (my os fingerprints database)

8192:128:0:60:M3884,N,W0,N,N,T:poplix:::poplix fi

Now I can configure pf with the following ruleset:

block in on rl0 all
pass in from any os poplix keep state

This new os fingerprint entry will identify
my packets and allow them to pass through firewall.


Linux client runs tripp with the following rules:

OUT (tcp.flags='syn')
set(
tcp.win='8192',ip.ttl='128',ip.flags.df='0',
tcp.options='mss=3884+noop+wss=0+noop+noop+ts=TS'
);

This rule tells tripp to rewrite all outgoing tcp packets with the SYN
flag set only allowing my first handshake packet to match "poplix"
fingerprint.


Result:

root@sd:# ssh papuasia.org -l poplix
ssh: connect to host papuasia.org port 22: Connection timed out
root@sd:#


root@sd:~# tripp -o eth0 -f rules -g 10.0.0.138 -S &
rewriter for outgoing traffic started

root@sd:~# ssh papuasia.org -l poplix
poplix@papuasia.org's password: **********
poplix@papuasia.org:~$


Note that is also possible to kill tripp after the connection
is estabilished (in this case on password request).





If pf is configured to drop (not reject) SYNs (or if our kernel drops RSTs)
it's possible to perform this kind of *authenication* without a real packet
rewriting software. In fact it's not necessary that our original syn (the
one generated by the kernel) avoids reaching its destination due to the
firewall drop. It's sufficent a tool that sniffs our syn, applys the
adjustment needed and then resends it. Doing that we'll have two SYNs per
connection, the first is generated by the kernel and the second is a
rewrite of the first one and will match the p0f signature.
Anyway it'll result in a dirty and sospicious handshake and possibly it'll
add entries to logfiles. The big advantage is that the rest of the tcp
stream is totally independent from any supplementary code, in fact tools l
ike tripp or fragroute need to rewrite the entire tcp stream (otherwise it's
possible to kill such tools after the connection is estabilished and restart
them when a new connection is needed).

A proof-of-concept is available at
http://tripp.dynalias.org/authsyn.tgz



Login or Register to add favorites

File Archive:

May 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    14 Files
  • 2
    May 2nd
    3 Files
  • 3
    May 3rd
    1 Files
  • 4
    May 4th
    18 Files
  • 5
    May 5th
    15 Files
  • 6
    May 6th
    21 Files
  • 7
    May 7th
    15 Files
  • 8
    May 8th
    19 Files
  • 9
    May 9th
    1 Files
  • 10
    May 10th
    2 Files
  • 11
    May 11th
    18 Files
  • 12
    May 12th
    39 Files
  • 13
    May 13th
    15 Files
  • 14
    May 14th
    17 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    2 Files
  • 17
    May 17th
    2 Files
  • 18
    May 18th
    15 Files
  • 19
    May 19th
    21 Files
  • 20
    May 20th
    15 Files
  • 21
    May 21st
    15 Files
  • 22
    May 22nd
    6 Files
  • 23
    May 23rd
    1 Files
  • 24
    May 24th
    1 Files
  • 25
    May 25th
    2 Files
  • 26
    May 26th
    23 Files
  • 27
    May 27th
    13 Files
  • 28
    May 28th
    18 Files
  • 29
    May 29th
    17 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2020 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close