Friday, July 15, 2011

Do you really trust that certificate?

If you've read many of my posts on this blog, you've probably realized by now that I'm lazy when it comes to dealing with malware. I hate the "whack-a-mole" game of trying to stay on top of every new thing every new piece of malware does - not only because it'd keep me busy 24/7 if I tried to do that, but also because Snort would end up without particularly useful coverage anyway even if I (and a hundred of my closest friends) did.

With that in mind, I was pleased to add SID 19551 - "POLICY self-signed SSL certificate with default Internet Widgits Pty Ltd organization name" - to our last rule release (Issued on 2011-07-14). On the surface, it doesn't seem like it's related to malware at all - but if you'll give me a moment to explain, you may find yourself turning it on in the not-too-distant future.

The thought process behind it started with the barrage of requests I've received recently for coverage of the "indestructible" TDL4 botnet. One requester was kind enough to supply this excellent analysis from SecureList.com, which provided a list of recent C&C servers for this particular botnet. Armed with that information, I was able to go query up my malware sandbox, which had dozens of recently-run samples ready for analysis.

Sifting through the traffic, I noticed that, in addition to the custom encryption described in the analysis I'd read, successful connections to the C&C servers were starting off with SSL-encrypted traffic. Most people would be disheartened at the sight of this; I immediately zoomed in and looked at the server certificate, hoping that the botnet authors had used a unique Common Name in the certificates that we could use for an easy rule. Unfortunately, they had not; instead, they'd used the default option for a self-signed certificate, "Internet Widgits Pty Ltd".

As I sifted through the rest of the PCAPs, hoping to find a quality pattern, it dawned on me that even using the default option from a self-signed certificate was a useful indicator. Sure, most IT administrators use self-signed certs on their internal gear, and even some cheap administrators of low-traffic, public-facing sites will use them too (::looks at 21-year-old self::). Any serious, relevant site that uses SSL will have a validly signed certificate from a trusted CA - and even the cheapskates out there will usually set a non-default name on their self-signed certs.

With that in mind, we've made this rule available, just in case you agree with this logic and want to give this method of detection a spin. The rule is of course off by default, given that it could generate a substantial number of false positives (we'll be eager to get feedback from the field on just how many it generates, and what the ratio of useful-to-garbage alerts actually looks like). If you do decide to turn it on, I would recommend also checking that you've enabled SIDs 19496 - 19550, which look for DNS queries for the TLD4 C&C domains listed in the report I referenced above. If you see the two fire in rapid sequence, well, chances are real high you've got a problem on your hands.

P.S. Seems the good folks at Netresec.com had a similar idea the just a few days before we published that rule. I promise we didn't steal from them, it's just that great minds think alike. ;-)

No comments:

Post a Comment