Detecting and Exploiting the PHPMailer RCE
Research / Security Alerts / Posted January 04, 2017
On the 25th of December 2016, a security researcher disclosed a critical security flaw within a popular PHP library used to send emails. The PHPMailer library is used by more than 9 million websites worldwide and is bundled with popular open source PHP content management systems such as WordPress. At worst the flaw could be exploited to execute arbitrary PHP code on the affected system. This would allow the remote attacker to take complete control of the application and launch further attacks against the system and internal network. PHPMailer versions below 5.2.20 are affected along with a number of other libraries that include the vulnerable code; such as SwiftMail and the Zend Framework.
A vulnerable VM created during our investigation can be downloaded here. The VM provides two different variants of the vulnerability in versions 5.2.18 and 5.2.19.
What is the vulnerability?
The original advisory lists the flaw as “Remote Code Execution”, whilst this could be true given the correct set of circumstances, it does not allow code execution in all cases.
The flaw arises from insecure parsing of the “sender” argument passed to the mailing function (setFrom() to be more specific). This allows the attacker to craft a request that will result in additional command line arguments being passed to the underling mailer binary. The attacker is therefore limited to the command line arguments supported by the installed MTA.
For example, if the application implements Sendmail, the command line argument -X can be supplied to write a log file to any location on the file system for which the executing user has permission. The log file contains verbose log information that includes data supplied by the attacker. One exploit scenario is that the attacker exploits Sendmail to write a malicious PHP file within a web accessible directory, accessing the file will then execute embedded PHP code to take control of the system.
Am I affected?
The vulnerable library should be updated on all affected systems regardless of configuration, however there are a few prerequisites to exploiting this flaw which are discussed below.
To exploit this flaw the attacker must control the sender address of the email. This may occur when a contact form, or similar, sets the “From” address to the email addressed supplied by the user. This may be the case for several different types of contact forms, to allow the recipient to reply to the sending user directly.
Even when the sender address is attacker controlled, in order to execute malicious code, the underlying mailer binary must provide a command line argument that can be abused. Sendmail was identified within the original advisory, however several alternatives to Sendmail such as Exim4 are commonly used.
Does AppCheck detect the flaw?
Yes, our initial update was available to subscribers on the 28th of December 2016. Further updates will also be made live on the 4th of January to safely exploit the flaw and detect the vulnerability in a wide range of configurations.
Detecting and Exploiting the vulnerability.
There are several methods that can be employed to detect the flaw remotely; each method has associated pros and cons. As with all of our security checks, multiple methods are combined to offer the greatest level of assurance possible.
AppCheck identifies the target component by crawling the target application to identify all points in which attacker supplied data could be processed. Each identified parameter is then tested using the following methods (but not limited to):
One accurate method of detecting this flaw is to use SMTP as an out-of-band detection mechanism. For example, when Sendmail is implemented as the MTA, the -N command line argument can be used to define when a failure (Delivery Status Notification) email is sent back to the sender. AppCheck submits an email address monitored by our Sentinel system along with -N success, failure option. If an email is received we can assume that the system is likely to be vulnerable. This is further confirmed by resubmitting the request with -N never, which should not generate an email.
DNS is also used to identify potential candidates for further fuzzing techniques. In this case AppCheck submits two payloads containing specially crafted domain names that are detected by our Sentinel DNS server. By changing each payload so that only one should successfully perform the DNS lookup on a vulnerable system we are able to identity the vulnerability.
AppCheck includes a safe exploitation module for this vulnerability that will attempt to fully confirm the flaw. The exploitation features are continually developed and we will add further techniques over the coming days.
One method employed by AppCheck is as follows;
All web directories are logged during the crawl phase.
When the PHPMailer vulnerability is identified, an attempt to write to each directory is performed using paths relative to the current directory.
For example, if the flaw is identified in https://target/forms/contactus.php and the following web paths are observed within the crawl; http://target/forms/resume/ and http://target/uploads/, the following payloads could be used in an attempt to create a PHP file in each directory:
"<?php phpinfo() ?>\" -X
"<?php phpinfo() ?>\" -X
If successful, accessing the file will execute the PHP code phpinfo()
Note: When targeting version 5.2.19, the \” should be replaced with ‘
Fixing the vulnerability
Initially version 5.2.18 of PHPMailer was reported to fix the issue, however it was found shortly after that this fix was flawed and could still be exploited. Versions 5.2.20 and above correctly resolve the vulnerability.
For Zend Framework users, upgrade to the latest release as described here; https://framework.zend.com/security/advisory/ZF2016-04
SwiftMail users should upgrade to version 5.4.5 or higher
The flaw was discovered and reported by Dawid Golunski;
Get started with Appcheck
No software to download or install.
Contact us or call us 0113 887 8380