Vulnerability Development mailing list archives
Re: CGI THREAT: Malicious data injection into Perl modules.
From: Sander <sanhi () dds nl>
Date: Fri, 25 Jan 2002 02:39:53 +0100
Onesphorf hass wrote:
Hi SecurityPeople! I have found a new method of CGI exploitation. I have found 3 bugs in commonly used CGIs. Since I am working with the authors now, proof of concept exploits will not be released before patches and updates are done. However, I have written a Security paper to share with theSecurity People.Feedback is wanted, I don't consider it done yet :) - Onesphorf
Very nice, but not exactly new. See: http://www.w3.org/Security/Faq/wwwsf4.html I think that Perl taint checking is a must when you use Perl and CGI. But it's true too many sites still use http://somecompany.com/cgi-bin/showme.pl?file=anyfileyouwanti wrote a one liner perl script that opens a remote shell abusing this construction.
( in case xterm isnt installed .... ) Its not new but it's something to be aware of. Did i mention modifying SQL where clauses this way yet? Sander
Author: 0nesphorf 0nesphorf () hotmail com CGI THREAT: Malicious data injection into Perl modules. 01. Introduction 02. Risk 03. Demonstration 04. Solution 05. Conclusion and Thanks 01. Introduction Most websites today gives the user the ability to give input, and return output based on the input. The ability to create dynamic web-pages is often thanks to CGI scripts. This makes for more interesting surfing (port surf's up, btw!), but as I will demonstrate in this article it can also help an attacker exploit your website. 02. Type of Threats The specific threat that I will discuss in this article is the ability to inject commands into Perl modules used by the CGI application itself. If we can trick the CGI script to add code into the module, chances are that we will be able to execute commands. 03. Examples (name of CGI script is taken away, since I haven't notified vendor yet) % nc localhost 80 GET /cgi-bin/xXXx.pl?user=0nesphorf;'touch /tmp/test' HTTP/1.0 HTTP/1.1 500 Internal Server Error Date: Wed, 23 Jan 2002 22:47:59 GMT Server: secret Connection: close Content-Type: text/html; charset=iso-8859-1 % ls /tmp/test % /tmp/test What I did was to include a command with backticks in a context that the CGI did not expect, which fooled it into writing the data into the CGI.pm module, which also made it execute the command due to the backticks which has a special meaning to Perl. 03.1. Other. This trick may or may not be used on CGIs written in a different language than Perl, but i have not tested that yet. Will research that in the future. 04. Solutions It is very important to keep in mind when writing CGI scripts, that the user using the CGI script has full control over the input, and is not at all limited by for example HTML forms. It is the CGI scripts job to make sure that the input is sane. 05. Conclusion and Thanks. I have demonstrated yet another method to fool CGI-scripts, by giving a sort of user-input which the script did not expect in that context. Let's learn from this, shall we. Thanks to Zenomorph for teaching me all I know about CGI exploitation, trough his technical papers. Written in Decemeber 2001 - Public not until January 2002 www.cgi-expertise.org - not yet up, be patient _____________________________________________________Hitta snörapporter... från 500 olika skidorter i Europapå http://se.snow.yahoo.com
Current thread:
- CGI THREAT: Malicious data injection into Perl modules. Onesphorf hass (Jan 24)
- Re: CGI THREAT: Malicious data injection into Perl modules. jon schatz (Jan 24)
- Re: CGI THREAT: Malicious data injection into Perl modules. Sander (Jan 25)