Exploiting vulnerabilites in php's fopen

Question

I am taking a cyber security class and for an assignment we have to exploit a specific php file and gain some sort of access to the server that it is hosted on. I can set my own $email and $password variables as they are set with $_POST. I believe the only piece of code I can exploit is this.

$email = $_POST['email']
$password = $_POST['password']
....    
$accountfile = "./acounts/" . $email

if(!file_exists($accountfile)){
  diefooter("unknown email address or password")
}
$fh = fopen($accountfile, "r")
if(!$fh){
  diefooter("Cannot open file $accountfile.");
}
$last = fgets($fh);
$first = fgets($fh);
$pass = fgets($fh);

if(strcmp($pass,$password)!=0){
  diefooter("wrong email or password.")
}

I know that there are vulnerabilities built into the fopen() function and that I can gain access to the shell with the correct input.

filePath = "/var/ctf/music-copyright/html/cgi-bin/login.php"
shellKode = "exploit@gmail.com\0;echo shell_exec("+'"cat '+filePath+'");'
# payload = {'email':shellKode, 'password':'test'}
testPayload = {'email':'exploit@gmail.com','password':'a'}
r = requests.post(url, data = testPayload)
print(r.text)

I can enter an email into the system but the format is verified before saving. At this point I'm a little lost and not sure what else I can be doing. fopen() is the only function in the file I think that can be exploited and I can't think of another place where an exploit may be.

Answer 1

I think they're referring to the CRLF vulnerability.

In your sample exploit code, you're passing some php code, but that's not what you would do.

The goal is to make fopen open a file from the internet. If the $email variable contains two strings separated by a CRLF, you can have fopen() visit an external website there where it's not supposed to.

All depending on what happens with the $fh file descriptor after, it will determine how you will take advantage of that.

Here's a link I found on that vulnerability: http://www.securiteam.com/unixfocus/5OP0C0A8AC.html

EDIT after you posted more code:

We're starting with that you can force $password to the value you want.

So the name of the game is forcing $pass to the value you want, such that strcmp returns true, and you get logged in without knowing any password.

$pass is controlled in that last statement $pass = fgets($fh)

And if you use the CRLF vulnerability to point fopen to open a URL that you host, e.g. http://your.ip.address/your-file, and inside that file, you set the same data as you set in $password. And that should allow you to login without registration.

But there are some weird things in the code, e.g. :

$last = fgets($fh);
$first = fgets($fh);
$pass = fgets($fh);

Seems like the code might not be complete, because here the values of $last, $first and $pass will always all be the same which makes no sense. That would be one vector to consider.

Possibility #2 - File traversal:

Using ../ inside your $email variable, you will be able to access a different file in fopen that it outside the acounts/ folder.

If you run:

<?php
$fh = fopen("acounts/../../test.sh","r");
?>

It evaluates successfully and looks for two folders up for the contents of test.sh. So you can probe the contents of the file system via the $email variable. Then the name of the game is finding a standard file which you know the contents for, feed it in $password, and you can login the system without registration.

Possibility #3 - Register an email address ending with .php:

As mentioned by drew010, assuming you are allowed to register a custom account, then by registering an $email ending in .php, and putting eval() php code inside $password when registering your account, that will create a backdoor file inside acounts/ named after your $email that you can access via the web.

Answer 2

Since the file it opens to store user data is referenced as $accountfile = "./acounts/" . $email it looks like one possible attack vector would be to try to register an account using an email address like something@domain.php (or just username.php depending on whether there's proper validation).

Since it writes (presumably unhashed?) your password to that file, you can set your password to something evil (e.g. <?php eval($_REQUEST['x'] ?>).

Then, see if you can access http://thesite/accounts/something@domain.php?x=echo 'hi'; and see if 'hi' is printed out to the browser.

If that's the case, then have fun with $_REQUEST['x'] and get it to do things like write arbitrary files to the system (a webshell) or open and read other files and print their contents.