One of my HIPS rules specifically blocks any access to a *.torrent file, for obvious reasons. Going through my HIPS logs today, I see the following event:

It’s fascinating to think that WoW uses bittorrent to manage itself, just not on one of my work machines, thank you very much.

I used to use Boxtrapper to control who could send email to an uber-secret email account, that Wordpress would check and post any email in that account.

For some reason my hosting service removed Boxtrapper and of course the spam found my inbox and was subsequently posted here on my blog.

To replace Boxtrapper, they’ve provided generic message control filters, so I set up a rule to allow email from my email accounts as the first rule and the second rule is this:

where from matches regex ‘.*’ bounce

So now if you aren’t on my approved list, you’ll get an NDR that simply states:

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

This will do the trick, at least until my provider decides to pull the plug on their message control filters.

Thanks again to every who notified me using Twitter, email, and my contact page on the blog and a big thanks to Martin McKeay for a very effective and creative way of getting the word to me. Good lookin’ out.

Belay on.

Thanks to everyone who let me know about the blog spam. I believe it is coming in through the post-from-email feature. I don’t have time right now to dig into it, I’m off to get belay certified, but I’ve disabled that feature. Hopefully that puts an end to it.

Thanks again.

Take ‘em for what their worth; this is a collection of events logged from 277 hosts located in 12 different office locations with five unique, central AV servers managed by five different IT departments.

The statistics have been collected over 11 days:

The failure to open a file is attributed to, according to the event log, “extraction errors encountered by the Decomposer Engines” which I assume are the engines that translate the file to something the AV software can scan, whether the file is an executable file, compressed file, text file, etc.

Now, is it really possible that on 277 laptops there have only been a total of 7 pieces of malware that have made it all the way to the machine? I’d love to say this number is accurate and the result of defense in depth, but I’m not ready to say that just yet.

What countermeasures do we have in place that would help?

1. Strict email attachment filters based on file extension alone
2. ‘Course grain’ AV at the spam gateway, before the email hits our servers
3. ‘Fine grain’ AV at the email gateway before the email hits the inboxes
4. IPS units protecting web browser attacks, but only while hosts are on our network
5. Behavioral HIPS on all laptops

Does that battery of defenses look like something that could reduce the number of threats that make it to our laptops to only 7 in 11 days for 277 hosts?

That’s a pretty good success story if its true. However, given that we have 1,253 cases of a failure to open a file, we have possibly 1,253 additional viruses that we can’t detect, not to mention the 969 alerts that the AV software is failing to auto-protect some hosts.

But as my grandpappy always says; if it seems too good to be true, it likely is too good to be true.

*The AV software logs multiple events on a single host, therefore I’ll have to distill these events to find an accurate count of the number of unique hosts or files affected.

Am I being Chicken Little in thinking that remote kernel attacks such as one leveraging the MS08-001 vulnerability will be the next chapter in the arms race between hackers and network defenders?

Alex Wheeler, one of the two responsible for discovering and researching the vulnerability said this; “This is a severe vulnerability across the board. I agree with Microsoft that this is critical and wormable.”

Holly Stewart of ISS said the following on the X-force’s blog; Frequency X

These issues are kernel-level vulnerabilities in TCP/IP and are so low in the stack that most host-based protection products would miss them. Even if you have IPS in your host product, the standard APIs that protection vendors hook into on XP and Windows 2000 do not provide protection at this low level in TCP/IP.

I usually have a good FUD radar (FUD-ar?) and it isn’t picking up anything on recent chatter on MS08-001. So far I’m hearing specifics on why this is potentially a big deal, not to mention the caliber of analysts chiming in on the subject.

This week I’ve been sending emails to vendors of our various security applications, seeking clarification on what level of protection they provide. One prominent vendor replied with the following:

Based on the information contained in the MS bulletin we are unsure that [our HIPS product] would mitigate against an exploit targetting that vulnerability - that is why its not listed in that particular row [of a spreadsheet detailing protection levels].

The disclaimer in the [snip] document is because there has been no exploit testing. Just because there is a MS vulnerability does not mean an exploit will be written against it or available.

This despite the fact that Immunity has already publicly demonstrated a successful attack method.

Now I’d like to revisit what Holly said; “These issues are kernel-level vulnerabilities in TCP/IP and are so low in the stack that most host-based protection products would miss them.” (emphasis mine)

To me this indicates a significant threat and quite possibly the beginning of a new trend in remote attacks. If I were a hacker, this one would get a lot of attention from me because 1) both XP and Vista are ripe for the picking and 2) it likely gets my code in a position where most security software can’t see or touch it. I’d worm that sucker and use it to deliver my bot and grow a big, nearly bullet-proof bot net that could be diced up and rented to the highest bidders.

Or maybe I’m wrong and the vendor has it right and this is just another MS vulnerability that will come and go. I’m still digging bomb shelters, just in case.