Well you cant really say thats all the vulnerabilities because it really depends on
the script and what it does. For example Matt Wrights WWWBoard script. Not vulnerable
to any of the attacks below but was found to have a vulnerability in the follow up
feature which allowed clobbering of the board. Also had the WWWAdmin script that went
with it had stored the passwd for the admin script in plain text in the passwd.txt
file.

 Some scripts also act as a 'proxy' allowing people to view other pages with them. I
have seen these all over the place and the scripts hostname,etc will appear in the
logs of the remote server.

These were just some thoughts that came to mind.

Franklin DeMatto wrote:

> I'm doing some research on Perl CGI vulnerabilities. Most Perl CGI's seems
> to have some weaknesses, and it's just a matter of manipulating them
> properly to make a proper exploit.
>
> By far, the biggest problem is weak (or even no) filtering of form
> fields. It only takes one line (s/\W+//g), yet this is rarely done properly.
>
> Other problems include:
>
> - Not filtering cookies.
> Very often, CGI's filter fields, but don't realize that cookies must also
> be filtered for evil characters.
> - Trusting the browser
> Not only can hidden fields be arbitrarily changed by anyone who at the
> least knows HTML, but so can cookies, HTTP_REFERER fields, and anything else.
> (Recently, after I informed the maker of a very popular CGI about a
> vulnerability in it, I was told "That's impossible!!! We check the
> HTTP_REFERER field!" Netcat, anyone? <I guess they don't teach that in CS
> school. . . > )
>
> The following are indirect problems:
>
> - Error messages too verbose
> While not a direct vulnerability, these often provide a lot of information
> on server structure, as well as filtering of evil characters. There is
> really no point in telling the user all about your server internals, so
> send these messages to the error log, not the stdout.
> - Cookie/hidden field predictability
> Again, this is not a direct vulnerability, but may allow for hijacking of
> other users accounts and the like. It can become a vulnerability if admin
> access can be gained this way.
> - Allowing creation of (semi-)arbitrary files on server
> Many CGI's can be used by attackers to create files on the server which
> they need in order to take advantage of other holes. Be restrictive in the
> type of files that your CGI creates - the more specific the format, the
> harder it will be for an attacker to make use of.
>
> My question for the list is as follows: What did I miss? Most of the real
> damage in my list can be eliminated with just a few lines of extra code -
> the major problem being that most CGI programmers don't know/care. But I'm
> sure there are some other problems, harder to exploit but harder for the
> programmer to avoid as well, that are out there. Anyone . . . ?

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]