RE: LOGS: GIAC GCIA Version 3.5 Practical DetectDarinMarais

Lola,
A few comments -

1) You seem to stuck between covering two different snort alerts - the Invalid HTTP Version String and the targeted web app - formmail.  You spend time discussing the SLMail attack when this was not the targeted web app.  I would suggest that you remove the references to Seattle Lab Software SLMail Pro 2.0 exploit in your "Description of the Attack" section.  You jumped right into discussing this vulnerability based on the sid 2570 snort info - http://www.snort.org/snort-db/sid.html?sid=2570.  While this is good background info, you rule out the SLMail app as the target when you dump the payload and see that the attacker is targeting formmail instead.  Spend more time discussing the Invalid HTTP Version String issues.  

2) Couldn't the invalid version string be used for other purposes (I.E. - Web Server fingerprinting, etc...)?  Could it be a buggy http client (I.E. - unintentional http version string problem)?  

3) Speaking of formmail - weren't there any formmail Snort alerts???

4) The invalid http version string doesn't have anything to do with the formmail exploits that are discussed.  These attacks can be successful with valid http version strings. 

5) How about other correlations with the same User-Agent strings?  http://www.dshield.org/pipermail/intrusions/2003-January/006419.php.  Looks like this could be some buggy http client code that is not issuing the CLR after the HTTP version.

Most Respectfully, 
Ryan C. Barnett 
SANS: GCFA, GCIH, GCUX, GSEC 


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of lola marais
Sent: Monday, September 27, 2004 9:06 AM
To: [email protected]
Subject: [Intrusions] LOGS: GIAC GCIA Version 3.5 Practical
DetectDarinMarais


this a detect for 3.5. please could you take a look and post any questions

2. Detect Invalid HTTP Version String

1. Source of Trace:
The binary log file was downloaded from the GIAC practical logs. The binary 
contains some bad check sums. This is because the real IP addresses have 
been changed. This fact has been pointed out by many of my peers that have 
gone before me.
http://isc.sans.org/logs/Raw/2002.9.10
All of the files that have been captured from at the above location appear 
to contain only the packet that has triggered the alert. This means that 
when the raw data is replayed to the snort process, a TCP signature that 
would normally require a TCP established connection (TCP 3-whs) in order for 
the detection to trigger an alert would not be detected for the replay of 
that data. In order to overcome the problem, I have disabled the Stateful 
detection process in the snort.conf file to relax the requirements for a 
signature to trigger.
The following text has been taken directly from the snort.conf file at the 
workstation in order to show the lines that are removed.
# stream4: stateful inspection/stream reassembly for Snort
#----------------------------------------------------------------------
# Use in concert with the -z [all|est] command line switch to defeat 
stick/snot
# against TCP rules.  Also performs full TCP stream reassembly, stateful
# inspection of TCP streams, etc.  Can statefully detect various portscan
# types, fingerprinting, ECN, etc.

# preprocessor stream4: disable_evasion_alerts
# preprocessor stream4_reassemble
The # placed before the command will cause the snort process to skip that 
line when the configuration file is called from the snort process.
The following text shows the snort command and the options that where used 
in order to generate the alerts.
# snort -c ./rules/snort.conf -l ./detect2/log1/ -r 
./GIAC_PRAC/GiacLogs/2002.9.10 -k none -dyev > ./detect2/log1/verbose -q -A 
fast -h32.245.0.0/16

USAGE: snort [-options]
Options:
        -A        Set alert mode: fast, full, console, or none(alert file 
alerts only)
                  "unsock" enables UNIX socket logging (experimental).
        -c <rules> Use Rules File <rules>
        -d        Dump the Application Layer
        -e        Display the second layer header info
        -h <hn>   Home network = <hn>
        -k <mode> Checksum mode (all,noip,notcp,noudp,noicmp,none)
        -l <ld>   Log to directory <ld>
        -q        Quiet. Don't show banner and status report
        -r <tf>   Read and process tcpdump file <tf>
        -v        Be verbose
        -y        Include year in timestamp in the alert and log files

