Consultant's view: Internal sender spoofing - Ban mail from

What would you do if an email from a colleague asked you to sign one of their contacts into your building? What if they just wanted to know when you were going to be out of the office over the coming weeks?

How would you react to a request for an updated inventory of your PC - from anti-virus to operating system? These are things we do without much thought as we trust the people making the request - or rather we trust the mechanism enabling them to make that request.

We process what we see and determine its credibility, so an email that appears to be from a colleague will get attention, and probably the response they're asking for. Spammers make their emails more credible by using mail relays inadvertently left open by an organisation and "bouncing" emails out to their targets. Fortunately, virtually all organisations have now secured their servers against this style of abuse.

It is also incredibly easy to manipulate an email's header so that it appears to come from someone other than the spammer or the unwitting host organisation. Tampering with the email in this way makes it more likely that the recipient will open it. This is really easy to spot though, as simply reading the email's properties and checking the mailserver will reveal the origins of the message. If they don't match it's probably spam or worse.

In our experience as penetration testers, we have found many instances where incoming spam is blocked at the mail relay, but internal mail relay is not being stopped. By sending some simple commands to a public SMTP mail server interface, we can make email appear to have come from one internal user, sent to another internal user. Inspecting email headers won't uncover the abuse as they will show that the message did indeed come from the internal user. The only way to spot a well-crafted mail relay such as this is to inspect the logs from your mail server'spublic interface and then correlate these with the workstation mailclient - an onerous task.

So, what is the significance of internal mail relay abuse?

Firstly, anyone using the internet, be they a hacker, a disgruntled oran ex-employee, can send emails between internal users. If those emails contain pornographic, malicious or defamatory content, the receiving party will believe it came from the named sources: recognised internal users. It's a time consuming issue to disprove.

Secondly, someone using social engineering, will usually try to find employees in the IT department who are away from the office. A relayed email from the supposed remote worker to an internal IT staff member, indicating that an "engineer will be visiting, so please let them in to the server room" makes the job of social engineering so much easier.

It's not a difficult attack either: send the following commands to your mail server from an external connection to try it out for yourself:

HELO (or EHLO)
mail from:
rcpt to:
Data
Message content
.
Quit


There are many more commands to improve the format of the email, but the above will prove the point. Obviously we would advise that you ensure the target for your test is your own corporate email address.

A similar style of relay can allow the attacker to make emails appear to come from internal users, sent to external parties. An email could besent from the CEO's account to a newspaper announcing a profits disclosure, for example. Of course newspapers always always check their sources, don't they?

How do you stop this? It's remarkably simple: blacklist emails coming from your public mail server interface that have your domain name in the "from" field.

Ken Munro is managing director of SecureTest. He can be contacted atken.munro@securetest.com

banconsultantsfrominternalmailsecuritysenderspoofingview