March 2011 Archives

Known hash replay attack

The use of client side password hashing in web application (such as may be on the rise. At least it appears that way to me as I have seen several deployments lately.

These hashing libraries usually promises to keep a user's password secure in non ssl environments.
One could argue that they perform the intended task. The problem with http traffic compared to https is that the traffic is obtainable by anyone else connected to the same network as the user (or the server). If an attacker obtains the hashed password string he or she can provide the hash to the server to authenticate as the user without knowing the users actual password.

This does mean that the user's plaintext password is safe until the hacker breaks it so for users who use the same password everywhere, there is a marginal protection when websites use hashed passwords. It's still a far cry from the relative security of submitting sensitive data over a SSL encrypted connection.

The March addition to Jason is, a script which iterates numeric values in passwords.
~/Jason$ ./ password1

You can grab a copy from the github project page:
Most of us think game over when we see a url that cointains a file reference, like http://localhost/basename.php?file=hello.php. Lets say that you were doing a penetration test where you are trying not to trigger any IDS alerts. How can you determine if the script filters the page variable using basename? Here are some simple steps that should go undetected.

Lets say that the scripts in this fictional url are as follows:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html xmlns="">
        <title>Basename poc file</title>
if (file_exists(basename($_GET['file']))) {
} else {
        echo "404 - File not found";
<?php echo "Hello World\n"; ?>
The first test we take is to determine what a negative response would be, we'll visit http://localhost/basename.php?file=hello.wisconsin, this nets us a custom 404 error. Now that we have a false contition the next test is simply http://localhost/basename.php?file=a/b/c/hello.php. If this gives us the same output as http://localhost/basename.php?file=hello.php the script is using basename (or a similar technique) to extrace the filename. If you get a negative response the script appears to be vulnerable to directory traversal/LFI/RFI. Better encode your next attack to avoid triggering the IDS.

Happy hacking!
(And yes, this is the February tutorial running late).
No Clean Feed - Stop Internet Censorship in Australia
Creative Commons License
This weblog is licensed under a Creative Commons License.