After this command was executed, an alert file was created in the specified 
log directory. The file was visually scanned for the detects that where 
created and then snortsnarf.pl perl script was run to produce an HTTP file 
for easier examination of those alerts.
This alert file contained the following three interesting alert entries.

# grep "Invalid HTTP Version String" ./detect2/log1/alert
10/10/02-06:19:08.026507  [**] [1:2570:6] WEB-MISC Invalid HTTP Version 
String [**] [Classification: Detection of a non-standard protocol or event] 
[Priority: 2] {TCP} 172.132.195.251:1813 -> 32.245.166.119:80
10/10/02-20:08:36.796507  [**] [1:2570:6] WEB-MISC Invalid HTTP Version 
String [**] [Classification: Detection of a non-standard protocol or event] 
[Priority: 2] {TCP} 4.63.173.119:4524 -> 32.245.166.119:80
10/10/02-23:42:12.086507  [**] [1:2570:6] WEB-MISC Invalid HTTP Version 
String [**] [Classification: Detection of a non-standard protocol or event] 
[Priority: 2] {TCP} 208.63.245.166:2989 -> 32.245.166.119:80
10/11/02-01:48:10.976507  [**] [1:2570:6] WEB-MISC Invalid HTTP Version 
String [**] [Classification: Detection of a non-standard protocol or event] 
[Priority: 2] {TCP} 4.65.196.108:3914 -> 32.245.166.119:80

The following information was deduced from the http output and the text 
alert file.
Sources triggering this attack signature
208.63.245.166
4.65.196.108
4.63.173.119
172.132.195.251

Destinations receiving this attack signature
32.245.166.119
In order to discover the network, I have used a series of tcpdump commands. 
Most of the tcpdump commands that I have used have been adapted from the 
GIAC Certified Intrusion Analyst (GCIA) paper by Peter H. Storm [37].
I would like to thank Mr. Storm for giving me the insight for these 
commands. Mr. Storm uses a series of tcpdump commands to discover the 
network. I have used similar commands to discover the network that I have 
been challenged with.
All of the packets displayed at the console have the following structure.
tcpdump -nner /GIAC_PRAC/GiacLogs/2002.9.10 -c 1
02:00:03.876507 0:3:e3:d9:26:c0 0:0:c:4:b2:33 0800 60: 255.255.255.255.31337 
 > 32.245.186.142.515: R 0:3(3) ack 0 win 0
This means that the awk variables for the TCP packet are as follows;
Time
Source MAC address
Destination MAC address
Ethernet frame type
packet length
Source IP address and port
Destination IP address and port
flags
Relative Sequence number (nbytes)
Etc.
I have used the command below to discover all of the hardware addresses in 
the networks. The command lets us know that there are only two devices on 
the local segment. Both of these devices happen to be manufactured by Cisco 
systems. I used the tool provided by the IEEE in order to determine the 
manufacture of the NIC. [38]
# tcpdump -nner 2002.9.10 | awk '{print $2}' |sort -u
0:0:c:4:b2:33
0:3:e3:d9:26:c0
# tcpdump -nner 2002.9.10 | awk '{print $3}' |sort -u
0:0:c:4:b2:33
0:3:e3:d9:26:c0
00-00-0C (hex) 	CISCO SYSTEMS, INC. 170 WEST TASMAN DRIVE SAN JOSE CA 95134
00000C (base 16) 	CISCO SYSTEMS, INC.
00-03-E3 (hex) 	Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA 95134
0003E3 (base 16) 	Cisco Systems, Inc.

