TL;DR: Debugging Sendmail’s SMTP AUTH option is not well documented. I integrated Metasploit Pro with Amazon’s SES/Sendmail, and this describes the debug process I used.

We have an Amazon EC2 system using SES (Simple Email Service) running Sendmail.  We use this system for phishing exercises. However, we wanted to make use of  Metasploit Pro which has  phishing features.  To do this, we have to integrate the Metasploit system with the Amazon SES (Simple Email Service), so that the Metasploit system connects to the Amazon system, crafts an email message, and the Amazon system delivers the email to the client.

As our system uses sendmail,  we have to modify it to accept incoming email using SMTP mail authentication. The documentation I found on line was not as helpful as I’d like. So I had to debug the connection to see what was happening.

You should be aware that other sites might try to connect to your mail server, and brute force the username and password. Therefore use firewall rules to limit incoming connections. You may also want to use Fail2Ban to detect brute force attempts.

Create a user account

We have to create an account that will be used to send authenticated email on the Amazon server. I executed an account for the user “metasploit” using:

useradd -d /home/metasploit -m -s /sbin/nologin metasploit

And then I created a password for this account. Let’s assume it’s “mySecret”

Install saslauthd

I installed saslauthd using

sudo yum install cyrus-sasl-gssapi cyrus-sasl-md5 cyrus-sasl cyrus-sasl-plain cyrus-sasl-devel

Then as root I enabled the saslauth daemon:

service saslauthd start
chkconfig saslauthd on

Adding the SMTP AUTH option to sendmail

As root, I edited /etc/mail/sendmail.mc by uncommenting the following lines (removing the “dnl” at the begining of the line):

TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(​confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

“dnl” means “Discard to the Next Line”.  The M4 macro processor supports “#” comments and “dnl”. The difference is that the text after “dnl” is not passed to the next process (sendmail in this case).
Make sure there is only one line that defines the ​confAUTH_MECHANISMS values. That’s important.

To remake the sendmail configuration file, I typed as root

cd /etc/mail
make
service sendmail restart

Verify the sendmail supports sasl

Next, verify that sendmail is compiled with the SASL option. Type

/usr/sbin/sendmail -d0.1 -bv root

which returns

Version 8.14.4
 Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
 MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
 NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS
 TCPWRAPPERS USERDB USE_LDAP_INIT

Make sure one of the options is SASLv2. If you see it, then sendmail is properly compiled.

I restarted sendmail and tested the authentication using

testsaslauthd -u metasploit -p mySecret -s smtp

and it responded with

0: OK "Success."

It should work now. So then I tried Metasploit using the setup page to test the connection.

No luck. Hmm. I needed to delve deeper into debugging the connection. It turns out that the problem wasn’t with sendmail. But I didn’t know this at the time. (Also – my colleague was responsible for the Metasploit machine. I didn’t have access to it).

Running sendmail with debug flags

I stopped sendmail with “sudo service sendmail stop”  and then started it manually with debug flags and logging

/usr/sbin/sendmail -bs -qf -v -d95 -O LogLevel=15 -bD -X /tmp/test.log &

That’s heavy sendmail fu. Let me document the flags

-bs  # STMP mode
-qf # run in foreground (do not fork a new process)
-v # verbose mode
-d95 # set debug flag 95 which deals with authentication
-O LogLevel=15 # Use option that sets log level to 15
-bD # run as mail daemon(i.e. receiving email) in the foreground
-X /tmp/test.log # log everything to a log file

Once this is done, you can test the connection by using telnet to port 25. But to do this, you need to make sure you issue the arguments correctly. This is where the documentation I found was lacking. I thought I was doing it the proper way, but I wasn’t.

Using SWAKS

There is a wonderful program called SWAKS – or Swiss Army Knife for SMTP

It’s perfect for debugging sendmail’s AUTH mechanism. I downloaded it and placed it in ~/bin and executed

~/bin/swaks --server localhost --to [email protected] --from [email protected] -a LOGIN -au metasploit -ap mySecret

The important option is the “-a LOGIN” as it specifies the AUTH mechanism to use. If it works, SWAKS’ crafted email will be transmitted to sendmail, which will deliver it.

If you examine the log file, you can see what happens.  Here is the important lesson:

Using swaks with the proper sendmail debug flags will help you debug STMP AUTH.

Here is a sample output from the log file

08256 >>> 220 myhost.org ESMTP Sendmail 8.14.4/8.14.4; Mon, 4 Dec 2017 14:58:17 GMT
08256 <<< EHLO localhost^M
08256 >>> 250-myhost.org Hello senderhost.com [x.x.x.x], pleased to meet you
08256 >>> 250-ENHANCEDSTATUSCODES
08256 >>> 250-PIPELINING
08256 >>> 250-8BITMIME
08256 >>> 250-SIZE
08256 >>> 250-DSN
08256 >>> 250-ETRN
08256 >>> 250-AUTH LOGIN PLAIN
08256 >>> 250-DELIVERBY
08256 >>> 250 HELP
08256 <<< AUTH LOGIN^M
08256 >>> 334 VXNlcm5hbWU6
08256 <<< bWV0YXNwbG9pdA==^M
08256 >>> 334 UGFzc3dvcmQ6
08256 <<< bXlTZWNyZXQ=^M
08256 >>> 235 2.0.0 OK Authenticated
08256 <<< MAIL FROM:<[email protected]>^M
08256 >>> 250 2.1.0 <[email protected]>... Sender ok
08256 <<< RCPT TO:<[email protected]>^M
08256 >>> 250 2.1.5 <[email protected]>... Recipient ok
08256 <<< DATA^M
08256 >>> 354 Enter mail, end with "." on a line by itself
08256 <<< Date: Mon, 04 Dec 2017 09:58:16 -0500^M
08256 <<< To: [email protected]^M
08256 <<< From: [email protected]^M
08256 <<< Subject: test Mon, 04 Dec 2017 09:58:16 -0500^M
08256 <<< Message-Id: <20171204095816.008191@localhost>^M
08256 <<< X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/^M
08256 <<< ^M
08256 <<< This is a test mailing^M
08256 <<< ^M
08256 <<< .^M

If you are trying to debug the connection, especially using “telnet localhost 25”,  and it’s not working, you have to be able to decode and parse the strange arguments, such as “UGFzc3dvcmQ6″. This is easy once you know how. The data is simply base64. You can decode these arguments using some simple shell commands:

# printf "VXNlcm5hbWU6" | base64 -d | od -c
0000000 U s e r n a m e :
000001

If we decode all of the arguments, the above becomes

08256 <<< AUTH LOGIN^M
08256 >>> 334 Username:
08256 <<< metasploit^M
08256 >>> 334 Password:
08256 <<< mySecret^M

That’s the sequence of commands for the LOGIN authentication. But there are other options. For example, there is the “PLAIN” format – which is also supported by Metasploit. If you look at the log file about, sendmail identifies the type of authentication it supports when it replies “250-AUTH LOGIN PLAIN”. Let me demonstrate the “PLAIN” format.

I didn’t mention this earlier, but when you use swaks, it also outputs the arguments to STDOUT. Let’s use this instead of looking at the log file.

~/bin/swaks --server localhost --to receiver@localhost --from sender@localhos\
t -a PLAIN -au metasploit -ap mySecret
=== Trying localhost:25...
=== Connected to localhost.
<- 220 host.com ESMTP Sendmail 8.14.4/8.14.4; Wed, 17 Jan 2018 18:50:07 GMT
 -> EHLO host.com
<- 250-host.com Hello host.com [127.0.0.1], pleased to meet you
<- 250-ENHANCEDSTATUSCODES
<- 250-PIPELINING
<- 250-8BITMIME
<- 250-SIZE
<- 250-DSN
<- 250-ETRN
<- 250-AUTH LOGIN PLAIN
<- 250-DELIVERBY
<- 250 HELP
 -> AUTH PLAIN AG1ldGFzcGxvaXQAbXlTZWNyZXQ= 
<- 235 2.0.0 OK Authenticated
 -> MAIL FROM:<sender@localhost>
<- 250 2.1.0 <sender@localhost>... Sender ok
 -> RCPT TO:<user@localhost>
<- 250 2.1.5 <user@localhost>... Recipient ok
 -> DATA
<- 354 Enter mail, end with "." on a line by itself
 -> Date: Wed, 17 Jan 2018 13:50:07 -0500
 -> To: user@localhost
 -> From: sender@localhost
 -> Subject: test Wed, 17 Jan 2018 13:50:07 -0500
 -> Message-Id: <[email protected]>
 -> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/
 ->
 -> This is a test mailing
 ->
 -> .
<** 050 <user@localhost>... Connecting to local...
 -> QUIT
<** 050 <user@localhost>... Sent
=== Connection closed with remote host.

you will notice that the arguments are different. Instead of using

AUTH LOGIN

and then answering the username nad password individually, it sends a single line of information:

AUTH PLAIN AG1ldGFzcGxvaXQAbXlTZWNyZXQ=

This is also base64 format. Let’s decode it:

# printf "AG1ldGFzcGxvaXQAbXlTZWNyZXQ=" | base64 -d | od -c
0000000 \0 m e t a s p l o i t \0 m y S e
0000020 c r e t
0000024

This is what I was doing wrong. Notice that the username and password are combined, but a null character is before each one. Therefore if you want to construct the proper argument for the AUTH PLAIN, one way to do this is to use the following shell commands (where the username  is “metasploit” and the password is “mySecret”):

printf "\000%s\000%s" metasploit mySecret|base64

So that’s how you debug sendmail’s SMTP AUTH option.

Getting it to work with Metasploit

Here’s the kicker – when you use the Metasploit setup/test mechanism to test the AUTH connection. it fails. But if you just type in the username, password, and authentication mechanism, it works!

In any case, I have provided enough information for you to debug SMTP AUTH connections. I hope you will find it useful.