PHPMailer could put your website at risk: here’s what you need to know

Does your website have one of those “contact us” forms?

If so, you’ve probably experienced what we jocularly called SPEWS: spam by electronic web submission.

That’s where spammers shove unwanted emails at your sales team or your support department by autofilling your contact form with junk mail.

In many organisations, emails generated by web forms skip the spam filter (technically, the actual emails come from inside, because the web server creates them), and the crooks love it when that happens.

But SPEWS can be worse than annoying: thanks to a security vulnerability in a popular web software component called PHPMailer, crooks could use your “contact us” form to take over your whole website.

PHPMailer is widely used in web software applications, because there are many uses for a PHP-based mail-sending toolkit, such as:

• Sending out links for trial downloads.
• Acknowledging support questions with a ticket number.
• Confirming a mailing list subscription.
• Welcoming new users after they set up their accounts.

Unfortunately, a security researcher called Dawid Golunksi recently published a proof-of-concept exploit showing how to use a sneakily-formatted email address to take over a vulnerable web server via PHPMailer.

This isn’t a straightforward command injection attack, where a Unix command is embedded directly into the booby-trapped email address, but a two-stage attack involving sneaking an untrusted file onto the server and then coming back for the second stage of the attack and running the injected file.

LEARN MORE: Command injection explained ►

Somewhat simplified, the attack goes like this:

• Specify an email address with a sneaky sendmail “logfile” option embedded in it.
• Place a PHP script in the email content.
• Wait for the server to process the email, causing it to be written to the logfile.
• Come back later and access the booby-trapped logfile.
• Wait for the server to extract and run the PHP script embedded in the faked logfile entry.

Bingo: remote code execution, or RCE.

As far as we can see, Golunski’s attack depends on a vulnerable web server constructing and sending its automatically generated email with the attacker’s email address specified as the sender.

That’s not always the case, but when sending a “contact us” email onwards to an internal account, for example support@example.com, it makes perfect sense, in which case, PHPMailer ends up constructing a command something like this:

sendmail -foutsider@some.example [. . .] 

Above, the -f option is used to designate the email sender. (Think of it as -f for from.)

If you read up on command injection above, you probably know where this is going.

By specifying a booby-trapped email address with some disguised quote marks, Golunski figured out how to turn the command generated by PHPMailer into something like this instead:

sendmail -foutsider -X/some/file/name  [. . .] @some.example [. . .] 

The -X parameter tells the email server to log the email, including its content, to /some/file/name, which is the trick used to inject an untrusted file onto a vulnerable server.

As mentioned above, by carefully embedding a PHP script in the content of a “contact us” email, crooks may therefore be able to add their own PHP programs onto the web server, perhaps even including some sort of PHP administration console toolkit.

By choosing the right path for /some/file/name, the crooks will probably be able to leave their booby-trapped PHP upload at a predicatable URL they can then visit, therefore activating their backdoor script whenever they like.

In case you’re wondering, the sendmail command is commonly installed and used on Unix systems for processing email from the command line. Even if the email server in use isn’t actually the Sendmail application, a largely compatible command with the name sendmail will usually exist to control it. If you’re using Postfix or Exim instead of Sendmail, there will be a sendmail command, but it will rather handily ignore the -X option, according to the relevant Postfix and Exim documentation. (That doesn’t fix this vulnerability, but it avoids any exploit that relies on -X to write to an attacker-controlled file.)

What to do?

First, you need to work out if your web server has PHPMailer installed.

One problem here is that you may be using PHPMailer without realising it, either as part of a web server programming framework (e.g. Zend), a content management system (e.g. Drupal), or included in the hosted webserver package you chose.

If in doubt, ask your hosting company.

Second, you need to update PHPMailer, either directly or by updating the application that includes it.

Unfortunately, we can’t give you a generic way of checking that you have the latest version of PHPMailer; once again, if in doubt, please ask your hosting company for advice.

Third, keep your eye out for future PHPMailer releases.

As sometimes happens when a dangerous RCE bug turns up, updates to updates come out in quick succession as the bug is investigated more deeply.

In the past two weeks, since this bug was first revealed, PHPMailer has already issued updates numbered 5.2.18, 5.2.19, 5.2.20 and 5.2.21, although the .21 update was admittedly only published to correct a typographic error. [Version numbers correct at 2017-01-03T17:15Z]

Patch early, patch often!