It happens with bad implementations where the DNAT (destination NAT) and the SNAT (source NAT) use a different IP because of a wrong rule or because the outbound and inbound interfaces are separated.

As a result, the operating system of the client will discard right away such a reply (with a TCP RST), because it does not match an existing TCP session.

The idea is that a pentester auditing such an infrastructure with a classic scanner will miss some entry points. A typical scanner relies on the network stack of the system : it will not receive the reply and will consider the port as filtered.

So Jonathan came with a proof-of-concept to illustrate his purpose.

It is composed of a B-Router and a client. The B-Router will intercept the reply and maintain the session by sending an ACK. This way, it handles an asymetric routing scheme for the client. Just add a filtering rule to block your system’s RST (iptables -A OUTPUT -p tcp –tcp-flags RST RST -j DROP ), and you are good to go.

Simple but brilliant, isn’t it ? The great thing is that the code has now been included in Metasploit, so it is even more straightforward.

Check the slides of Jonathan at DEFCON for more info. You can download the source there (or just update your Metasploit and look for it in auxiliaries).

I tried it out and I must say that the new UI is great. I am not a big fan of Flash and I regret this choice. However, the design is excellent, all options are accessible in a logical way. Instead of spreading over the options like it used to be, they come to you in the right order.

I also appreciate that the server and the client set-up are now unified thanks to the web interface (you can access it from localhost or from the network indifferently).

The report section has also been greatly improved.

So, if you were already an Nessus user, it is worth upgrading.

Talking about the set-up, there is an up-to-date package for openSUSE (of course, there are a lot less dependencies than before).

But it seems that Tenable Network Security dropped support for the client on our favorite distribution.

At least, for some reason, they stopped making an universal statically linked binary (though they keep doing it for the server part) and it hasn’t changed since april.

Even the server has a rather limited and obsolete support of openSUSE 10, whereas Debian, Ubuntu and Fedora have support for various versions and architectures. Check there.

This is rather a shame, as openSUSE is one of the major distribution.

I tried some workarounds like converting the deb packages, but, as expected, there are some dependancies issues.

So far, it seems that not many people are affected, because there are not many voices on the forum. I can live without it, but however, this is often a nice and useful tool.

Does anyone use it here ? Or did you get it to work somehow ? If you feel concerned, please let it know to Tenable !

By nature, it is quite difficult to detect if a machine is sniffing, because it operates passively, receiving all packets from the wire but, normaly, answering only to packets destinated to itself.

There are however several methods that make the detection possible.

Some are based on the latency, because in promiscuous mode a machine will take more time to answer (packets have to be processed by the kernel, not the network card only).

Another imply to generate some tricky packets, with a correct IP but a wrong MAC address. The machine should answer only if it is in spoofing mode.

It is also possible to use source-routing with a host on the path that doesn’t route. If an answer comes back anyway, the target is sniffing.

Other methods are implemented by IDS and based on the volume of DNS requests.

Most of these methods are not necessarily reliable, easy to implement. All the ones based on IP routing are quite easy to workaround by the attacker.

Detectpromisc works exclusively at the ARP level.

According to the OS, it sends out some specific ARP packets (multicast, fake broadcast…).

In normal mode, the network card will discard theses illegitimate packets : they call it the hardware filter.
In promiscuous mode, there is no hardware filter : packets reaches directly the kernel (software filter).

Of course, according to the OS, the kernel will behave differently, but some tricked ARP packets generated by Detectpromisc will cause the sniffing machine to send an answer.

It is therefore possible to differenciate a sniffing machine from a normal machine. Plus, as it is quite reliable and OS specific, it is possible to fingerprint the target.

In practice, it has worked very well so far :

% sudo ./detect.py -i eth0 -O 192.168.222.25
Scan right index finger on UPEK TouchStrip
WARNING: No route found for IPv6 destination :: (no default route?)
192.168.222.25 : promiscuous mode card detected
probably: Linux 2.2/2.4/2.6
% sudo ./detect.py -i eth0 -O 192.168.222.26
WARNING: No route found for IPv6 destination :: (no default route?)
192.168.222.26 : promiscuous mode card detected
probably: Windows 2k/NT4

A full paper on how it works is there. Great tool, isn’t it ?

Prads is a fingerprinting scanner, coded in Perl. I am fond of this kind of tool, so I enjoyed checking it out.

Prads operates differently from Nmap or SinFP that I already introduced on this blog. It works passively, meaning that it aims to scan systems without sending out a single packet. It does this by capturing the traffic silently though an interface in promiscuous mode.
The advantage, of course, is that it is much more stealth than a classic scanner, which leaves usually a lot of log entries in firewalls or IDS.
It works on several layers and is based on all the common protocols, that should make it efficient and fast : TCP, UDP, ICMP, ARP.

Using Prads is very simple, just look at prads –help for more info.

There is a sample output, after running it a few seconds on my network :

% sudo perl prads.pl -d eth0 --os --service
Starting prads.pl...
Using eth0
DBD::SQLite::db prepare failed: table asset already exists(1) at dbdimp.c line 271 at prads.pl line 320.
 1243801518 [SYN       ] ip:  192.168.222.23 - Linux - 2.6 (newer, 7) [S4:64:1:60:M1460,S,T,N,W7:.] distance:0 link:"ethernet/modem"
 1243801518 [SYNACK    ] ip: 192.168.222.254 - Linux - 2.6 (newer, 0) [5792:64:1:60:M1460,S,T,N,W0:ZA] distance:0 link:"ethernet/modem"