I used the following command to determine the IP addresses that have 
originated from the NIC address 0:0:c:4:b2:33
# tcpdump -nner 2002.9.10 "ether src 0:0:c:4:b2:33" | awk '{print $6}' |awk 
-F \. '{print $1"."$2"."$3"."$4}' |sort -u
32.245.166.119
32.245.166.236
I used the following command to determine the source IP addresses of the 
packets originating from the NIC 0:3:e3:d9:26:c0. The output of the command 
has been truncated in order to conserve space.
# tcpdump -nner 2002.9.10 "ether src 0:3:e3:d9:26:c0" | awk '{print $6}' 
|awk -F \. '{print $1"."$2"."$3"."$4}' |sort -u
12.111.47.194
12.145.180.2
130.49.189.232
snip ...
80.5.120.28
80.5.153.244
80.6.250.44
80.67.66.40
I used the following command to determine the destination IP addresses of 
the packets originating from the NIC 0:3:e3:d9:26:c0
# tcpdump -nner 2002.9.10 ether src 0:3:e3:d9:26:c0 | awk '{print $8}' |awk 
-F \. '{print $1"."$2"."$3"."$4}' |sort -u
32.245.113.30
32.245.113.38
snip ...
32.245.88.213
32.245.99.128
# tcpdump -nner 2002.9.10 ether src 0:3:e3:d9:26:c0 | awk '{print $8}' |awk 
-F \. '{print $1"."$2"."$3"."$4}' |sort -u |wc -l
     82
I used the following command to determine the destination IP addresses of 
the packets originating from the NIC 0:0:c:4:b2:33
# tcpdump -nner 2002.9.10 ether src 0:0:c:4:b2:33 | awk '{print $8}' |awk -F 
\. '{print $1"."$2"."$3"."$4}' |sort -u
12.213.27.68
12.219.102.151
12.219.135.64
snip ...
80.35.219.162
81.65.129.9
81.96.106.54
# tcpdump -nner 2002.9.10 ether src 0:0:c:4:b2:33 | awk '{print $8}' |awk -F 
\. '{print $1"."$2"."$3"."$4}' |sort -u |wc -l
    423
>From the output of these commands we are able to draw the network diagram. 
The network according to the data looks as follows.

2. Detect was generated by:
The signature that alerted us and has generated the event in the alert file 
was following snort signature.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC 
Invalid HTTP Version String"; flow:to_server,established; content:"HTTP/"; 
isdataat:6,relative; content:!"|0A|"; within:5; reference:bugtraq,9809; 
reference:nessus,11593; classtype:non-standard-protocol; sid:2570; rev:6;)
The above signature will look for:
TCP protocol coming from any external IP address. This is a variable and can 
be defined in the snort.conf file. My snort configuration file specifies 
any. This source IP address can come from any TCP source port.
The following has been extracted from the snort.conf file.
# Set up the external network addresses as well.  A good start may be "any"
var EXTERNAL_NET any
That is connected and established (has completed a TCP 3-whs) to any IP 
address that is defined as an HTTP server on any defined HTTP port. The 
following two parameters are variables that can be changed in the snort.conf 
file during the configuration of snort in order to make the detection 
process more accurate.
1.$HTTP_SERVERS
2.$HTTP_PORTS
The signature will look for the content HTTP/ in the payload of the packet 
and then verify that there are at least 6 bytes after the end of the content 
string. It will verify that there is not a newline character within 5 bytes 
of the end of the content HTTP/.
The follow description was taken directly from the snort user guide [39] at 
the web site in order to help explain the parameter isdataat.
"3.5.9 isdataat
Verify that the payload has data at a specified location, optionally looking 
for data relative to the end of the previous content match.
3.5.9.1 Format
isdataat:<int>[,relative];
3.5.9.2 Example
alert tcp any any -> any 111 (content:"PASS"; isdataat:50,relative; 
content:!"|0a|"; distance:0;)

This rule looks for the string PASS exists in the packet, and then verifies 
there is at least 50 bytes after the end of the string PASS, and then 
verifies that there is not a newline character within 50 bytes of the end of 
the PASS string."

3.Probability the source address was spoofed:
Since the signature requires a TCP established connection, there is very 
little chance that the source address is spoofed. Although when I search the 
file for other packets that belong to this connection I was unable to find 
any, there must have been a completed connection. IMHO, the snort process 
has only captured the trigger packet.

