The Best Defense Makes a Good Offense

During the process of evaluating corporate security products, I often begin thinking about how to circumvent the features of the product. More recently, I have started to think about how to leverage the features of products to attack the defender and organization. Since my coding skills are a bit behind the times (ancient really), I quickly took the route that many attackers take. Spear phishing. There is little doubt that spear phishing is often the path of least resistance and is still highly successful. SANS described it as the "...primary initial infection vector used to compromise computers that have internet access." in the Top Cyber Security Risks published in September 2009.

It is not inconceivable to suspect the success of email phishing correlates closely with the quality and familiarity of the email the intended victim receives. The more convincing the email, the more trust the recipient will have when clicking on a link or attachment within that email.

So I thought I would play the evil attacker and post some examples of emails that a corporate end user might receive from a security product that they know and trust. What better software than a product designed to thwart spam and spear phishing? The following is a notification a user of Postini Anti-Spam services would receive (with some href attribute changes of course);

YourATarget Inc's junk mail protection service has detected suspicious email message(s) since your last visit and directed them to your Message Center.

You can inspect your suspicious email at:

 https://login.postini.com/exec/login?email=user@youratarget.com

Suspicious email is kept for 14 days, after which it will be automatically deleted.  Please visit your Message Center to delete unwanted messages and check for valid email.

For help accessing and configuring your Message Center:

http://www.postini.com/services/help.html

Thank You!

YourATarget Inc

Staying with that theme, Postini also provides an email encryption portal that will encrypt an email and send the recipient a notice.

You have a Postini Secure Email message from user@yoruatarget.com.

To view the secure message, click here.

Do not reply to this notification message. This notification message was auto-generated by the sender's security system. To reply to the sender, please go to your secure message by clicking on the link above.

While there is some irony in using notifications from security products to phish and even more in the fact I was able to sent my spoofed emails through Postini's anti-spam filters unscathed. You could certainly leverage the familiarity of any enterprise application for offense. Some other possibilities include email notifications sourced from a helpdesk system, collaboration software (i.e. Sharepoint), or from email servers warning about size quotas. You can certainly apply these ideas to other attacks too. For example consider the following default Web Filter warning that could be leveraged during a Man-in-the-Middle attack.

Please note I have nothing against Postini or similar products. It just happens to be a product that I am familiar with and is quite popular. I am curious on what examples others can come up with. The Social Engineering Toolkit (SET) just released a new version and it is a great platform for testing the success of phishing attacks. It includes built in templates or you can certainly enter in your own custom email. Happy phishing!

Is a Warning a Mitigation?

On Friday the good people at The Internet Storm Center posted some notes on a readers experience with a recent targeted phishing attempt of his corporate OWA (Outlook Web Access) users. The email used to target the end users is convincing. It explains that their mailbox settings have been changed due to a security update and includes a hyperlink to what appears to be an URL residing on the corporate domain. Once clicked, the unsuspected recipient is brought to another site that offers up an executable containing the ZBot Trojan.

Soon after reading the post, I chatted with a few people who stated that they too had witnessed this attack at their place of employment. None of this is very surprising to me, except that it does not seem to occur more often. At first glance, one might be inclined to believe this is a low risk attack vector. It's just OWA right? I disagree however. Many organizations allow OWA untethered from the internet. OWA runs on Microsoft Exchange which indicates it is a Microsoft Active Directory environment. In almost all cases OWA is using the same login credentials that is used to authorize the access to corporate resources such as Windows end nodes, file shares, VPN's, databases, and web applications. It is the "keys to the kingdom" if you will. Combine this with end users running as local adminitrators and there are multiple opportunities for compromise.

OWA has been no stranger to vulnerabilities in the past. An URL redirection vulnerability affecting Exchange 2003 has gone unpatched and almost unnoticed by many Exchange administrators for years. With the exception of some frustrated forum posts from a handful of systems administrators and security practitioners, there seems to be little mention of the issue. The user is presented with the organizations OWA login page and after providing credentials is redirected to the attackers server. An example of the redirected URL:

https://[victim]/exchweb/bin/auth/owalogon.asp?url=http://[attacker/file.exe]

Such vulnerability would only make the aforementioned phishing attempt more effective. The Open Web Application Security Project (OWASP) recently released release candidate 1 of the The Top Ten Critical Web Application Security Risks of 2010. Number eight on this list is  UnvalidatedRedirects and Forwards. To quote the summary of this risk:

"Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages."

Again there is no official Microsoft patch for the issue but the aforementioned OSVDB link does contain a comment describing a mitigation tactic. By hard coding the redirectPath variable in login.asp to you company's full URL path for the locale you’re using, you can prevent the redirection. It should be noted however the redirectPath should be hardcoded in each of the locale's being used (i.e. language set in the user’s browser). While Exchange 2007 is not affected by this example it is affected by a similar URL Redirection described here. Upgrading to Exchange Service Pack 1 or higher fixes the issue.

So I am not sure why I was surprised when I recently received an email from one of the email lists I subscribe to. In it, Dan from http://www.madjic.net/ describes a similar redirection issue with Exchange 2007 SP1. He had verified that with some modifications, URL redirection is still possible via:

https://[victim]/owa/[user]@[victim]/redir.aspx?URL=http%3a%2f%2f[attacker/file.exe]

One would need to include the victim's login name but this would be trivial since in many Exchange environments the email address is the same as the Windows username. Now here is the rub. Once redirected the end user is presented with the following warning:

So my question is this; is a warning a mitigation? (Please comment as I am truly curious on everyone's opinion on this) While certainly an improvement, I would not consider it a fix or mitigation. Users have a tendency to click through warnings. SSL Certificates are a great example of this. This actually reminds me of another Microsoft mitigation from almost a decade ago (I am dating myself now).

This warning was included in Outlook 2000 Service Pack 2 and above and was a direct result of worms such as the ILOVEYOU virus which leveraged VBA in Outlook to spread to the others in the victims contact list. Did it stop the propagation of such malware?

Certainly properly architecting OWA and placing it behind a proxy with appropriate ACL's that restrict outbound connections would be a better solution than a warning. This may not be feasible for small businesses, however. End User education is always a must but with spam and attacks becoming more streamlined and targeted this is not a realistic solution in itself. I purpose the better solution would be to provide systems administrators with an easy way to turn redirection off (that is a hint Microsoft). Hey let's get a bit crazy! Let's make the default setting be disabled.

I think most of us understand the concept of the path of least resistance. Attackers will always take the road that is less bumpy. History has proven that phishing, is one such avenue. Many attack vectors have come and gone but yet phishing attacks still exist. Let’s not give the bad guys anything that is going to make their jobs any easier. Now go forth and mitigate!