LOGS: GIAC GCIA Version 3.4 Practical Detect Ian Eaton

Hello,  

This is my first posted detect, I would appreciate if someone could
review and provide any feedback, thanks in advance.

Regards, Ian Eaton





1 Attack host 10.10.10.186
--------------------------

1.1 Source of Trace
-------------------

This detect was taken from files contained within the tar gzip file
2003.12.15.tgz located at http://www.incidents.org/logs/raw/.  This
archive contains 14 separate binary log capture files named 2003.12.15.1
to 2003.12.15.14.

There is a lot of activity recorded in these files, I have chosen to
concentrate on traffic generated by the subject host 10.10.10.186. 
There is pertinent information relating to this host in all the log
files except the last 2003.12.15.14 so this discussion will cover the
whole set of traces within this archive set.  Among others this host is
seen attacking 172.20.201.198, these are the two systems I have chosen
to write this detect on.

I constructed this diagram and specific information on each host using
techniques as identified by Ian Martin[1], who in-turn used ideas
courtesy of Les Gordon[2] and Andre Cormier[3].

Attacker                                   FTP daemon
10.10.10.186 ----- \                       Subject Target
                   |S                      172.20.201.198
                   HW     Gateway          
Packet Logger ---- UI---- 10.10.10.1       
                   BT                      
                   |C                      Other Targets
DNS/DHCP server    |H                      172.20.11.2
10.10.10.2 --------/                       172.20.11.1


Details on the Attacking host:
Who             Attacker
IP              10.10.10.186
MAC             0:2:a5:b6:e2:e3
MAC owner       Compaq Computer Corporation
P0f             Linux 2.4/2.6 (up: 2 hrs)

Other players in the trace include:

Who             DNS/DHCP server
IP              10.10.10.2
MAC             0:50:56:40:0:64
MAC owner       VMWare
P0f             ?

Who             Subject Target 
IP              172.20.201.198
MAC             ?
MAC owner       ?
P0f             Linux 2.2 (1) (up: 5 hours)

Who             Gateway
IP              10.10.10.1
MAC             0:50:56:40:0:6d
MAC owner       VMWare
P0f             ?

Who             Alternate Target
IP              172.20.11.2
MAC             ?
MAC owner       ?
P0f             ?

Who             Alternate Target
IP              172.20.11.1
MAC             ?
MAC owner       ?
P0f             ?


1.2 Detect was generated by
---------------------------

The 14 files are binary log files which could be generated by any number
of packet capture programs like tcpdump, snort and ethereal.  From what
I have observed they do not seem to follow the pattern as described in
the file http://www.incidents.org/logs/raw/README, the README suggests
the binary log files are made up of traffic triggered by an unknown set
of snort rules.  In these files almost all the packet streams are in
their entirety, for example the full TCP three way hand shake to its
close is intact.

The only thing missing from these capture files is any data after the
96th byte.  The snap length for the capture seems to have been set to 96
bytes so a lot of the payload is missing from the trace, though there is
usually enough to ascertain what is happening within a selected trace.

Whichever program captured these logs it was set to capture log files of
a particular size before rotating to a new file as seen by a consistent
file size of around 3Mb.  The time frame for the captured data is over a
78.5 minute time span.  The activity we are interested in occurs in all
but two files, being the first 12 which contain approximately 25 minutes
of data, the additional two files contain the remaining 50 plus minutes
of data.

To analyse the binary log files I used a few common tools like
tcpdump[4] (version 3.7.2), Snort[5] (version 2.1.1), Ethereal[6]
(version 0.10.2) and p0f[7] (version 2.0.3).  When using snort I used a
default snort.conf with a rule file set dated 20040404, the only change
being to uncomment all rule types to make them available.


1.3 Probability the source address was spoofed
----------------------------------------------

Probability the source was spoofed is nearly impossible, host
10.10.10.186 actively attacks 172.20.201.198 using multiple protocols
including TCP.  For the TCP protocol to function correctly it needs to
maintain state, maintaining state with TCP is nearly impossible to do if
you spoof your IP address.

There is the remote chance that the attacker is sniffing the packets
crossing the wire and spoofing every response packet, though this is not
even remotely likely and would be and extremely advanced technique.  The
attacker does not make an effort to hide the attack as it is easily
detectable, it would be a waste of effort to do this and then make the
attack obvious.


1.4 Description of attack
-------------------------

10.10.10.186 is seen to actively attack 172.20.201.198, the attacker
follows four distinct stages in their attempt to compromise the victim:

