[Snort-sigs] SID 885

Brad Arlt arlt at ...417...
Thu Mar 7 19:32:10 EST 2002

# This is a template for submitting snort signature descriptions to
# the snort.org website
# Ensure that your descriptions are your own
# and not the work of others.  References in the rules themselves
# should be used for linking to other's work. 
# If you are unsure of some part of a rule, use that as a commentary
# and someone else perhaps will be able to fix it.
# $Id$

Rule:  WEB-CGI bash access

Sid: 885

Possible web server access of the Bourne Again Shell (bash)

Possiblity that shell commands can run on web server with the same
access permsissions as the web server.

Detailed Information:
/bin/bash is a common path (or path component) of the Bourne Again
Shell.  bash is an interactive command line interpreter that is in
common use on Unix, Linux, and *BSD style operating systems.  There
are also versions available for MacOS X, and Windows.  Any program you
can think of can usually be run from bash.

Attack Scenarios:
I imagine there are many.  Some that I can think of are:

 1) very poor input validation and input use in PHP (or CGI and other
	dynamic contents langauge); such as using a GET or POST
	variable in a popen call without checking its contents

 2) CGI variable input validation; some web servers like to perform
	sanity checks on POST and GET variables before they call CGI
	scripts.  Some web servers have done this in a manner that
	makes running commands in the input validation script really easy
 3) bash and other shells being in your CGI-bin directory; well in
	this case the web server was *configured* to run bash, but
	this is never desirable

In all cases bash can then be made to run other commands ("pkill
httpd" might be fun), and might be made to run interactively through
the web connection.

Ease of Attack:
Variable.  If bash is in your CGI-BIN directory, easy.  Most common
attack paths would require utilizing a bug in a scripting langauge, so
it depends on the bug in the PHP/CGI/ASP/JSP/Servlet scripts you are
running on that webserver.

False Positives:

The URL for one or more legitimate web page has "/bin/bash" in it.
"http://www.mydomain.comm/manpages/bin/bash" would be such a legit URL
that will trigger this rule.

False Negatives:
It is possible for "bash" to be located anywhere, not just /<base
directories>/bin/bash.  /sbin/bash for example

Corrective Action:

Ensure /bin/bash (and other shells) cannot be accessed via your web
server.  If you are using dynamic content in your web pages, ensure
that access to executables has been restricted to a directory of
trusted programs that are hard to abuse and cannot create a shell.
PHP, and Apache allow you to do this, I imagine others do as well.
And of course, validate all input before using it in PHP, CGI, and
other scripting languages.

Contributors:  Brad Arlt <arlt at ...417...>

Additional References:

   __o		Bradley Arlt				Security Team Lead
 _ \<_		arlt at ...417...			University Of Calgary
(_)/(_) 	http://pages.cpsc.ucalgary.ca/~arlt/	Computer Science

More information about the Snort-sigs mailing list