Why rootkits targeted at Red Hat Enterprise would make me especially nervous

November 28, 2008

A while back, I wrote in passing that I would be especially nervous if I ran across a rootkit that specifically targeted Red Hat Enterprise systems (for example, to the extent of corrupting the RPM database checksums). Today I feel like elaborating on that.

(Right off the bat I'll say that it's not because we use RHEL here. Our use of RHEL is small and so far none of it is in machines that are particularly exposed to users or the world.)

What would make me nervous is that the population running RHEL is both rather small and rather selective; it is almost entirely commercial enterprises with real money to throw around (RHEL not being cheap). This means that a RHEL specific rootkit is specifically targeting companies, which means that it is likely being used by people who specifically intend to exploit companies of reasonable size and prosperity, not just whatever random machines that they can get their hands on.

(I admit that the existence of CentOS may throw a spanner into this theory, although it depends on how specific the targeting is.)

Crackers are up to no good generally, but people who target reasonable sized companies are up to a whole new level of no good and are correspondingly much more serious about the whole business. Since there is more work and money (and risk) involved, my belief is that it is much more likely that the people involved will be dangerously skilled attackers, people who are at least as clever and knowledgeable as I am. (And probably significantly more clever; they likely do this for a living with serious money involved.)

This doesn't mean that we're being targeted by such people. But it does mean that when they build rootkits, they're likely to build very good, thorough, sophisticated, and hard to detect rootkits. So if there's ever a RHEL rootkit that's going around, I'm going to have to assume that it's a really good one, skip all my usual measures, and go straight to the painful things. And that assumes that we detect the compromise in the first place, which is probably unlikely.

Written on 28 November 2008.
« The practical insecurity of self-signed SSL certificates on the web
Good editors aren't better or worse, just different »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Nov 28 00:01:23 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.