So let's see... the ASN.1 vulnerability allows an attacker to gain admin access via a port that's enabled on most firewalls going to web servers. The bagle, mydoom, and netsky variants so far have been little more than a nuisance. The key difference between the rash of virii over the last few months and the ASN.1 vulnerability is that the viruses a) have very little impact and b) are easily mitigated. They install an smtp engine to spread themselves and they open a backdoor port. (Yes, there are two exceptions: Mydoom.f deleted MS office related files, and the latest bagle variants facilitate the spread of the phatbot trojan. Those are the only two exceptions to my knowledge.) That's it. Lets' look at the actions that can be taken to mitigate these threats, and that should be taken in the first place: first, the built-in SMTP engine. Either you have one or more mail servers on site, or you don't. If you do, chances are you know what their IP's are. If your corporate firewall is lettling SMTP traffic out from any host, then you're letting any machine on your network become a spambot. Then you have the backdoor ports. 3127, 2745, and now 2556. If you're letting incoming traffic through on those ports to any host without a business need for it, you're inviting attackers and other worms to exploit those backdoors. Not only that, but those backdoor ports make it simple to find infected machines, in case your AV software has been knocked offline. A quick shell script to scan my subnets for those ports runs every morning and lets me know if anything got poast our other measures. Compare all of those mitigations to the ASN.1 vulnerability. The two mitigating actions are 1) Run the patch, and 2)Disable SSL and RAS on Microsoft web/VPN servers. ANd here's the biggest problem with that vulnerability: it existed for 6 months before it was patched. For all we know, Mr. Mullen's client could have had the ASN.1 vulnerability exploited, and he could have a rooted machine running. Just because an incident is loud doesn't mean it's critical.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/225/25408#25408