4.Description of attack:
It has been said that upon detecting the signature WEB-MISC Invalid HTTP 
Version String the attacker could be attempting to exploit a vulnerability 
that exists in a web server running Seattle Lab Software SLMail Pro 2.0 to 
2.0.9.
This vulnerability was outlined in the discussion section of these URL
http://www.securityfocus.com/bid/9809/discussion/
http://xforce.iss.net/xforce/xfdb/15399
http://secunia.com/advisories/11048/
The discussion explains that there are two vulnerabilities that exist in 
SLMail application. These vulnerabilities where released on 2004-03-05 and 
exist in all versions prior to version 2.0.9
A buffer overflow could cause a remote attacker to execute code on the 
victim(tm)s hosts. This is achieved by sending a crafted HTTP string with an 
overly long HTTP sub-version.
http://www.faqs.org/rfcs/rfc2616.html
3.1 HTTP Version
   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
   of the protocol. The protocol versioning policy is intended to allow
   the sender to indicate the format of a message and its capacity for
   understanding further HTTP communication.
The second buffer overflow exists in three of the ISAPI Extensions files 
included with the web mail component. These files will allow a buffer 
overflow to occur and consequently the execution of code that would be run 
with the same user privileges of the web server process.
1.user.dll
2.loadpageadmin.dll
3.loadpageuser.dll
However judging by the string that has been received; I am more incline to 
believe that the attacker was trying to exploit the vulnerability that 
exists in some versions of formmail perl script.
In order to determine if the signature has trigger for the correct reasons, 
tcpdump was used to view the hexadecimal values in the payload of the 
packet. It is also interesting to point out at this time that the remote 
device has a TimeToLive (TTL) of 115. Passive fingerprinting techniques [40] 
tell us that it is very possible that the remote device is a windows 
operating system
# tcpdump -nnvttttXr ./GIAC_PRAC/GiacLogs/2002.9.10 port 1813
10/10/2002 04:19:08.026507 172.132.195.251.1813 > 32.245.166.119.80: P [bad 
tcp cksum e41!] 3263194808:3263195121(313) ack 3337717011 win 5840 (DF) (ttl 
115, id 23608, len 353, bad cksum 5d5a!)
0x0000   4500 0161 5c38 4000 7306 5d5a ac84 c3fb        E..a\[email protected].]Z....
0x0010   20f5 a677 0715 0050 c280 66b8 c6f1 8513        ...w...P..f.....
0x0020   5018 16d0 aa29 0000 4745 5420 2f63 6769        P....)..GET./cgi
0x0030   2d62 696e 2f46 6f72 6d4d 6169 6c2e 706c        -bin/FormMail.pl
0x0040   3f65 6d61 696c 3d53 6b61 6e6e 6564 4061        ?email=Skanned@a
0x0050   6f6c 2e63 6f6d 2673 7562 6a65 6374 3d77        ol.com&subject=w
0x0060   7777 2e58 5858 5858 5858 582f 6367 692d        ww.XXXXXXXX/cgi-
0x0070   6269 6e2f 466f 726d 4d61 696c 2e70 6c26        bin/FormMail.pl&
0x0080   7265 6369 7069 656e 743d 7365 6e64 3234        recipient=send24
0x0090   3532 4061 6f6c 2e63 6f6d 266d 7367 3d6d        [email protected]&msg=m
0x00a0   6953 6c65 6454 4d20 2532 4563 6f6d 266d        iSledTM.%2Ecom&m
0x00b0   7367 3d6d 6953 6c65 6454 4d20 4854 5450        sg=miSledTM.HTTP
0x00c0   2f31 2e31 436f 6e74 656e 742d 5479 7065        /1.1Content-Type
0x00d0   3a20 6170 706c 6963 6174 696f 6e2f 782d        :.application/x-
0x00e0   7777 772d 666f 726d 2d75 726c 656e 636f        www-form-urlenco
0x00f0   6465 640d 0a55 7365 722d 4167 656e 743a        ded..User-Agent:
0x0100   2047 6f7a 696c 6c61 2f34 2e30 2028 636f        .Gozilla/4.0.(co
0x0110   6d70 6174 6962 6c65 3b20 4d53 4945 2035        mpatible;.MSIE.5
0x0120   2e35 3b20 7769 6e64 6f77 7320 3230 3030        .5;.windows.2000
0x0130   290d 0a48 6f73 743a 2077 7777 2e58 5858        )..Host:.www.XXX
0x0140   5858 5858 580d 0a43 6f6e 6e65 6374 696f        XXXXX..Connectio
0x0150   6e3a 204b 6565 702d 416c 6976 650d 0a0d        n:.Keep-Alive...
0x0160   0a                                             .
In order to view the ASCII string in an easier reading format, the command 
tcpflow was used to extract the string. The text below shows the packet that 
is currently analysed as well as two other alerts that have occurred in the 
same raw different source IP addresses.
# tcpflow -cr ./GIAC_PRAC/GiacLogs/2002.9.10 port 1813
172.132.195.251.01813-032.245.166.119.00080: GET 
/cgi-bin/[email protected]&subject=www.XXXXXXXX/cgi-bin/FormMail.pl&[email protected]&msg=miSledTM 
%2Ecom&msg=miSledTM HTTP/1.1Content-Type: application/x-www-form-urlencoded
User-Agent: Gozilla/4.0 (compatible; MSIE 5.5; windows 2000)
Host: www.XXXXXXXX
Connection: Keep-Alive

