Re: Fail Open Authentication and Parameter Injection

["Jeff Williams @ Aspect" <jeff.williams () aspectsecurity com>]

Great example!  We see bizarre stuff like this all the time.  The
developer may have had a reason (like only the first 8 chaacters of the
password are significant or something), but the implementation came out
broken.  The reason is broken too, but that's a different issue.

This is a perfect example of why security code review is so important.
There are a million ways to mess up the implementation of a security
feature, or to implement some non-security feature in a way that
introduces a vulnerability.  There's just no way to find all these
problems by penetration testing.  You might find one or two, but you'll
never get anywhere close to finding them all.

You just can't beat actually looking at the code.  You'll need to work out
a process for reviewing the code and a standard to review against.  You
also need to make sure you've found ALL the code.  But a code review will
give you some real assurance that you've covered everything...in a way
that penetration testing never can.

--Jeff

Jeff Williams
jeff.williams () aspectsecurity com
Aspect Security, Inc.
http://www.aspectsecurity.com



----- Original Message -----
From: Dawes, Rogan (ZA - Johannesburg)
To: 'Indian Tiger' ; webappsec () securityfocus com
Sent: Tuesday, March 25, 2003 2:09 AM
Subject: RE: Fail Open Authentication and Parameter Injection


I'll give a real world case which I found.

A web app was using the following comparison for chacking passwords :

and password like "$password%";

Don't ask me why they thought this was a good idea, I just know that they
did it.

Even providing the first character of the password would have been
sufficient, but I chanced upon it when the client sent me a wrapped url
with
the password parameter on the next line:

E.g. please start here: http://www.blah.com/mylogin.asp?username=myname
&password=password

When I clicked on the URL (intending to paste the rest once the browser
had
started up), I was logged in!

Bizarre, but true!

An example of parameter injection:

A web app that allows you to execute a traceroute from the web server to
an
arbitrary destination.

Takes an IP address as input, and executes something like:

/bin/sh -c "traceroute $ip > file"

Then reads file in, and includes it in the web page it displays to you.

Provide something like:

192.168.1.1 > /dev/null ; cat /etc/shadow

And with any luck, you will get the shadow file from the server instead of
the traceroute output.

Rogan

-----Original Message-----
From: Indian Tiger [mailto:indiantiger () mailandnews com]
Sent: 21 February 2002 08:44 PM
To: webappsec () securityfocus com
Subject: Fail Open Authentication and Parameter Injection


Hi,

I am learning Web Application Security Penetration Testing using WebGoat.
I
have some queries on this.

Fail Open Authentication
WebGoat's step 3 says: "Try removing password parameter with Achilles. "
How it's possible. Is there any chance when server don't even check
password
if we remove password parameter.

Parameter Injection
What could be the scenario where a site is vulnerable to Parameter
Injections.
I have given a thought on this but not able to think how exactly it works
in
practice.
Webgoat has given an example like this 'blah & netstat -a & ipconfig'
But where a developer will be allowing to insert such values.

Any help on this would be highly appriciated.


Thanking You.
Sincerely,

Indian Tiger, CISSP