[Snort-sigs] SID 885
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.
Rule: WEB-CGI bash access
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.
/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.
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.
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.
It is possible for "bash" to be located anywhere, not just /<base
directories>/bin/bash. /sbin/bash for example
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...>
__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