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 the >Security 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=anyfileyouwant i 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 > 0nesphorfat_private > 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 Europa >på http://se.snow.yahoo.com >
This archive was generated by hypermail 2b30 : Fri Jan 25 2002 - 09:29:11 PST