; 3.0.10-1.1.1 Firefox [192.168.222.23:44555] distance:1 link:SERVICE
 1243801518 [SERVICE   ] ip: 192.168.222.254 - Unknown HTTP - HTTP;  [192.168.222.254:80] distance:1 link:SERVICE
; 3.0.10-1.1.1 Firefox [192.168.222.23:44556] distance:1 link:SERVICE
; 3.0.10-1.1.1 Firefox [192.168.222.23:44557] distance:1 link:SERVICE
; 3.0.10-1.1.1 Firefox [192.168.222.23:44558] distance:1 link:SERVICE
; 3.0.10-1.1.1 Firefox [192.168.222.23:44559] distance:1 link:SERVICE
 1243801536 [SYNACK    ] ip:    91.121.56.96 - Linux - 2.6 (newer, 5) [5792:64:1:60:M1380,S,T,N,W5:ZA] distance:7 link:"GPRS, T1, FreeS/WAN"
 1243801536 [SERVICE   ] ip:    91.121.56.96 - Generic TLS 1.0 SSL - ;  [91.121.56.96:443] distance:1 link:SERVICE
 1243801438 [UDP       ] ip:  192.168.222.23 - @Linux - 2.6 [20:64:1:.:2:0] distance:0 link:ethernet [OLD]
 1243801438 [UDP       ] ip:        89.2.0.1 - @Linux - 2.6 [20:64:1:.:2:0] distance:2 link:ethernet [OLD]
 1243801544 [SERVICE   ] ip:        89.2.0.1 - - - DNS; - [89.2.0.1:53] distance:1 link:SERVICE
 1243801549 [SYNACK    ] ip:   192.168.222.1 - Cisco - 7200, Catalyst 3500, etc [4096:255:0:44:M1460:A] distance:0 link:"ethernet/modem"
 1243801549 [SERVICE   ] ip:   192.168.222.1 - Cisco SSH - Protocol 1.5; 1.25 [192.168.222.1:22] distance:1 link:SERVICE
 1243801549 [SERVICE   ] ip:  192.168.222.23 - OpenSSH - Protocol 1.5; 5.1 [192.168.222.23:42208] distance:1 link:SERVICE
 1243801600 [SYN       ] ip:  192.168.222.23 - Linux - 2.6 (newer, 7) [S4:64:1:60:M1460,S,T,N,W7:.] distance:0 link:"ethernet/modem"  [OLD]
 1243802459 [SYNACK    ] ip:   192.168.222.2 - UNKNOWN - UNKNOWN [8192:128:1:60:M1460,N,W8,S,T:A] distance:0 link:"ethernet/modem"
 1243802459 [SERVICE   ] ip:  192.168.222.23 - Windows SMB - ;  [192.168.222.23:37748] distance:1 link:SERVICE
 1243802459 [SERVICE   ] ip:   192.168.222.2 - Windows SMB - ;  [192.168.222.2:445] distance:1 link:SERVICE
 1243801596 [SYNACK    ] ip:    91.121.56.96 - Linux - 2.6 (newer, 5) [5792:64:1:60:M1380,S,T,N,W5:ZA] distance:7 link:"GPRS, T1, FreeS/WAN"  [OLD]
 1243801596 [SERVICE   ] ip:    91.121.56.96 - Generic TLS 1.0 SSL - ;  [91.121.56.96:443] distance:1 link:SERVICE [OLD]
 1243801367 [UDP       ] ip:   192.168.222.2 - @Windows - MS [20:128:0:.:0:0] distance:0 link:ethernet [OLD]

As you can see, there is already some interesting output.
It detected quite well my Linux laptop running Firefox (UPDATE : according to the author, it is a bug as client detection has not been implemented yet) and surfing a few website, the provider’s DNS servers, another Linux machine and a Windows desktop. Concerning the last two, I guess that a more completed signature database would have allowed a more precise fingerprinting. The Linux box is a wifi Linksys router and the Windows one runs Vista.
Also, the gateway curiously did not show up itself, but the presence of a SSH connection helped to find it.
Finally, there is a little incoherence between the distance shown for the DNS server (=2, correct) and for the service (=1).

To be honnest, so far, I had never found interest in the existing passive scanners. There were POf but it is now pretty outdated and seems not to be developped anymore. Ettercap could fingerprint the system seen while sniffing (profiles), but it was definitely too limited and not really furtive. Moreover, Nmap with the right options, or SinFP itself can be quite stealth.

But now Prads has a place among the tools I use. It is efficient, straight forward and provide some useful info, beyond the OS detection : service and client info, distance, etc. It is nice because, once again, all these data are obtained withou sending out any request at all.

As it is in its early stage, it is very promising and I am looking forward to Prads and its signature database improving. Please keep up the good job !

That’s all for today. This tour was short but I will write again about this tool, as I will be using it. The next post will probably introduce the way the signature database is built and how it can be extended. So keep wired and don’t forget to check the Prads homepage.