|
AFD Technical Information
How does AFD perform active filtering detection?
Initially, lib-pcap was considered for trying to detect
things like TTL differences, RST vs FIN, etc. It was quickly
realised that this wasn't needed. The objective was so simple;
Is a dynamic filter in place between the tester and the target.
The answer is binary - if we believe that the target is dynamically
filtered, then its over. If we believe that the target is clean,
then the testing is on.
In the program's usage (osstmm-afd -h), the test methodology has
been documented this way;
osstmm-afd: What the ..;
afd is the active filtering detector - designed to meet OSSTMM's
requirement for detecting active filtering such as IDP or IPS.
The program works by taking a list of known-ugly signature strings
and requesting them against the target web service, in an attempt
to get locked out.
Return condition -2 means; time-out or prematurely closed
connections, or the inability to establish a new connection.
Condition -2 signifies active filtering, -1 signifies comms
failure, while 0 is a nil result (all ok, and likely to be no
filtering).
By hurling signatures at the target, we hope to invoke a negative
response (from anything).
What differentiates a communications failure vs active filtering?
There are a number of trip conditions, and these are dependant on
on the calling function (see below). The program has decisions
against each function error, pre-programmed into it; determining as
to whether the error is likely to be a communications error or a DoS
employed by a filter. This is possible as the socket code takes into
account network error conditions - such as Connection Refused,
Connection Timed Out, Network Unreachable - even the fact that the
program is no longer using a socket is a good indicator that the
underlying connection (TCP stream) has been shut down.
So, by function;
connect()
DoS in Effect: ENOTSOCK, ECONNREFUSED, ETIMEDOUT, ENETUNREACH
Comms Failure: EFAULT, EISCONN, EADDRINUSE, EINPROGRESS, EAGAIN,
EAFNOSUPPORT, EACCES, EPERM, any other.
send()
DoS in Effect: EBADF, ECONNRESET, ENOTCONN, ENOTSOCK, EPIPE
Comms Failure: EAGAIN, EDESTADDRREQ, EFAULT, EINTR, EINVAL,
EISCONN, EMSGSIZE, ENOBUFS, ENOMEM, EOPNOTSUPP,
any other.
recv()
DoS in Effect: ECONNREFUSED, ENOTCONN, ENOTSOCK
Comms Failure: EBADF, EAGAIN, EINTR, EFAULT, EINVAL, ENOMEM,
any other.
close()
DoS in Effect: EBADF
Comms Failure: EINTR, EIO, any other.
Note that the close() can be used as the the HTTP/1.1 request is
issued without the "Close" header - so the connection should remain
open up until our close() point, no matter how fast the comms are
(or slow the test machine is) - unless the IDP RST the stream, for
example.
How can I test osstmm-afd locally?
The fastest valid test for the tool is to hit a port that is known
to not be open/running any listener. So try your web server at
port 99/TCP
[root@cipher afd-0.7]# osstmm-afd -P HTTP -t www -p 99 -v
Performing active fitering detection against the following target;
HTTP://www:99/
Performing: Nil parameter Requests
Test: 001 / 081
Connecting : 192.168.1.247:99 .. Connection refused [ECONNREFUSED]
Target seems likely to have active filtering running.
Note that as it was the first test that failed, you should
confirm the target, port and protocol parameters.
Compare this to the same test against port 80/TCP;
[root@cipher afd-0.7]# osstmm-afd -P HTTP -t www -p 80 -v
Performing active fitering detection against the following target;
HTTP://www:80/
Performing: Nil parameter Requests
Test: 001 / 081
Connecting : 192.168.1.247:80 .. Connected.
Sending Sig : .. 188 bytes sent.
Validating : Retrieve .. 1400 bytes avail.
Closing : Closed.
Test: 002 / 081
Test Skipped: Test ignored due to protocol mis-match
[........]
Performing: Nil parameter Requests
Test: 080 / 081
Connecting : 192.168.1.247:80 .. Connected.
Sending Sig : .. 188 bytes sent.
Validating : Retrieve .. 1400 bytes avail.
Closing : Closed.
Test: 081 / 081
Test Skipped: Test ignored due to protocol mis-match
Target appears to be clean - no active filtering detected.
This demonstration shows that you are in a good position to
assess a halt on communications based on decisions from
non-local infrastructure.
One other test worth considering, if you don't have access to an
IDP device, is testing against IDS and seeking out the alarm events
(the equivalent points where an IDP may have commenced its
counter-measure deployment). The test web service is arbitrary
(it need only respond to HTTP/1.1 requests).
This Snort Log file was recorded on
a Windows XP PC running Snort, and the Abyss web server - both
in default installation condition. As can be seen from the log,
46 of the 48 attack signatures in the original default AFD v0.5
configuration file, were detected by Snort. This is a good
indication that an IDP of equivalent "awareness" is likely to
have responded to an AFD scan.
Where have the 81 v0.7 AFD signatures come from?
The first (and last) two signature(s) were home made - a simple request for the
root HTTP document, or empty SMTP message. This signature type is not considered
an attack signature, and is included only to provide a connection test.
The next 53 signatures were taken from this paper at CGI Security;
http://www.cgisecurity.com/papers/fingerprint-port80.txt
The next 20 signatures were taken randomly from this Snort rule list, and
then re-engineered back into recognisable attack patterns (10 HTTP and 10 SMTP);
http://www.bleedingsnort.com/bleeding-all.rules
The final 4 signatures were constructed from the Eicar test virus
pattern;
http://www.eicar.com/anti_virus_test_file.htm
Here is a sample signature configuration entry for one of the
fingerprint-port80 examples;
new.signature cmdexe1
cmdexe1.label "cmd.exe" Commands
cmdexe1.protocol HTTP
cmdexe1.example http://host/x.asp=../../WINNT/system32/cmd.exe?dir+c:\
cmdexe1.parameter ../../WINNT/system32/cmd.exe?dir+c:\
Realistically, any signature could be represented in this format. See the latest source for the most current osstmm-afd.cfg signature file.
Could the tool be extended, perhaps for other protocols?
It could be expanded fairly readily. The tool, was originally designed
specifically for HTTP (and not HTTPS). This was primarily due to HTTP
being the protocol of choice for users, hackers and security folk, alike.
However, in its current form, it supports SMTP and HTTP; and can be further
extended for any non-interactive TCP protocol, very easily. The signatures
hurled at the target are maintained in the configuration file
/usr/local/etc/osstmm-afd.cfg and are entirely flexible.
The one extension that was considered, but has not yet been implemented,
is the addition of a timer to each test (or signature hurl). After three
tests, the AFD could declare a time average required to perform a test.
This could then be used to detect more subtle variations (such as tar-pitting)
when things start to slow down.
What other features does the program support, can I embed it?
There are a number of useful features that have been added
despite no immediate need or use, that should keep the tool more
generally relevant (such as user agent, cgi-path, referer string,
silent output for embedding, and virtual host support). The v0.7
command options include the following;
osstmm-afd: Usage;
Long Short Args
~~~~ ~~~~~ ~~~~
--config -c {"string"} Specify the configuration file to use
--dangerous -! Enable dangerous signatures
--debug -D Enable debugging
--help -h Display this help screen
--protocol -P {HTTP|SMTP} Specify the testing protcol
--port -p {1-65535} Specify the target port
--silent -s Report zero output (only error level)
--target -t {"string"} Specify the target hostname or IP
--timeout -T {1-120} Specify the connect timeout in seconds
--verbose -v Display test detail as executed
--version -V Display version and exit
Protocol: HTTP
--agent {"string"} Configure User-agent: header value
--path {"string"} Specify the path, program and variable
--referer {"string"} Configure Referer: header value
--vhost {"string"} Specify the target virtual host name
Protocol: SMTP
--helo {"string"} Specify source server name
--address-all {"string"} Specify all addresses as string
--mail-from {"string"} Specify mail from: address
--rcpt-to {"string"} Specify rcpt to: address
--rfc822-from {"string"} Configure From: address
--rfc822-to {"string"} Configure To: address
--rfc822-subj {"string"} Configure Subject: text
How about an HTTP usage example and its equivalents?
A complex usage example may be;
[root@cipher afd-0.7]# osstmm-afd -P HTTP --timeout 2 \
--agent "NCSA_Mosaic/2.8 (X11; FreeBSD 5.2.1 i686)" \
--referer "http://www.google.com/search?hl=en&q=foo&btnG=Search&meta=" \
--vhost "www.scan.target.com" --path "/app/login.php?user=" \
--target 192.168.1.247 -p 80 -v
Which would produce HTTP/1.1 queries such as this one;
GET /app/login.php?user=../../WINNT/system32/cmd.exe?dir+c:\ HTTP/1.1
Host: www.scan.target.com
Referer: http://www.google.com/search?hl=en&q=foo&btnG=Search&meta=
User-agent: NCSA_Mosaic/2.8 (X11; FreeBSD 5.2.1 i686)
X-AFD-INTERFACE-lo: 127.0.0.1
X-AFD-INTERFACE-eth0: 192.168.1.21
Pragma: no-cache
Accept: */*
This query would be functionally equivalent to the following
netcat command;
[root@cipher afd-0.7]# nc -w 2 192.168.1.247 80 << EOF
GET /app/login.php?user=../../WINNT/system32/cmd.exe?dir+c:\ HTTP/1.1
Host: www.scan.target.com
Referer: http://www.google.com/search?hl=en&q=foo&btnG=Search&meta=
User-agent: NCSA_Mosaic/2.8 (X11; FreeBSD 5.2.1 i686)
X-AFD-INTERFACE-lo: 127.0.0.1
X-AFD-INTERFACE-eth0: 192.168.1.21
Pragma: no-cache
Accept: */*
EOF
If you operate within the finance,
communications technology,
insurance,
business services,
educational, or
legal
sectors, then see how Pure Hacking can help you manage the risk for your organisation.
Business Services
"Pure Hacking distinguish themselves by successfully communicating difficult
technical concepts to all levels. They also followed through with their promise
to continue support in explaining these concepts long after our contract finished."
IT Manager - Production Systems, International Business Services Corporation
|
|
