Exploiting MD5 vulnerability in this PHP form?

Question

I've been practicing in security-related topics and I came upon this problem which I don't understand at all. You receive a form with one input named pass, and this is the code you need to bypass:

<?php
error_reporting(0);
session_save_path('/home/mawekl/sessions/');
session_start();
echo '<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>';
echo 'This task is as hard to beat as the castle which you can see on the bottom.<br>';
echo '<pre>';
include('./ascii.txt');
echo '</pre><br>';

$_SESSION['admin_level']=1;

if (!isset($_POST['pass']) || md5($_POST['pass'])!='castle')
{
    echo '<b>Wrong or empty password.</b><br>';
    $_SESSION['admin_level']=0;
}

If it enters the final if statement, you lose (Need to make it so $_SESSION['admin_level'] stays at 1).

Any help is appreciated, thanks!

Clarification:

I can't edit the code I posted. It's a challenge. All I can do is send a password through an input whose name is "pass". Yes, I know md5 is supposed to return a 32-char long string. That's the challenge.

Answer 1

Try sending a HEAD request.

I'm assuming that with ascii.txt included, the output of the script is just over a nice number like 4096 bytes, a common output_buffering value. Once the script has written output_buffering bytes, it needs to flush the output buffer before continuing.

Normally this works fine and the script continues, but if the request type is HEAD, there's nowhere for the output to go and execution stops, hopefully in the middle of the "wrong password" message which means admin_level is never set back to 0.

If ascii.txt is a file you can control, you'll have to tweak the size so the numbers work out to exceed output_buffering while writing the "wrong password" message.

Here's a paper on this technique. It might not always be applicable based on the PHP version/config, but the last example in the paper is so similar to this problem that I'd expect it to be the intended solution.

Answer 2

The security flaw isn't in MD5 in this case. And the idea isn't to get if (!isset($_POST['pass']) || md5($_POST['pass'])!='castle') to evaluate in favor of the hacker. The vulnerability appears when you crash the script. The admin privileges are not conditional. No matter what the user gets their permission elevated by setting 1 to $_SESSION['admin_level']. PHP is procedural. So if you can error out the following IF statement the permission is not only set but it remains persistent. This is now available to the rest of the program as it is stored in the session. Even if the script crashes and errors out. So if the IF statement only exists during a login the attacker can visit all the other restricted scripts as an admin_level set to 1.

So timeline of events:

• Attacker puts bad data or an overflow of data in the POST request
• Script runs
• Script gives admin_level of 1 which is stored in the session
• Script bombs at evaluation
• Attacker goes to another page/script that looks to see if $_SESSION['admin_level'] is 1

This could of been avoided if the script made the session value part of the IF statement:

if (!isset($_POST['pass']) || md5($_POST['pass'])!='castle')
{
    echo '<b>Wrong or empty password.</b><br>';
    $_SESSION['admin_level']=0;
} else {
    $_SESSION['admin_level']=1;
}

However there is still a lot more that should be done to secure this code.

Answer 3

I've seen a similar challenge somewhere. Try to send something like 'QNKCDZO' as input. md5('QNKCDZO') is '0e830400451993494058024219903391' (note the 0e prefix in the hash indicating scientific notation of a number) and since the code uses the != operator (instead of the type sensitive !==) PHP (older versions only?) will actually cast it to a number before comparing. Obviously, both will then evaluate to 0 and you win.

Edit: ruakh is right. This doesn't quite work, because both the hash and the string 'castle' would need to look like a number to PHP for the cast to happen.

Answer 4

I haven't been able to test in PHP 5.5.9, and what I'm going to propose doesn't work on my PHP 5.6.22 (but I might have made some silly mistake).

The only workaround I can fathom is if MD5 returns something that is treated as a number. I've Googled and found something which seems germane.

Answer 5

I see that you accepted gabedwrds solution (which is excellent, by the way), but I wanted to post one potential solution that I have used in the past when doing some interesting pentesting practice. (I am by no means an expert in that field, but I am sometimes a hobbiest.)

If you will notice, the script never sets any policy for handling a user abort. By default (unless configured otherwise in the PHP ini), if a user aborts their connection while a page is loading, the PHP script exits immediately and stops all processing. Because of this, if you time your connection just right, you could abort your connection between the $_SESSION['admin_level']=1; and the evaluation of the conditional, thus forcing the server to exit the script immediately, without finish the conditional evaluation that would cause admin_level to be reset to zero.

Of course, this is entirely dependent on the PHP configuration not having ignore_user_abort=1. So if that is set to continue even if a user aborts, the privileges will still be reset.

To increase your window of opportunity to use this exploit, you could increase the size of your pass payload/variable data. md5 has to hash in chunks, so by increasing the size of the pass data, you will cause the md5 function to spend more time computing the hash, thus giving a large gap of time that you have to abort the connection.

Answer 6

Similar to what others have said, PHP has a max memory size. If you put in POST data that was JUST big enough to use ALMOST all of PHP's memory up, then it could conceivably crash when it gets exactly to this line if it ran out of memory:

echo 'Wrong or empty password.'

This is built on three principles:

1) When sessions are enabled, PHP doesn't flush the output, instead storing it all in RAM until the page is done rendering.

2) PHP has a maximum RAM size allocated for each requests and, when reached, crashes your script.

3) When new lines are written, it uses more RAM, using up your remaining RAM.

Given the above facts, if you put more HTTP POST data in your HTTP request (ex: $_POST["data"]="largestring") then you could conceivably trigger an out of memory error before $_SESSION["admin_level"]=0 is run.

In a real-life scenario, this is highly unlikely because PHP also has a maximum POST body size, maximum header size, and whatever server container is hosting it (nginx, apache, etc) typically also has max limits. You would probably hit all of these max limits, but if configured poorly, its possible you could get $_SESSION["admin_level"]=1 effectively becoming an admin when going to any other pages on the website using this method.

Update: Another similar method would be to put a big password so that the md5() function fails while processing it or something, again causing it to crash because it runs out of memory. Depends on how md5() internally works. Its probably making a COPY of the $_POST["pass"] field, so if $_POST["pass"] was gigantic, then it could be very easy to cause this copy to be what uses up all the RAM and makes it crash.

Answer 7

Assuming you can modify the ./ascii.txt, I would put this text inside:

<?php

override_function('md5', '$a', 'return "castle";');

And that should work.