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”
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
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.
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 firstname.lastname@example.org --from email@example.com -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:<firstname.lastname@example.org>^M 08256 >>> 250 2.1.0 <email@example.com>... Sender ok 08256 <<< RCPT TO:<firstname.lastname@example.org>^M 08256 >>> 250 2.1.5 <email@example.com>... 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: firstname.lastname@example.org^M 08256 <<< From: email@example.com^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: <firstname.lastname@example.org> -> 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
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.