Subscribe to our Newsletter. The latest news and articles delivered to your Inbox!
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.
Network sniffing provides a plethora of information useful in troubleshooting and identifying security weaknesses. Today we look at a practical example by extracting user credentials from a network capture.
In Sniffing with Microsoft Network Monitor we captured traffic and explored how to single out a specific network conversation with the help of filters. Today we will employ this tool in a practical example, demonstrating how user credentials can be extracted from a network capture of a plain text authenticated SMTP email. We should look at this from the perspective of a malicious hacker that manages to install a network sniffer. Thus our goal here is that of understanding the potential danger that arises from the flow of unencrypted sensitive data.
In Plain Text Authentication Exposed we walked through the sending of such an email using telnet. In the process we highlighted how the credentials are sent unencrypted. We also looked at the Exchange 2003/2007 configuration elements determining whether the server allows the use of such an authentication method.
We can go ahead with our main course. I will skip details on installing the Microsoft Network Sniffer and on configuring Exchange to allow plain text authentication. Check the two articles referenced above for these bits. Also note that even though here I am working with Exchange 2007 this article is not specific to Exchange. The discussion applies to any scenario where plain text authentication is in use.
So here I have a mail server (EXCHSRV) and a client machine (MARS). My goal is to capture emails sent from MARS and extract any transmitted credentials.
MARS is being used by a user with credentials:
On MARS, we setup Outlook Express OE as an SMTP/POP3 client. We configure an OE account for User1 to access his mailbox feeding the wizard the necessary credentials. The following are the most important settings under the Servers property page for the email account:
Note the 'My server requires authentication' checkbox is set. The same credentials for both incoming (POP3) and outgoing (SMTP) emails are being used.
On the Exchange server we have Microsoft Network Monitor v3.2 installed and capturing all traffic. To replicate a live environment, we also bombard the Exchange server with emails from another machine. In between, we submit an email from MARS.
After collecting tens of thousands of frames, we stop the capture and proceed with identifying the email from MARS. Of course we have too many packets to step through each one by one. Thus we employ a display filter:
(Source == "MARS " OR Destination == "MARS ") AND ProtocolName == "SMTP"
We already discussed this filter in Sniffing with Microsoft Network Monitor, so I will not delve into details on how this was constructed. What matters is that we are instructing the Monitor to only display SMTP conversations between MARS and EXCHSRV. Thus we automatically hide emails from other machines and any non-SMTP conversations.
Now we are able to step through the emails. From the Frame Summary pane, we can easily identify each of the SMTP commands (EHLO, AUTH LOGIN, MAIL FROM, RCPT TO etc.) and the server responses. We discussed these commands in Plain Text Authentication Exposed.
Let's jump straight to the server response in return to the AUTH LOGIN command. The response text reads:
The text here is base64 encoded. We decode this using the motobit.com online encoder/decoder. This is just a prompt saying 'Username:'. So the next frame from MARS will supply the user name.
Here is the base64 encoded username:
Decoding this we of course get 'user1'.
The frame that follows is the server password request. Next we have the password itself, completing the authentication process.
This is the captured password base64 encoded:
As expected on decoding we get:
No matter how complex our password is, a hacker with such a capture will have no problem to extract our credentials. The reason is that the weak link is not the password itself, but the authentication protocol.
Here we made use of a capture display filter to isolate the relevant frames. This is a luxury that an experienced hacker does not require. If we open the capture in a binary viewer and search for 'AUTH LOGIN', we immediately jump to the position where we can expect to find the credentials. He may then need to skim through the capture for some time but the information won't be far away. Raw searches for well known keywords allow hackers to immediately tell if a large block of captured data includes interesting information.
Today we looked at one example of how a network sniffer could be employed. There is a lot more information flowing over the network. For example let say we have an RBL anti-spam filter and we wanted to verify if the software is sending out any queries. This would be just a matter of sniffing DNS conversations:
Or let say we don't know why an incoming email is being rejected. The sniffer would have the answer.
Sniffing with Microsoft Network Monitor
Plain Text Authentication Exposed
Motobit.com - Base64 Encoder/Decoder
Add New Comment...