Rule: 

--
Sid: 1367

-- 
Summary: 
This event is generated when execution of a "mail" command is attempted via HTTP.

-- 
Impact: 
Possible intelligence gathering. This may be an attempt to gain information using mail to access sensitive files on a webserver.

-- 
Detailed Information: 
This may be an attempt to gain intelligence from sensitive system files on a webserver. This rule generates an event when a "mail" command followed by a space is used over a plain-text (unencrypted) connection on one of the specified web ports to the target web server. 

The "mail" command is used to read and send email on UNIX systems. The rule looks for the "mail" command in the client to web server network traffic and does not indicate whether the command was actually successful. The presence of the "mail" command in the URL indicates that an attacker attempted to trick the web server into executing a system command in non-interactive mode i.e. without a valid shell session. 

This rule may also generate an event if it detects this command in an unencrypted HTTP tunneling connection to the server or a shell connection through an exploit of the web server.

-- 
Attack Scenarios: 
The attacker can make a standard HTTP request that contains the path to the "mail" command in the URI, which can then return requested files to an external destination.

--
Ease of Attack: 
Simple, no exploit software required

-- 
False Positives: 
This event may be generated if "mail" followed by a space is present in a URI. For example, http://www.foo.com/mail /file.html

--
False Negatives:
None Known

-- 
Corrective Action: 
Webservers should not be allowed to view or execute files and binaries outside of its designated web root or cgi-bin.

This command may also be requested on a command line should the attacker gain access to the machine. 

Non-essential binaries should be removed from a webserver once it is in production.

--
Contributors: 
Original rule writer unknown
Snort documentation contributed by Anton Chuvakin <http://www.chuvakin.org>
Sourcefire Research Team
Nigel Houghton <nigel.houghton@sourcefire.com>

-- 
Additional References:

--