Stage1 - Testing of the FTP service on the target for a potential
vulnerability;
Stage2 - Directed attack towards the FTP service with a buffer overflow;
Stage3 - More detailed analysis of the target host via a port scan, OS
fingerprinting and vulnerability assessment; and
Stage4 - Another attack directed against the FTP service with the same
buffer overflow.

The attacker uses a couple of tools in an attempt to compromise this
host.  Starting off with a basic FTP client to test for availability of
specific commands, they then run a specific exploit with the intention
to take advantage of a flaw in the FTP server to compromise the host.

The exploit is executed multiple times throughout the trace and is
described in this CVE entry related to the wu-ftpd 2.6.0 vulnerability:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0573

Further references related to this specific exploit include:

AusCert description of a vulnerability in the site command for wu-ftpd
"site exec" command for version up to and including 2.6.0
http://www.auscert.org.au/render.html?it=1911

Cert advisory for the vulnerability.
http://www.cert.org/advisories/CA-2000-13.html

The exploit code could possible be this:

wuftpd <= 2.6.0 x86/linux remote root exploit (2000/06/28)
http://www.mindsec.com/files/examples/7350wu/7350wu.c

After a few attempts using the exploit the attacker moves on to using a
vulnerability scanner with the aim of discovering as much information
about the target as possible, providing the attacker valuable
information for further attack, though the only real exploit that comes
from the attacker is the SITE EXEC buffer overflow.


1.5 Attack Mechanism
--------------------

As previously mentioned there are four stages to this attack, here I
describe each stage.

1.5.1 Stage1

In files 2003.12.15.1 to 2003.12.15.3 we find what appears at first to
be some fairly benign probing of the FTP service.  The attacker having
connected to the FTP server probes the service for information on its
ability to handle the SITE command.  The site command is intended to be
used by the administrator of the FTP server.  Taken from the apache FTP
server site[8]:

<The> "SITE command is used by the server to provide services specific
to the system. Most of the SITE commands can be used by the admin only.
You can get all the available SITE commands by "SITE HELP".  All the
server administrative tasks can be performed by the SITE command. So the
administrator can monitor, control the server remotely."

Here are some snippets of the payload, remember the snap length on the
trace is set to 96bytes so we are unable to view the whole packet
payload.

attack reqst =>                 SITE help
server respn =>                 214-The following SITE command
server respn =>                   UMASK           GROUP      

In another connection we find the attacker test each SITE option inturn
and receive an error in response, this does appear to be done by hand as
seen by the timing between each request.  Here I show a portion of the
connection with a rounded time value, showing a 4.5 to 7 second gap
between each request.

attack reqst => 95.6sec         SITE index
server respn =>                 500 'SITE INDEX': command not 
attack reqst => 102.5sec        SITE minfo
server respn =>                 500 'SITE MINFO': command not 
attack reqst => 107.1sec        SITE checksum
server respn =>                 500 Nothing transferred yet
attack reqst => 113.4sec        SITE chmod
server respn =>                 500 'SITE CHMOD': command not 

Even though the attacker receives a negative response to the SITE chmod
command they still try to lessen the file permission on a selected file
to have full Read Write Xecute for the Owner Group and Everone,
fortunately for the target this does not work.

attack reqst =>                 SITE chmod 777 libnss_files-2.
server respn =>                 553 Permission denied on serve

During this initial stage we don't find any snort rules triggered by the
attacker's activity.

1.5.2 stage 2

After testing the FTP server for the SITE command the attacker then
tries to exploit it with a buffer overflow.  If we look at file
2003.12.15.4 within Ethereal at line 16801 we see a new connection to
the FTP server, in this trace we see the server response that reveals
the FTP server allows anonymous access and has the name "lazy".  After
the initial login we see the FTP server bombarded with a collection of
strange SITE EXEC commands that have odd parameters, the start of this
trace look like:

