Pentest Writeup | Exim SMTP 4.87

gavin

— 5 min read
Pentest Writeup | Exim SMTP 4.87

This blog covers how I attempted to exploit an exposed Exim service running an outdated version (4.87) on a company I have gotten permission to conduct penetration tests on.

💡
This blog post is meant for education purposes and to spread awareness of securing self-hosted services. Do not attempt any of the exploits on others you have not received consent to pentest for.
❗
For privacy reasons, the actual Domain(s) and IP(s) of the company have been redacted.
😗
Disclaimer: The service, although outdated, was not vulnerable to the exploit attempted in the writeup. However, I was able to do something else!

Reconnaissance

Nmap Scan & Research

First, I did an nmap scan on the server and found several service running on it! Since I have not touched on SMTP vulnerabilities before, I thought I would try to do so.

nmap results showing an exposed Exim smtpd 4.87 service

With some research, I found a working exploit / proof-of-concept (PoC) for Exim services running versions between 4.87 - 4.91 on ExploitDB.

ExploitDB Exploit for Exim 4.87 - 4.91 service

Exploitation

Using and modifying existing Exim Exploit PoC

I copied the script over to my Kali machine and modified it slightly to take in two inputs, IP and Port.

Output of the exploit script

As shown above, I encountered an error; "Access denied - Invalid HELO name". With some research, the HELO command sent to the Exim server also helps the server check the hostname. All I had to do was modify the script (again) to take an input hostname (-n, redacted) to be sent through the HELO command in the PoC.

Tip: The hostname usually something that uses the same name as the domain name with a common user, such as [email protected] .

Output of the modified script that takes a hostname as an input

The HELO hostname validation has been satisfied! I now have yet another error to deal with; "restricted characters in recipient address". This is a pretty self-explanatory error, basically there's input validation for the recipient address.

All I had to do was modify the script (yet again) and see if certain characters are accepted. I first attempted to use hex-encoded bytes (e.g. \x20 for space).

Output of the modified script that uses hex-encoded bytes to send the payload

With this, I have discovered that hex-encoding the payload indeed works to bypass the input validation. However, the way the server parsed it did not work in my favour, so I had to change my strategy.

Original strategy where the payload is injected into the recipient address.

The above payload is the original approach where the payload is injected through the recipient address.

New strategy where the payload is injected into the recipient address

The new strategy involves injecting the payload through the sender address.

Output of the modified script that injects the payload through the sender address

Since we get the same error for injecting the payload through both the sender and recipient address, I changed my strategy (yet again) to inject the payload through the DATA command, using an X-Header instead.

Modified script to inject the payload through the DATA header.
Output of the modified script which injects the payload through the DATA header.

This time, the error indicated progress in our attempt to get initial foothold in the system. I modified the sender address to use the same address as the recipient address, since it is a valid email address in the smtp server.

Output of the modified script which has a valid sender address.

This error means our exploit works! We just need to bypass the authentication, which is common through port 25 which just so happens to be running as it commonly allows Unauthenticated Server-to-Server SMTP communications.

Output of the script being used against the target's port 25

This is when I realised, although the script works, I wasn't receiving a shell. This meant that the payload, although valid, will not work as commands will not be recognised and therefore will not be run; because the Exim templating system and/or filter rules excluded code/commands which is often enabled by default.

To do a final check, I manually tested conditional statements using the "expanding variables" command syntax in the RCPT TO field through telnet.

Output of conditional statement in RCPT command

Since this was also not possible, I have concluded that the service is not vulnerable to this CVE Exploit.

Conclusion

It was vulnerable, but not vulnerable enough, unless...?

Although the script was not able to execute arbitrary commands or allow me to obtain a shell, I am able to:

  • Discover emails in the SMTP server (by bruteforce)
  • Send emails to and from valid emails in the SMTP server without authentication or any authority (Social-engineering attacks; imagine receiving an email you thought was from a colleague, but it wasn't!)
  • Carry out DDoS attacks and impact the availability of the SMTP server (services on the infrastructure are known to not have protection against DDoS attacks.
  • Flood internal mailboxes with valid but useless mails.
The administrator patched the service the following day

The next day, as I was finalizing this write-up, I realized the service has been patched, or strengthened, to only allow internal connections. Oh well. 🥲

If you know of any working exploits that you think might be helpful in a successful RCE, feel free to let me know. If not, I hope this write-up helped you learn a thing or two about SMTP servers, how they function, what vulnerabilities can exist, why they exist, and gets you thinking of ways to defend against such threats.

Read more