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!

Forecast: Cloudy with a Chance of Low Visibility

Now that I have had a chance to re-coup from Shmoocon and the associated Shmoosnow Apocalypse, I wanted to get this post up. Great CON BTW! If you have the chance to go in the future, don't hesitate!

In December, I began noticing an uptick in scans looking for TCP 1080 (socks proxy) on my corporate firewalls. Not that unusual. But by New Years Day the scans began accounting for a large percentage of all deny's logged to my syslog servers. After some investigating, the fact that all source IP's were registered to Amazon's Ec2 Elastic cloud services became apparent. Egress filtering did not indicate any outbound connections to the IP addresses in question.

So began my adventures in reporting the issue to the Amazon abuse black hole. I initially reported the top source offender via ec2-abuse@amazon.com on Thursday January 7, 2010 and "promptly" received the following email on Monday January 11th.

Please file a report at
https://www.amazon.com/gp/html-forms-controller/AWSAbuse/

It is possible that the activity you see comes from an Amazon EC2 instance. This activity that you report was not, however, initiated by Amazon.

One of the biggest advantages of Amazon EC2 is that developers are given complete control of their instances. While the IPs may indicate that the network is Amazon's, our developer customers are the ones controlling the instances. You may learn more about EC2 at http://aws.amazon.com/ec2

That said, we do take reports of unauthorized network activity from our environment very seriously. It is specifically forbidden in our terms of use.

In order for us to identify the actual customer, please provide
* src IP
* dest IP (your IP)
* dest port
******************** Accurate date/timestamp and timezone of activity**************************
* Intensity/frequency (short log extracts)
* Your contact details (phone and email) Without these we will be unable to identify the correct owner of the IP address at that point in time.

Thank you

Best regards,

-EC2 Abuse Team

I obliged but cursed as I fought to fill out the report on the badly designed web form which kept throwing vague invalid input errors. The forms purpose is to facilitate the reporting of abuse between the reporter and Amazon EC2 customer while keeping both anonymous. So I attempted to keep a positive outlook with the hope that my time may assist an Amazon EC2 customer with a possible compromise.

After a week of no response, I followed up with their follow-up form located at here. During this time the scanning for open proxies on my firewalls had escalated and was accounting for more than 30% of all daily denied connections. So I began submitted the top source IP's (all Amazon EC2 addresses) with the associated logs. To date I have not received one response from any submissions.

So I wanted to share the breakdown of 30 days of logs acquired from my production firewalls. Destination port TCP 1080 made up 35.7% of all denied connections during the month of January 2010 (see breakdown of ports below).

Of those connection attempts, 43.7% of all source addresses resided from the same 10 addresses which were all registered to Amazon's EC2 Cloud services. All source addresses checked from the remaining sources were also registered to Amazon Ec2 Cloud services but for obvious reasons I did not check every source address. The amount of connection attempts has dropped since the end of January but are they still occurring at a good clip.

Others have noted abuse of Amazon EC2 cloud services in the past. Brian Krebs formerly of The Washington Post and now at Krebs On Security wrote about his experience with spammers leveraging Amazon EC2 services in July 2008. More recently, Amazon was found hosting command and control servers for the Zeus botnet. And while editing this post yesterday, I came across this article at ZDNet UK on subject. The article contains some good quotes from Rik Ferguson, Senior Security Adviser at Trend Micro.

"One of the things that persuades me personally that the cloud is absolutely a viable model and has longevity is that it has already been adopted by criminals," Ferguson said. "They are the people who are leading-edge adopters of technology that is going to work and going to stick around for a long time."

 "But now that criminals are moving into cloud services, what are you going to do? Block EC2 [Amazon Elastic Compute Cloud]? It becomes very much more difficult and I think that is an area that security companies and security professionals need to focus on."

Every ISP and ASP out there has to deal with issues similar to this. Let's face it the problem is not going away anytime soon. However, with the loss of visibility associated with the dynamic nature of cloud services, attractiveness of easy provisioning and setup for the non-technical, and the service providers desire to provide privacy for its customers, cloud services are certainly ripe for abuse. Let's hope providers, such as Amazon, can find a happy medium of providing needed services and privacy for its customers while offering others an effective mechanism for reporting and deterring any misuse and exploitation.