# tcpflow  -cr ./GIAC_PRAC/GiacLogs/2002.9.10 port 4524
004.063.173.119.04524-032.245.166.119.00080: GET 
/cgi-bin/[email protected]&subject=www.XXXXXXXX/cgi-bin/formmail.pl&[email protected]&msg=w00t 
0aol%2Ecom&msg=w00t HTTP/1.1Content-Type: application/x-www-form-urlencoded
User-Agent: Gozilla/4.0 (compatible; MSIE 5.5; windows 2000)
Host: www.XXXXXXXX
Connection: Keep-Alive

# tcpflow  -cr ./GIAC_PRAC/GiacLogs/2002.9.10 port 2989
208.063.245.166.02989-032.245.166.119.00080: GET 
/cgi-bin/[email protected]&subject=www.XXXXXXXX/cgi-bin/FormMail.pl&[email protected]&msg=miSledTM 
%2Ecom&msg=miSledTM HTTP/1.1Content-Type: application/x-www-form-urlencoded
User-Agent: Gozilla/4.0 (compatible; MSIE 5.5; windows 2000)
Host: www.XXXXXXXX
Connection: Keep-Alive
The source IP address that was captured in this detect actually triggered 
two different signature events.  The packet in the raw data file that was 
captured on 10/10/2002 at 04:19:08 from the IP address 172.132.195.251 
according to the binary file has also triggered an event for WEB-CGI 
formmail access
This signature documented in the text directly below has been written to 
capture events when an external address is trying to get access to the 
formmail script file. The file is normally is located in one of the 
subdirectories of a UNIX web server.
The consequences of gain access to the formmail perl script prior to version 
1.6 are that it would allow the attacker to execute commands at the web 
server with the privileges of the web server process. That signature had the 
following structure.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI 
formmail access"; flow:to_server,established; uricontent:"/formmail"; 
nocase; reference:arachnids,226; reference:bugtraq,1187; 
reference:bugtraq,2079; reference:cve,1999-0172; reference:cve,2000-0411; 
reference:nessus,10076; reference:nessus,10782; 
classtype:web-application-activity; sid:884; rev:14;)
A description of this signature could be found at the following URL 
location.
http://www.snort.org/snort-db/sid.html?id=884

5.Attack mechanism:
The SLMail attack would normally try to overflow the buffer on the web port 
of a SLMail server and consequently the attacker would be able to execute 
which ever program that he or she felt like. The character string that 
however appear beyond the HTTP/ content string look as if they are part of a 
banner to inform the web server.

