RE: LOGS: GIAC GCIA Version 3.4 Practical Detect Ian Eaton

        Comments inline below.
        Don M, GCIA Local mentor

> -----Original Message-----
> From: intrusions-bounces@xxxxxxxxxxxxxx 
> [mailto:intrusions-bounces@xxxxxxxxxxxxxx] On Behalf Of Ian Eaton
> Sent: Saturday, May 22, 2004 8:47 AM
> To: intrusions@xxxxxxxxxxxxx
> Subject: [Intrusions] 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.

        don - interesting.  out of couriosity, are there other ones like
that?
        do you have, or do you explain, why there are different data sets?

> 
> 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
> 

        don - do you explain in a different detect how you go
        about discerning this info?  I think you should explain
        in your own words the process in at least one of your
        detects.

> 
> 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)

        Don - it would be best if you showed the p0f command and output,
        also how you narrowed the source data (performed data reduction)
        so that p0f would work.

> 
> 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           ?

        don - do you explain later how you know it's a dns and a 
        dhcp server...

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

        don - how do you know its up 5 hrs - what does this mean
> 
> Who           Gateway
> IP            10.10.10.1
> MAC           0:50:56:40:0:6d
> MAC owner     VMWare
> P0f           ?

        don - gw as in the network gw or as in a gw2k pc?

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

        don - does this mean p0f could not discern anything ?
        if so, state that - as it is HIGHLY VALUABLE information
> 
> 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.

        don - "hand shake to its close is intact" - doesn't make
        to much sense?

> 
> 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.

        don - do you have a sample trace of a handshake,
        do you have some packets that are ACK packets, etc?
        The idea is to have some support to bolster your case.
        Personally, I believe you - it would be useful to show
        some packets at some point in the process to support
        your conclusion.

> 
> 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.

        don - hmmm.... do you mean sniffing locally on the
        wire or doing a man in the middle kind of thing?
        
> 
> 
> 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:

        don - Ok - at this point you have said X is atk'ng Y
        a few times, but I haven't seen a packet trace that supports your 
        point.  You really should show some flows that support the 
        point.  If later, then say so; if not, then you need some
        X -> Y stuff and Y -> X response stuff.

> 
> 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.

        don - see, here's the kind of thing you need.  S1 -
        show a few packets, S2, a few more, etc.
> 
> 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.

        don - and you know this how, because, will you explain
        later, that sort of thing?
> 
> 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

        don - this is an example of correlation - they all belong
        in one section in the write up if possible.  helps
        preventing you from forgetting them, helps the grader
        give you credit for putting them in the right spot, etc.

> 
> 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."

        don - description ok, but where is the traffic?
        where is the -X value (data paylow) o/t traffic?

> 
> 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   

        don - and you got this how ...   meaning what did you
        do to extract this ever so cool info from the data ...
        That would add a lot of value here.  Remember -
        the practical is about demonstrating what you have
        learned and the process you used to get there.
> 
> 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.

        don - it would add value if you said how many times, not
        just "many times".  
> 
> [**] [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"

        don - it would be good to show a half a dozen lines or  
        so and then explain you do data reduction, and how you
        do that, and then produce the open ports list below.

> 
> 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 

        don - now that's some meaty content!
> 
> 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%UL
> EN=134%DAT=E)

        don - cool ... very cool...

> 
> 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

        don - ok, so you draw the conclustion that its nessus,
        but what did you look at in the nessus app to correlate..
        is there a particular assessment that matches the "goo"?
        in other words, does the nessus scanner have a ftp test
        that uses this email addr?

> 
> 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.

        don - cool...


> 
> 
> 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.

        don - this text above is off.  the point of 
        correlations - is to discuss how your detect
        correlates w/ others, with SANs, GIAC, Sec Focus,
        CVE, etc.       This text belongs elsewhere ..
> 
> 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

        don - this is right.

> 
> 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/

        don - also goot.
> 
> 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
> 

        don - you also had some other text way up top that belongs here.

> 
> 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.

        don - good.  
> 
> 
> 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

        don - I don't think you can score a zero ...

> 
> 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.

        don - at this point I don't recall all of the text above,
        but didn't you show that they were thwarted at some points?

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

`       don - missing a period.

> 
> 
> 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)

        don - you need to explain your answer.  that is
        necessary, and I imagine a required point for the
        practical...  
> 
> 
> 1.11 References
> ---------------

        don - good list, these belong in the main References section.
> 
> [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
> 

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