Follow Up: Closed Relay - SMTP Auth Attack

On Monday, I posted a blog post related to an increase in SMTP Auth Attacks. Frank posted an interesting comment with a question which I thought was worth discussing:

Good posting. I haven't seen very strong support by MTAs to identify SMTP AUTH brute force attacks. Any comments on what vendors are doing, between Exchange (using AD on the backend), LDAP-based auth, and native system AUTH?

Of course the best way to mitigate exposure to a SMTP Auth Attack is to disable the feature. If it really is necessary to use it, it could be limited to specific IP addresses or subnets that are trusted such as a VPN, rather than allowing anyone in the world to authenticate. However, the comment obviously relates to a situation where SMTP Auth must be supported and the connection IP address of clients could come from anywhere.

In the case of an Exchange server mentioned above, it's not usually recommended to have the server in the DMZ from a security viewpoint. Instead, a SMTP proxy (which could be software/appliance/hosted) sitting in front of the MTA could be used to detect these attacks rather than relying on Exchange or the back end authentication mechanism to detect them.

Does Exchange actually have any features to combat an attack? To be perfectly honest I wasn't sure so I did a little digging. I was already aware of the tarpit feature in Exchange 2003 dicussed in this Knowledge Base article. As the tarpit feature is bypassed for authenticated sessions it's not clear if it would help prevent a SMTP Auth attack by tarpitting it due to failed authentication attempts. However, I did find a MS Exchange tutorial claiming that it did. I wanted to confirm this so I contacted our friend, Terry Zink, the product manager for Exchange Hosted Services to pass my query on to a relevant contact. He was kind enough to oblige and confirmed that Exchange 2007 does tarpit failed authentication attempts and was pretty sure that 2003 did likewise.

While I was writing this follow up to the original blog post, Frank also commented on the ability of other MTA's to prevent these attacks:

Incidentally, a vendor who has customized qmail (among other things) mentioned to me that they have rate-limiters per IP and username for just that aspect.

That's a typical way to mitigate this type of attack. Rather than allowing an attacker to hammer a mail server all day the authentication failures per ip or user can be used to detect it. It's quite similar to a SSH Brute Force attack and there's a unix solution, Fail2Ban, that can detect failed smtp authentications and create rules to temporarily ban the originating IP addresses.

If any of you are worried that you might be vulnerable to such an attack and are not even sure if this feature is enabled, you can check by telnet-ing directly to port 25, issuing a ehlo/helo and looking at the capabilities reported by the MTA to see if AUTH is listed. You could also check your outbound mail servers IP address against multiple blacklists using this tool multiple blacklists. It's also a good idea to monitor SMTP AUTH traffic at a perimeter firewall or SMTP Proxy to see any failures.

Irish Stock Exchange Website Compromised

I regularly read the US-CERT (United States - Computer Emergency Readiness Team) website to follow current activity. This morning, there was a warning of an attack that has compromised a large number of legitimate websites. One of the compromised sites generated quite a bit of media attention since it's a security related website. However, I thought it might be interesting to see if any other well known websites had also been compromised.



After a little searching I saw that the Irish Stock Exchange website, www.ise.ie had been a victim of the attack. The Announcement List asp page had been compromised in an attempt to add a link to a malicious Trojan hosted on a different web server. Fortunately, this issue has already been resolved but evidence of the attack against the site is revealed in a google cache search of the announcement page.

The Danger of Auto Open

It's quite common for PC users to have applications linked to specific file types. For example, a pdf file may be associated with Adobe Reader or a mpeg video file associated with Windows Media Player. If an internet user clicked on a website link to a file such as this, the user could may be prompted to confirm the file should be opened. Many people opt to use the "Auto Open" feature so the application would immediately open the attachment.

Mass mailing worms typically exploit vulnerabilities in applications by crafting an evil file. Did you realize that by simply opening an image, pdf or other simple file it could be possible for an attacker to take complete control over your PC? You may feel that you would never click on an attachment in an e-mail from someone you don't know as it's obviously a worm but the attachment doesn't even need to be in the e-mail, it could be simply linked to.

Here's an example of an attack I provided to David Utter of Web Pro News:

http://www.google.com/search?hl=en&q=inurl:mail%20intext:shaping+traffic+techniques&btnI=

The URL above exploits a combination of the "Feeling Lucky" feature and an "Auto Open" configured PC. Should a user click on the link the pdf attachment could automatically open. Fortunately in this case it's a benign white paper but it could have easily been a malicious file.

I should point out that the "Feeling Lucky" button has been abused by spammers for quite a few months but my combining social and technical engineering techniques this could have been an effective attack. At the time there were rumors of a Google Phone so an attack e-mail could have been created with Subject lines related to a sneak peak. Since, the e-mail was related to Google, it would make sense for the body to have a link to Google, keywords specific to the gphone could have been used. Lastly, there was a fresh pdf exploit that could have been used to infect PC's.

The One that Got Away

Yesterday, I speculated that LinkedIn could be used as an attack vector for a phishing attack. Although it's interesting to try and theorize how an attack could take place it's even more interesting to hear first hand how an attempted phish did take place.

Within hours of reading my blog post, Matt Hartley, responded with a first hand account of how he almost fell victim to such an attack. Fortunately, he was the one that got away and didn't take the bait. Perhaps people think of online scams as being ridiculously obvious such as being written in capital letters, referencing obscure countries they've never been to and the chance of obtaining millions of dollars of inheritance. In reality they can be much more sophisticated.