The RFC was consulted in order to determine what the attacker was trying to 
achieve by including the browser banner beyond the http sub-field.
The RFC used was http://www.faqs.org/rfcs/rfc2616.html
The following information was extracted from the RFC.

2.2 Basic Rules
   The following rules are used throughout this specification to
   describe basic parsing constructs. The US-ASCII coded character set
   is defined by ANSI X3.4-1986 [21].
Snip ..
       CR             = <US-ASCII CR, carriage return (13)>
       LF             = <US-ASCII LF, linefeed (10)>
Snip ..
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
   protocol elements except the entity-body (see appendix 19.3 for
   tolerant applications). The end-of-line marker within an entity-body
   is defined by its associated media type, as described in section 3.7.

       CRLF           = CR LF

The arguments that appear after the content HTTP/1.1 are not valid in the 
HTTP request-line since there is no preceding hexadecimal 0a = decimal 10 
which is the equivalent of a LF. That makes this HTTP get string invalid. It 
could be that the attacker was trying to craft a packet to hide the banner 
of the real browser by hard coding the parameters at the end of the HTTP get 
string.
This is strange and is not very common but does not appear to be malicious 
from the SLMail vulnerability point of view.

The payload content indicates that it is defiantly an attempt to scan for 
vulnerable formmail scripts and this should be cause for concern. The file 
capture was searched using tcpdump for a response to this packet with no 
joy. This is stimulus packet but the web server does not seam to have 
offered any response to the request.

Matt Wright explains the Formmail attack
"The Formmail package has become a favorite tool of spammers.
Formmail allows a website to email form submissions to an email account. If 
left unpatched a malicious user can send spam simply by including the list 
of target email addresses in an HTTP request to Formmail. This behavior 
makes tracking down the origin of the spam difficult because the only place 
the spammers IP address is saved is in the Web logs of the affected site.
FormMail is a widely-used web-based e-mail gateway, which allows form-based 
input to be emailed to a specified user.
When the form is submitted, the commands will be executed on the host, with 
the privileges of the web server process. This might be leveraged by the 
attacker to gain local access to the host. [41]"

6.Correlations:
The following links where found for the SLMail attack by searching the 
Internet. The links below don(tm)t show any time where the vulnerability has 
been used in an exploit against a SLMail server.
http://www.securityfocus.com/bid/9809
http://cgi.nessus.org/plugins/dump.php3?id=11593
http://marc.theaimsgroup.com/?l=bugtraq&m=105232506011335&w=2
There are many correlations for the formmail.pl. This attack is used by lots 
of spammers. Formmail correlations can be found at URL:
http://cgi.nessus.org/cve.php3?cve=CAN-2000-0411
The remote IP address in this attack was examined against the Dshield 
reports. It should be noted that this attack did occur in 2002 according to 
the time in the tcpdump packet but the IP address was not list as previously 
reported.
IP Address: 172.132.195.251
HostName: AC84C3FB.ipt.aol.com
DShield Profile: Country:   US
Contact E-mail: [email protected]
AS Number: 1668
Total Records against IP:  not processed
Number of targets:  select update below
Date Range: to
request contact update
Update Summary

Whois:
OrgName:    America Online
OrgID:      AOL
Address:    22000 AOL Way
City:       Dulles
StateProv:  VA
PostalCode: 20166
Country:    US
http://www.dshield.org/ipinfo.php?SANSDSHIELD=72cdedcfaad2851ed63a3925db648883&ip=172.132.195.251&Submit=Submit
The formmail.pl attack is extremely well analysed in Detect #2: Web-CGI 
formmail access of the GCIA practical paper submitted by Barbara Morgan. 
This complete document can be found at the following URL location on the 
Internet.
http://www.giac.org/practical/GCIA/Barbara_Morgan_GCIA.doc

7. Evidence of active targeting:
This attack is received from two other source IP addresses on the same day. 
The web server on this network has been targeted. The attack did not appear 
in the capture file for any other destination. It can only be assumed that 
the web server has been targeted. It seams impossible that if the attack 
where a scan for vulnerably systems on this network that only one 
destination IP address has been scanned.

8. Severity:
Severity = (criticality + lethality) - (system countermeasures + network 
countermeasures)
Critically: Nothing is really known about the local web server but since the 
server is located on the internet it can only be assumed that it is used for 
some form of business and even if it is not, one should guard against 
attacks on this public server. I am going to assume the worst and say that 
it is a business web server.
Lethality: If the server where running a vulnerable version of SLMail the 
attack would have been unsuccessful. If the web server is using a vulnerable 
version of the popular the gateway script formmail.pl to translate 
information from the web pages for sending via the email server, the attack 
would have mailed the spammer with information regarding the web server 
location. The web server could then be used in an attack later on. The email 
severs could be used as a spam gateway if vulnerably script is detected by 
the spammer.
System countermeasures: Nothing can be determined regarding the patch 
program for this web server. The TTL in the response packets tell us that it 
is very possible that the operating system is UNIX.
Network countermeasures: The network firewall would have permitted this 
attack to pass to the web server. There was no response from the web server 
for this session but there have been responses for others sessions.  The 
packets below show those responses to other IP addresses external to the 
network.
# tcpdump -nnvqr ./GIAC_PRAC/GiacLogs/2002.9.10 "src host 32.245.166.119 and 
port 80"
02:12:07.466507 32.245.166.119.80 > 212.62.35.225.1168: tcp 536 (DF) (ttl 
63, id 672, len 576, bad cksum 6274!)
09:39:24.466507 32.245.166.119.80 > 213.202.69.145.32776: tcp 581 (DF) (ttl 
63, id 19980, len 621, bad cksum f39e!)
09:39:28.756507 32.245.166.119.80 > 213.202.69.145.32776: tcp 554 (DF) (ttl 
63, id 19999, len 594, bad cksum f3a6!)
10:00:15.336507 32.245.166.119.80 > 213.202.69.145.32855: tcp 581 (DF) (ttl 
63, id 30869, len 621, bad cksum c915!)
10:57:56.596507 32.245.166.119.80 > 195.29.132.172.32777: tcp 563 (DF) (ttl 
63, id 13339, len 603, bad cksum e133!)
10:58:04.336507 32.245.166.119.80 > 195.29.132.172.32777: tcp 551 (DF) (ttl 
63, id 13340, len 591, bad cksum e13e!)
There is an NIDS to detect this attack, so the network staff will be 
informed of the possibility of an attack on the mail server if the alerts 
are properly analysed and the NIDS is properly tuned.

(4 + 4) - (1 + 3) = 4

In conclusion of this attack and from all of the evidence that has been 
collected it could be said that on the 10/10/2002 at 04:19:08 the device 
located at IP address 172.132.195.251 and others tried to exploit 
vulnerability in the perl script called formmail.pl on the web server 
service running at 32.245.166.119. Whilst attempting this exploit 
vulnerability in this script, it has triggered the event Invalid HTTP 
Version String in parallel.

9. Defensive recommendation:
Check the device running at IP address 32.245.166.119 is not running SLMail. 
If it is that apply the recommended Security Patch, which is currently 
version 2.0.14 and can be found at 
http://www.slmail.com/Products/SLMailPro/Utilities.asp
More especially, check if the device at this location is is running a 
vulnerable version of formmail.pl. If it is then the device should be 
patched immediately by upgrading the script.

10. Multiple choice test questions:
When writing snort signatures for content matching, the parameter "isdataat" 
is used to indicate to the snort process to
a) Hide all email addresses used in the in the signature description.
b) Look for defined conditions, x bytes beyond the previous content string 
match
c) Look for defined conditions, x bytes before the previous content string 
match
answer = b

_________________________________________________________________
Go beyond Hotmail with MSN Hotmail Plus! http://join.msn.com/?pgmarket=en-xe

_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions
_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions