WinDeveloper IMF Tune

WinDeveloper IMF Tune
WinDeveloper IMF Tune

Plain Text Authentication Exposed

Alexander Zammit

Alexander Zammit Photo

Alexander Zammit has been developing server applications for over 15 years. Most of his works involve Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.

  • Published: Sep 06, 2007
  • Category: Security
  • Votes: 5.0 out of 5 - 6 Votes
Cast your Vote
Poor Excellent

Exchange allows the use of plain text authentication for inbound and outbound SMTP email. Employing telnet we test for the availability of this authentication method, and expose its key weakness.

In Authentication Primer we started discussing authentication methods highlighting some fundamental concepts. Plain Text authentication is one such method, one that is often considered to be too weak for applications requiring an adequate level of security. Today we take a close look at plain text authentication in the submission of SMTP emails highlighting its limitations.

Base64 Encoding

In the discussion that follows we will encounter the use of Base64 encoding. This is documented in RFC 4648 (see references). Don't worry you don't have to read any RFC. Online tools are available that will happily convert to and from Base64. I found one such tool at motobit.com.

The uninitiated should make sure not to confuse encodings with encryption. Security applications use encryption in an attempt to ensure only the intended recipient is able to read/use the information.

Encodings transform information to a format more suitable for a given application. For example an encoding could be used to convey Unicode text through a channel that only support ANSI text. Here the intention is not that of hiding information, no secret keys are involved.

AUTH LOGIN

An easy way to see what plain text authentication is about is using telnet. In Telnet Port 25 and Testing Exchange through Telnet we saw how easy it is to submit an SMTP email in this manner. Today we revisit the topic adding the use of the AUTH LOGIN SMTP command.

  1. To begin I created a user mailbox on Exchange having plain text authentication enabled for inbound emails. The credentials were set as follows:
    Username: VERT\user2
    Password: password

  2. Connect to Exchange as explained in Telnet Port 25.

  3. Following the EHLO command the AUTH LOGIN command was submitted:

    EHLO test.local
    250-bang.vert.local Hello [192.168.0.221]
    250-SIZE
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-X-ANONYMOUSTLS
    250-AUTH GSSAPI NTLM LOGIN
    250-X-EXPS GSSAPI NTLM
    250-8BITMIME
    250-BINARYMIME
    250-CHUNKING
    250 XEXCH50
    AUTH LOGIN
    334 VXNlcm5hbWU6
    

    The seemingly cryptic response is just a Base64 encoded string. We decode this using the online tool referred to earlier. It turns out the text simply says "Username:"

  4. Next using the same tool we encode the username 'user2' to Base64 getting "dXNlcjI=". This value is fed to telnet as the username.

    AUTH LOGIN
    334 VXNlcm5hbWU6
    dXNlcjI=
    334 UGFzc3dvcmQ6
    

    As you can expect the response is the encoded text saying "Password:"

  5. So we now encode "password" to Base64 getting "cGFzc3dvcmQ=" and feed the value to telnet

    AUTH LOGIN
    334 VXNlcm5hbWU6
    dXNlcjI=
    334 UGFzc3dvcmQ6
    cGFzc3dvcmQ=
    235 2.7.0 Authentication successful
    
  6. The 'Authentication successful' response confirms that we completed the authentication procedure. We could now proceed with the MAIL FROM command as explained in Telnet Port 25. The complete telnet session is shown below.

telnet session

This discussion highlights the key issue with this authentication method. As the name suggests, the credentials are sent over the wire in plain text without any encryption. Just like we encoded/decoded Base64 so can anyone else who manages to sniff the credentials.

Using this procedure we can easily test if our servers are configured to accept such a weak authentication method. Keep in mind that even when allowing other authentication methods, an attacker might be able to force clients to use the weakest authentication.

Exchange Configuration

Let's have a look at where the SMTP Authentication settings are located in Exchange 2003 and 2007. Each allow for configuring authentication for inbound and outbound emails independently.

In Exchange 2003 you will find these under the SMTP virtual server properties and SMTP connectors. At the SMTP Virtual server properties, under the Access page, click on Authentication. Here we find the settings for inbound emails.

SMTP Virtual Server Access

SMTP Virtual Server Inbound Authentication

Next check the authentication settings for outbound connections. At the SMTP virtual server under the Delivery page click on the Outbound Security button.

SMTP Virtual Server Delivery

SMTP Virtual Server Outbound Security

In Exchange 2007 similar settings are available at the Send and Receive Connectors. Look for these on Edge and Hub transport servers. From the management console, under Server Configuration, open the Receive connector properties. Select the Authentication page to see the allowed inbound authentication methods. Furthermore check the Permissions Group page to see the user categories that are allowed to submit emails.

Receive Connector Authentication

Receive Connector Permission Groups

For outbound authentication, move to the Organization Configuration and check the Send Connector properties. You should at least have one for the internet facing server. This may be the Hub or Edge transport depending on how Exchange 2007 is configured.

At the Send Connector select the Network property page. Authentication configuration here is directly bound to the smart host configuration. This clarifies the right context when outbound authentication could be configured. Select 'Route mail through the following smart hosts" and click on Change to expose the Authentication settings.

Send Connector Network

Send Connector Smart Host Authentication

In both Exchange versions it is worth noting how these allow for Transport Layer Security (TLS). TLS adds a certificate based handshake protocol that is required to take place before SMTP authentication. This improves security and is highly recommended whenever plain text authentication is in use. The telnet test we made earlier was performed against a server where TLS was disabled. For more details on TLS check references.

References

Authentication Primer

Telnet Port 25

RFC 2554 - SMTP Service Extension for Authentication

RFC 4648 - The Base16, Base32, and Base64 Data Encodings

Base64 Encoding/Decoding Tool

How to help protect SMTP communication by using the Transport Layer Security protocol in Exchange Server

Copyright © 2005 - 2014 All rights reserved. ExchangeInbox.com is not affiliated with Microsoft Corporation