I recall a couple of years ago I was toying around with SMTP, and more in particular Exchange and Lotus Domino. I noticed that even when the server is configured to not act as a relay, it still delivers internal messages, that is to anyone on any of the domains it is configured for – WITHOUT authentication and by using telnet and the SMTP commands.
I am assuming the reason for this is because you are actually sending an email from the SMTP server itself, not from a user account.
(And before I go on, I haven’t tried this for years, and I only tested a few different servers, so would love if you guys tested your own servers and let me know if it is still relevant)
Basically the premise is, you can spoof an email to anyone inside that company, making it look like somebody else from within that company (the circle of trust)
I did a few tests within my own company’s Exchange server and also a friend of mine who’s company was running a Domino server, who worked at a completely different company in another city. (He really should have had a separate mail filtering gateway somewhere in front of his set up with proper firewall rules preventing external people to connect directly to their Domino server over port 25).
From within my company, let’s call the domain backtosecurity.com. I logged into my Exchange server. (My commands are in BOLD)
telnet mail.backtosecurity.com 25
220 mail.backtosecurity.com Microsoft ESMTP MAIL Service ready at……….
mail from: CEO@backtosecurity.com
250 2.1.0 Sender OK
rcpt to: firstname.lastname@example.org
250 2.1.0 Recipient OK
Subject: Marts, I think you deserve a pay rise <ENTER><ENTER>
I am really pleased with your performance lately. I am giving you a 20% pay rise effective immediately.
250 2.0.0 Message accepted for delivery
Seconds later my Outlook makes the ‘ding’ noise. I check my email. Yep, looks like my boss just sent me an email giving me a pay rise. Checking the headers of the email I received shows that it was sent from OUR mail server. So it can’t be spam with a spoofed email address, it came from in house. Must be normal – eh? (Most people would not notice that the ‘client’ was ‘SMTP’ opposed to ‘Outlook6.5’ etc.
I then telnetted to my friend’s Domino server (by looking up his company’s MX records) and sent an email to him, from somebody else I knew in the company. This freaked him out (much to my amusement).
This does not work with trying to send an email to an external domain or email address as relaying is turned off, and you will need to authenticate as a a valid user.
So what is dangerous about this? We already have tools that make it easy to spoof emails. We also have things like SET (Social Engineer’s Toolkit) that can make custom targeted phishing campaigns with malicious links that reverse shell back to your box. But what if somebody savvy actually checks the headers and sees that the originating IP address of the sender was foreign? This would not happen in my example above.
So now it is time to use your imagination.
Let’s say we do the usual information gathering on a company before an attack. We find out the syntax they use for staff email addresses. We check their website for employee listings and account managers, directors etc. We use Google ( “@targetdomain.com”), we can use tools like Maltego, we can check social networks (and infiltrate the circle of trust under a disguise of an another employee, if need be). All you need are their names, and we know their corresponding email address.
Now let’s assume the company has a mail server sitting inside the company, might be in the DMZ, doesn’t matter. The firewall is allowing incoming SMTP(25) traffic from ANY. (This is a bad set up, but it is still very common as far as I know). So we can now telnet to their mail server. Craft an email like I did above to somebody in their company, from somebody in their company, without raising too much suspicion.
Won’t the email be text only? Won’t they notice the standard Outlook HTML formatting is not there? Not if you don’t want it to. You can add HTML into the subject with the SMTP commands. And this will be handy for masking your malicious link that gives you root.
Content-Type: text/html; charset=”ISO-8859-1″
<meta http-equiv=’content-type’ content=’text/html; charset=ISO-8859-1′>
<p>Hey Bob, does this page on the intranet work for you?</p>
If I was Bob, I would click on that link. Problem with this is, when it doesn’t work, Bob will reply saying “No, it doesn’t”, which will alert the users AFTER you potentially gain root. Which might not be a problem in your circumstance. (I won’t delve into setting up a Malicious server that gives you a reverse shell and iFrames them to a legitimate site).
Creativity is all which is required here
One other quick example to ensure the user does not try to reply (and set of alarm bells) is to forge an email from the IT department saying “click here to view our new intranet site. (we are still working out the kinks so if doesn’t work at the moment, don’t be alarmed).”
Other caveats? Well when I tested this, I could not find a way to make the SEND FROM email address have an ALIAS for the name. For example, the user will see the entire email address instead of the sender’s name, which might raise suspicion within a domain environment. I am sure there is a way to change this, I just haven’t couldn’t it out last time I looked.
This resource gives a good example of crafting mail using SMTP commands: http://www.walkernews.net/2011/01/06/uses-telnet-and-smtp-commands-to-send-email-with-subject-and-html-content/
So there you have it. I have not tested this method for a couple of years. New versions of mail servers might prevent this, so I would like to hear people’s thoughts. It just came back to me when I was eating lunch and was curious as to why I haven’t seen any main stream attacks using this method (that are publicised)
How to protect yourself from this?
Well the usual steps apply. Check the headers to see where the email has come from (and with what client). If there is a link in your email, view the HTML output before clicking and make sure it isn’t masking something strange.
And also, best practice is to not allow ALL SMTP traffic straight in to your internal mail server. You should have some sort of email filtering device/proxy in front of this, or even use a third party relay like MessageLabs or Google’s Postini, then configure your firewall rules to only allow SMTP traffic from that service/device (your MX records will be pointing to said service/device).
Hope somebody learned something from this, and more importantly to be vigilant when checking the validity of messages you receive.
This appears to have been fixed in Exchange 2003 Service Packs and any newer versions.
Can still affect default installations of Sendmail.
This can still be a threat with online email service providers if they haven’t been updating their servers.