server respn =>                 220 lazy FTP server (Version w
attack reqst => 23.02sec        USER ftp
server respn =>                 331 Guest login ok, send your 
attack reqst => 23.04sec        PASS mozilla@
server respn =>                 230 Guest login ok, access res
attack reqst => 23.06sec        SITE EXEC %020d|%.f%.f|
server respn =>                 200-00000000000000000049|0-2|
server respn =>                 200  (end of '%020d|%.f%.f|')
attack reqst => 23.13sec        SITE EXEC 7 mmmmnnnn%.f%.f%.f%
server respn =>                 200-7 mmmmnnnn-2-2200-20700000
server respn =>                 200  (end of '7 mmmmnnnn%.f%.f
attack reqst => 23.27sec        SITE EXEC 7 mmmmnnnn%.f%.f%.f%
server respn =>                 200-7 mmmmnnnn-2-2200-20700000
server respn =>                 200  (end of '7 mmmmnnnn%.f%.f

the trace lasts for just over 27.6seconds and contains 222 packets most
of which look similar to the above.  With the complexity of the commands
and the speed of execution it would be safe to say this trace is from an
automated attack tool.  The attacker seems to have kept this connection
open for a while performing other tasks as a graceful close for this
connection is found in a later file 2003.12.15.7.  Towards the end of
this specific trace we see the attempted buffer overflow finish with
this command sequence:

attack reqst => 28.67sec        id;
server respn =>                 uid=0(root) gid=0(root) groups

This connection only triggered two snort rules

[**] [1:553:6] POLICY FTP anonymous login attempt [**]
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"POLICY FTP anonymous
login attempt"; content:"USER"; nocase;
pcre:"/^USER\s+(anonymous|ftp)/smi"; flow:to_server,established;
classtype:misc-activity; sid:553; rev:6;)

This rule[9] is designed to fire when a user logs into an FTP server
using either the username anonymous or ftp.  If this FTP server is
expected to allow anonymous logins you probably would turn this rule off
for traffic directed to the server otherwise you would expect to receive
a lot of false positives.  This rule is triggered many times throughout
the attacker's activity, from now on I will treat this rule as being
inactive.

[**] [1:1971:3] FTP SITE EXEC format string attempt [**]
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP SITE EXEC format
string attempt"; flow:to_server,established; content:"SITE"; nocase;
content:"EXEC"; nocase; distance:0;
pcre:"/^SITE\s+EXEC\s[^\n]*?%[^\n]*?%/smi"; classtype:bad-unknown;
sid:1971; rev:3;)

Simply put this rule[10] is designed to trigger when the packet contains
SITE EXEC and at least two percent (%) signs separated by a number of
characters within the following string as long as they are not newline
characters.  It is designed to pick up this specific activity directed
to the a WU-FTPD daemon prior to 2.6.2 and does.  To understand how this
command works in greater detail look at some of the references at the
end of the paper.  This rule correctly triggers when the buffer overflow
is attempted against the FTP server and is triggered once for each
attempt made by the attacker.

Looking at file 2003.12.15.4 within Ethereal at line 24339 we see the
attacker makes a new connection in an attempt to verify the previously
executed exploit, this connection continues into the next capture file
2003.12.15.5.  The user logs in with the user jsmith@xxxxxxxxxxxx

server respn =>                 220 lazy FTP server (Version w
attack reqst => 66.22sec        USER anonymous
server respn =>                 331 Guest login ok, send your 
attack reqst => 74.58sec        PASS jsmith@xxxxxxxxxxx
server respn =>                 230 Guest login ok, access res
attack reqst => 74.58sec        SYST
server respn =>                 215 UNIX Type: L8
attack reqst => 76.36sec        PASV
server respn =>                 227 Entering Passive Mode (172
attack reqst => 76.40sec        LIST
server respn =>                 150 Opening ASCII mode data co
server respn =>                 226 Transfer complete.
attack reqst => ~122sec QUIT
server respn =>                 221-You have transferred 0 byt
server respn =>                 221-Total traffic for this ses

Maybe the attacker does not see what they expect so they perform the
same buffer overflow again which is in file 2003.12.15.6.  This attempt
does not complete cleanly as the victim host resets the connection just
before the end.

In file 2003.12.15.7 we find the final close of the first buffer
overflow attempt, maybe having this connection open caused the second
attempt to fail so a third attempt at the buffer overflow is made which
seems to end with a desirable sequence of characters for the attacker.

attack reqst =>                 SITE EXEC 7 t....PsPsu....PsPs
server respn =>                 200-7 t...PsPsu...PsPsv...PsPs
attack reqst =>                 3....F3...jT...'.....=..R..h..
server respn =>                 uid=0(root) gid=0(root) groups

This connection is again reset by the victim host, the buffer overflow
does not appear to be working for the attacker.  In file 2003.12.15.8 we
see the attacker lead off with a DNS lookup and then a connection to the
FTP server with an abrupt but friendly close possibly just verifying the
FTP server is still active on the target.  I suspect the attacker is not
seeing what they want so, they move onto stage 3 of the attack.

During the execution of each buffer overflow snort triggers the same FTP
SITE EXEC rule (SID:1971) otherwise there are no other signs of the
attackers activity.

1.5.3 Stage 3

Looking at file 2003.12.15.8 in ethereal we can see the timing of events

DNS Query                       4.889sec
Start of FTP connection         4.895sec
Close of FTP connection         9.373sec
DNS Query                       85.410sec
Port Scan starts                85.630sec

This shows when the attacker verified the FTP server was still active,
then within the next 75 plus seconds' opens up another attack tool,
configures it and launches it against the victim host.  The attack tool
starts with a DNS lookup and a full connect scan of host 172.20.201.198
which continues well into file 2003.12.15.9.  The scan begins with port
1 and scans sequentially up to port 15000.

This scan is a full connect scan which expects an open port to generate
a SYN/ACK in response to the connection, using tcpdump we are able
identify the ports that gave a positive response.  As the port scan
covers both file 8 and 9 a similar command was required to identify the
open ports discovered in the rest of the scan.

/usr/sbin/tcpdump -nn -vv -r 2003.12.15.8 "host 10.10.10.186 and tcp[13]
& 0x12 = 0x12"

The open ports are:

Port Number     Description
21              ftp
22              ssh
23              telnet
25              smtp
79              finger
98              admin package linux conf, on a Solaris box
111             sunrpc portmapper
113             auth
513             login ?
514             command shell for tcp, udp it is know for syslog
587             submission, mail message submission
1024            ?
1043            ?
1071            ?
3306            mysql
6010            x11-ssh-offset (6010/tcp # SSH X11 forwarding offset)
6011            ?
6012            ?
6013            ?
6014            ?
6015            ?
6016            ?
6017            ?
6018            ?
6020            ?

During the course of this port scan additional snort rules were
triggered, they are fairly basic rules that trigger when a connection is
attempted to specific ports, they could generate numerous false
positives depending on the wether the service is available or not, they
may not be implemented in a production rule set because of the potential
for a high rate of false positives[11].

[**] [1:1418:3] SNMP request tcp [**]
[**] [1:1420:3] SNMP trap tcp [**]
[**] [1:1421:3] SNMP AgentX/tcp request [**]
[**] [1:615:5] SCAN SOCKS Proxy attempt [**]
[**] [1:618:5] SCAN Squid Proxy attempt [**]
[**] [1:620:6] SCAN Proxy Port 8080 attempt [**]

Now the port scan is complete and we see what appears to be a standard
nmap[12] OS finger print attempt[13], several packets with strange flag
combinations hit the target system.  All these packets are within log
2003.12.15.9 and can be viewed in ethereal at the line numbers shown 

T1 - line 29053 - is a SYN packet with a bunch of TCP options to an open
port, in our case we know that port 21 is open.
Source          sport   Destination     dport   Info
10.10.10.186    48599   172.20.201.198  21      [SYN, ECN] Seq=0 Ack=0 Win=3072
Len=0 WS=10 MSS=265 TSV=1061109567 TSER=0
172.20.201.198  21      10.10.10.186    48599   [SYN, ACK] Seq=0 Ack=1 Win=32595
Len=0 MSS=265 TSV=1938094 TSER=1061109567 WS=0
10.10.10.186    48599   172.20.201.198  21      [TCP ZeroWindow] 48599 > 21 
[RST]
Seq=1 Ack=2894031810 Win=0 Len=0

T2 - line 29054 - is a NULL packet with options to open port, again to
port 21.
Source          sport   Destination     dport   Info
10.10.10.186    48600   172.20.201.198  21      [] Seq=0 Ack=0 Win=3072 Len=0 
WS=10
MSS=265 TSV=1061109567 TSER=0
10.10.10.186    48600   172.20.201.198  21      [] Seq=0 Ack=0 Win=3145728 Len=0
WS=10 MSS=265 TSV=1061109567 TSER=0

T3 - line 29055 - us a SYN|FIN|URG|PSH packet with options to an open
port.
Source          sport   Destination     dport   Info
10.10.10.186    48601   172.20.201.198  21      [FIN, SYN, PSH, URG] Seq=0 Ack=0
Win=3072 Urg=0 Len=0 WS=10 MSS=265 TSV=1061109567 TSER=0
172.20.201.198  21      10.10.10.186    48601   [SYN, ACK] Seq=0 Ack=1 Win=32595
Len=0 MSS=265 TSV=1938095 TSER=1061109567 WS=0
10.10.10.186    48601   172.20.201.198  21      [TCP ZeroWindow] 48601 > 21 
[RST]
Seq=1 Ack=2891563653 Win=0 Len=0

T4 - line 29056 - is an ACK to an open port with options
Source          sport   Destination     dport   Info
10.10.10.186    48602   172.20.201.198  21      [ACK] Seq=0 Ack=0 Win=3072 Len=0
WS=10 MSS=265 TSV=1061109567 TSER=0
172.20.201.198  21      10.10.10.186    48602   [TCP ZeroWindow] 21 > 48602 
[RST]
Seq=0 Ack=1567106289 Win=0 Len=0

T5 - line 29057 - is a SYN packet to a closed port with options, the
port scan would have revealed which ports are closed, but port 1 is a
safe bet as it is almost always closed, I have never seen it
legitimately open.
Source          sport   Destination     dport   Info
10.10.10.186    48603   172.20.201.198  1       [SYN] Seq=0 Ack=0 Win=3072 Len=0
WS=10 MSS=265 TSV=1061109567 TSER=0
172.20.201.198  1       10.10.10.186    48603   [TCP ZeroWindow] 1 > 48603 [RST,
ACK] Seq=0 Ack=0 Win=0 Len=0

T6 - line 29058 - is an ACK to a closed port with options
Source          sport   Destination     dport   Info
10.10.10.186    48604   172.20.201.198  1       [ACK] Seq=0 Ack=0 Win=3072 Len=0
WS=10 MSS=265 TSV=1061109567 TSER=0
172.20.201.198  1       10.10.10.186    48604   [TCP ZeroWindow] 1 > 48604 [RST]
Seq=0 Ack=1567106289 Win=0 Len=0

Snort triggered on this connection with this rule because the ACK was
set to zero

[**] [1:628:3] SCAN nmap TCP [**]
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN nmap TCP";
stateless; flags:A,12; ack:0; reference:arachnids,28;
classtype:attempted-recon; sid:628; rev:3;)

T7 - line 29059 - is a FIN|PSH|URG to a closed port with options
Source          sport   Destination     dport   Info
10.10.10.186    48605   172.20.201.198  1       [FIN, PSH, URG] Seq=0 Ack=0 
Win=3072
Urg=0 Len=0 WS=10 MSS=265 TSV=1061109567 TSER=0
172.20.201.198  1       10.10.10.186    48605   [TCP ZeroWindow] 1 > 48605 [RST,
ACK] Seq=0 Ack=0 Win=0 Len=0

Snort triggered on this connection with this rule because URG PSH and
FIN bits where set.

[**] [1:1228:3] SCAN nmap XMAS [**]
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN nmap XMAS";
stateless; flags:FPU,12; reference:arachnids,30;
classtype:attempted-recon; sid:1228; rev:3;)

PU - line 29060 - is a UDP packet to a closed port
Source          sport   Destination     dport   Protocol        Info
10.10.10.186    48592   172.20.201.198  1       UDP     
172.20.201.198          10.10.10.186            ICMP            Destination 
unreachable

Sifting through an nmap signature file from version 3.47 I found this
signature as possibly being that of the target system.  To understand
the makeup of this signature please refer to the Fyodor's classic
fingerprinting article at
http://www.insecure.org/nmap/nmap-fingerprinting-article.txt

Fingerprint Linux 2.3.28-33
Class Linux | Linux | 2.3.X | general purpose
TSeq(Class=RI%gcd=<8%SI=<177B202&>3C1B3)
T1(DF=Y%W=7C70%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=7C70%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(DF=N%TOS=C0|A0|0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

The attacker now has a clear idea as to which ports are open and perhaps
an idea as to which TCP/IP stack is installed on the victim host.  The
traffic generated by the attacker is a series of tests as seen in
capture files 2003.12.15.9 to 2003.12.13.  All the ports previously
observed as being open by the port scan are tested for vulnerabilities. 
Looking at the payload for some of these tests we can determine the
whole scan / fingerprinting effort is likely to have been generated by
the vulnerability scanner Nessus, evidence is contained in this packet
and others:

server respn =>         220 lazy FTP server (Version w
attack reqst =>         USER anonymous
server respn =>         331 Guest login ok, send your 
attack reqst =>         PASS nessus@xxxxxxxxxx
server respn =>         230 Guest login ok, access res
server respn =>         221 You could at least say goo

Due to the snap length we can't see all the information exchanged
between the hosts, the ftp server name is visible, but the version has
been cut off, as a guess I would expect the 'w' to stand for wu-ftp[14]
daemon from Washington University.  We notice that the attacking host
connects with the user anonymous and a password of nessus@xxxxxxxxxx, a
sure sign this is a connection generated by Nessus.  A full nmap TCP
connect() scan is part of a standard Nessus vulnerability assessment

Based on the banners received during the Nessus scan we can identify
some of the software installed on this server which will be valuable
information for the attacker.

Port 21 - w? (I suspect it would have indicated wu-ftp)
Port 22 - SSH-1.99-OpenSSH_2.1.1
port 23 - Red Hat Linux release 7.0
port 25 - 220 lazy ESMTP Sendmail 8.11.0

When port 23 is tested by Nessus it reveals the OS version, which can
easily be cross checked for vulnerabilities specific to this OS.  Nessus
is not a stealthy scanner so it should be expected to trigger any IDS
installed somewhere between the attacker and the destination, these are
the types of rules triggered by the Nessus scan, many of which triggered
more than once during the scan[15].

[**] [1:491:6] INFO FTP Bad login [**]
[**] [1:1672:7] FTP CWD ~ attempt [**]
[**] [1:1432:4] P2P GNUTella GET [**]
[**] [1:361:9] FTP SITE EXEC attempt [**]
[**] [1:489:7] INFO FTP no password [**]
[**] [1:604:5] RSERVICES rsh froot [**]
[**] [1:1992:2] FTP LIST directory traversal attempt [**]

1.5.4 Stage 4

Before the Nessus scan has completed the attacker takes the opportunity
to run the buffer overflow exploit again.  It looks very similar to the
previously described SITE EXEC exploit, the difference with this one is
what happens after the exploit has completed.  The exploit seems to
work, at which point the attacker begins to explore the host system.  To
conserve space I will only present some of the more interesting parts of
the trace

In log file 2003.12.15.10 we see the full buffer overflow executed,
after looking at a few directories on the server the attacker checks
what user they are logged in as

attack reqst =>         id
server respn =>         uid=0(root) gid=0(root) groups

Then checking a documents directory we find a directory containing
documents related to the version of wu-ftp installed, 2.6.0 is
vulnerable to the SITE EXEC exploit.

attack reqst =>         cd doc
attack reqst =>         ls
server respn =>         wu-ftpd-2.6.0

This trace continues in file 2003.12.15.11 where we see the attacker
trying to view the .rhosts file, the reason for this will become
apparent at the end of the trace.

attack reqst =>         cat .rhosts
server respn =>         cat: 
server respn =>         .rhosts: No such file or direc

This triggers a simple snort rule designed to identify if the ".rhosts"
character sequence is seen in a packet headed towards the FTP server:

[**] [1:335:4] FTP .rhosts [**]
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP .rhosts";
flow:to_server,established; content:".rhosts"; reference:arachnids,328;
classtype:suspicious-filename-detect; sid:335; rev:4;)

The attacker then checks many aspects of the host including network
information.  This command reveals all the listening services.

attack reqst =>         netstat -an
server respn =>         Active Internet connections (s
server respn =>         0 172.20.201.198:1020     192.
server respn =>            0      0 172.20.201.198:22 
server respn =>         ISHED tcp        0      0 172 
server respn =>                        udp        0 
server respn =>         DGRAM                    563  

the attacker is also able to view information about the makeup of the
host and view users within the /etc/passwd file

attack reqst =>         uname -a
server respn =>         Linux lazy 2.2.16-22 #1 Tue Au
attack reqst =>         cat passwd
server respn =>         root:x:0:0:root:/root:/bin/bas
server respn =>         che:x:48:48:Apache:/var/www:/b

The last part of the trace continues in file 2003.12.15.12 where the
attacker changes into a new user

attack reqst =>         su - jsmith
attack reqst =>         id
server respn =>         uid=500(jsmith) gid=100(users)

>From here the attacker starts to investigate some of the files on the
system.

attack reqst =>         cd ../work*
attack reqst =>         ls
server respn =>         important-proposal.txt
attack reqst =>         cat imp*
server respn =>         Blah blah blah...\n\n(sounds imp

Further into the trace the attacker tries to append data to the file, I
am not sure how successful the attacker is as the snap length makes it
difficult to see if the data is there when the attacker reads the file
back.

Before disconnecting from the system the attacker tries one more
command.

attack reqst =>         rlogin 172.20.11.1
server respn =>         172.20.11.1: Connection refuse

An attempt is made to remotely log into another system 172.20.11.1 this
receives a negative response.  The previously seen .rhosts check was
related to this command, the .rhosts file holds the rules for external
users and systems that can connect to the system using the well known
"r" commands like rlogin, rsh etc.  It is the remote systems .rhosts
file that determines what hosts can connect.

Normally I would expect to see an attacker set up shop on the server by
uploading further tools and establishing a back door for later access,
instead the attacker just breaks the connection.

1.5.5 The attacker moves on?

I am not sure if the attacker succeeded in their efforts to compromise
172.20.201.198 but they move on to other targets including 172.20.11.2
and 172.20.11.1, making a connection to port 513 (whois daemon) on
172.20.11.2 to find the service not listening.  The attacker moves on to
make a series of SSH connection on 172.20.11.1, which is the same host
they tried to use rlogin to open a remote connection to.

Because the attacker did not leave a back door on 172.20.201.198 when
they decide to return to the host they run the SITE EXEC exploit again,
towards the end of the trace tries to rlogin into 172.20.11.1 again
without success.  This is an attempt to relay though the victim host to
another victim, the goal is to take advantage of privileges the original
victim might have to manipulate the subsequent victim host.


1.6 Correlations
----------------

There are numerous hosts on the 10.10.10.x network attacking hosts in
other networks.  My suspicions are this attacker is within a mock
network created for users to perform attacks on various hosts, there
would be great opportunity for the attacker to share information
identified by other attackers or even use another host to do the
reconnaissance.

The first correlations we can make are with hosts within the same
10.10.10.x subnet the attack host is in.  There are many other hosts
within this subnet that target our victim like host 10.10.10.165 which
performs an entire ping sweep of the IP range that 172.20.201.198 lives
in.

Other hosts that target 172.20.201.198 are:

10.10.10.196, 10.10.10.234, 10.10.10.228, 10.10.10.147, 10.10.10.232,
10.10.10.142, 10.10.10.160, 10.10.10.224, 10.10.10.174, 10.10.10.214.

We know that Nessus is widely advertised as a security tool for the
security professional to perform a vulnerability assessment of various
hosts.  Certain groups within the black hat community are probably using
this tool as well, but because its not very stealthy I am sure the more
experienced black hat is using other more difficult to detect
techniques.

This link talks about another issue with wu-ftpd related to the SITE
EXEC command but in this case is not a buffer overflow, rather a
configuration issue in slackware.
http://www.wu-ftpd.org/wu-ftpd-faq.html#QA72

Wu-ftpd is not the only system to be vulnerable to SITE EXEC exploits,
this is a more recent SITE command vulnerability found in GlobalSCAPE
Secure FTP Server (2004-03-18)  http://secunia.com/advisories/11159/

While compiling the correlations section I found Chris Compton had also
detailed this detect, he makes the assumption that 10.10.10.196 and
10.10.10.186 are working in tandem to penetrate the victim host. 
Chris's paper presents the material slightly differently providing more
of a focus on the actual exploit rather than the sequence of events the
attacker went through.
http://cert.uni-stuttgart.de/archive/intrusions/2004/01/msg00020.html

Davison Avery documented another example of this exploit found within
the same log files but from a different attacking host (10.10.10.228)
and victim (172.20.201.135).
http://cert.uni-stuttgart.de/archive/intrusions/2004/03/msg00097.html


1.7 Evidence of Active Targeting
--------------------------------

The attacker is half way through an FTP connection when logging starts
so there is no traffic indicating prior reconnaissance to locate this
particular host.  The attack seems directed to this particular host
until completion of the last buffer overflow attempt.

The attacking host does not interact with any other hosts until the last
couple of log files, there is again no evidence of previous
reconnaissance being performed at the network layer.  If I am correct in
assuming this is a mock network I suspect there was wide scale sharing
of reconnaissance information at the social level between all the
attackers in the 10.10.10.x network.

When we look at the source port numbers from the attacking host used
with each new connection we can see they increase sequentially with
little to no gaps between successive port numbers.  This indicates the
victim was actively targeted by the attacker and not performing any
other network related tasks while targeting the victim.


1.8 Severity
------------

(Criticality + Lethality) - (System Countermeasures + Network
Countermeasures) = Severity

(4 + 5) - (0 + 0) = 9

Based on the information I have collected on these log files I suspect
this is a network set up specifically to allow people to attack systems,
and test their ability to compromise hosts.

Criticality = 4

A public FTP server for a corporate should have a high criticality, this
service though not as visible as your Web server does provide a public
face to your company.

Lethality = 5

The system is vulnerable to the exploit so a full compromise is possible
via this attack vector providing a root shell.

System Countermeasures = 0

As highlighted by the port scan there are multiple services externally
accessible, if the date on the log files is correct it was recorded late
2003, the software installed on this system is well behind in patches. 
I suspect this environment has been setup to allow people to test their
attack techniques so system countermeasures are not implemented to make
the environment a little easier to attack.

Network Countermeasures = 0

Network countermeasures again are non existent in this environment,
there was no packet filtering in front of the system


1.9 Defence Recommendations
---------------------------

An anonymous FTP server is always open to abuse and thus should be
strictly controlled and monitored.  If you don't require anonymous
access to your FTP server consider more secure methods of file transfer
like SFTP or SCP.  These provide an encrypted tunnel protecting all the
data as it travels over the Internet while also providing a more secure
method of authentication if using cryptographic keys.

There are still uses for anonymous FTP servers, assuming you do want to
allow anonymous access to your files, FTP is an ideal candidate.  If you
allow anonymous access we can assume the data being offered is not high
in value, administrators should make sure this is the case by removing
all restricted data from the server, even if it is not being served by
the FTP daemon, as a compromise of the server would still make this data
available to the attacker.

FTP is a clear text protocol so all aspects of the communication can be
monitored over the network, no one should be able to hide their actions
if you freely allow access to the system so the protocol is probably the
most ideal as you can get maximum benefit from you network IDS.  In the
real world I would expect this whole attack sequence to be detected by
an IDS situated on the outside of the FTP server.  Snort produced more
than enough alarm bells for me to start an investigation.

Because of its clear text nature I would not use FTP anytime I was
offering confidential data, access control should be strict and your
main source of logging may need to come directly from the host itself.

The trace shows that though detectable the attacker was able to deliver
what ever packet they desired to the victim without any form of
filtering.  Two things become apparent, there is no firewall in place,
and the system has what I would consider excessive services available,
especially if its home is directly on the Internet.  All network
services not required for the functioning of the FTP server should be
removed, and a firewall implemented to block any traffic not required
for public access.

System hardening resources include:

OpenNA book: "Securing & Optimizing Linux: The Hacking Solution (v3.0)"
can be located at http://www.openna.com while a free earlier release can
be found at:

http://www.openna.com/products/books/sol/solus.php, from the website:

The SANS store http://store.sans.org/ offers papers on securing Linux
like "Securing Linux: A Survival Guide for Linux Security"

Red Hat hardening script named Bastille Linux can be found at:

http://www.bastille-linux.org/, 

Taking the date of the trace literally (December the 15th 2003) we find
the version of Linux installed on the victim is quite old, this could
indicate a lack of version control, a lack of system management, or
security patch policy.  All these are very important in the day to day
running of an Anonymous FTP server.  There are many guides that can help
with policy creation one being "The SANS Security Policy Project"
http://www.sans.org/resources/policies/ which provides a collection of
policies and policy templates.


1.10 Multiple Choice Test Question
----------------------------------

How many packets does nmap send to a host when trying to identify the OS
type given the -O command line option:
a.      6
b.      7
c.      8
d.      9

Answer: c   (T1 - T7 which are TCP tests, and a UDP test)


1.11 References
---------------

[1]  Ian Martin's practical as posted to the incidents.org mailing list
- http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00089.html
[2]  Les Gordon's practical as posted to the incidents.org mailing list
- http://cert.uni-stuttgart.de/archive/intrusions/2002/10/msg00221.html
[3]  Andre Cormier's practical as posted to the incidents.org mailing
list -
http://cert.uni-stuttgart.de/archive/intrusions/2003/01/msg00162.html
[4]  Tcpdump homepage http://tcpdump.org/
[5]  Snort home page http://www.snort.org
[6]  Ethereal home page http://www.ethereal.com
[7]  p0f home page http://lcamtuf.coredump.cx/p0f.shtml
[8]  http://incubator.apache.org/projects/ftpserver/site_cmd.html
[9]  Snort rule reference http://www.snort.org/snort-db/sid.html?sid=553
[10] Snort rule reference
http://www.snort.org/snort-db/sid.html?sid=1971
[11] To obtain more information on these specific rules search for the
Snort ID at http://www.snort.org/cgi-bin/sigs-search.cgi
[12] nmap's man page http://www.insecure.org/nmap/data/nmap_manpage.html
[13] nmap fingerprinting techniques are described in this classic text -
http://www.insecure.org/nmap/nmap-fingerprinting-article.html
[14] http://www.wu-ftpd.org/
[15] To obtain more information on these specific rules search for the
Snort ID at http://www.snort.org/cgi-bin/sigs-search.cgi

additional references:

Snort User Manual which includes a section on "How to Write Snort Rules
and Keep Your Sanity"  http://www.snort.org/docs/snort_manual/

Detailed description of PCRE (Perl Compatible Regular Expression) as
supported by snort   http://www.pcre.org/pcre.txt

Mastering Regular Expressions (2nd Edition)  Jeffrey E. F. Friedl
(Published by O'Reilly)



_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions