By Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

In yesterday’s post, we discussed the reuse of malware. In today’s article, I want to focus on how botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnets [host recidivism].

The sophistication of the botmasters pales in comparison with the persistence of the problem.  An owner unable or unwilling to secure these hosts affords their systems to be cyber-magnetically drawn into some future botnet.  Call it magic or fate — no compromised system just sits there and serves up the connected monitor web advertisements for timeshares and Viagra, without simultaneously offering other services to a Botmaster.  Just because a host has not been engaged in a SPAM campaign or doesn’t have an active keystroke logger installed doesn’t mean that the ability is not resident within the rootkit installed.  In today’s market, ignoring bot earning potential is akin to leaving money on the table, from an organized crime point-of-view. 

A system not patched against MS09-123 is likely not going to be patched against MS10-123.  This is primarily because the decision to patch is most typically made by implementing and enforcing a policy that stipulates the process of perpetual patching for the lifecycle of that piece of software.  The merits of an individual patch and the situational risks surrounding the vulnerability at hand are less likely to come into play since so much software needs patching so frequently.  Modes of interaction of a vulnerability in a distinct piece of software cannot always be anticipated because the instantiations of that vulnerability (no matter how minor) in custom configurations and interactions with other objects are too numerous to fathom. 

End users are not typically engaged in formal policy adherence to their home systems — that is not the claim here.  However, the principle carries forward as those end users who roughly follow a best practice configuration seek out and engage offering by the specific vendors they use, most notably the automated processes allowing for silent and automatic patching of the software.  Whether the software belongs to Adobe, Microsoft or Apple, most major vendors offer means for systems online to update themselves before or shortly after vulnerable binaries are executed by the user. 

These (and formally documented) processes are made for repeatability.  So a missed patch is rarely as much as an oversight as it is another in a pattern of computer activity (really, lack thereof) that’s put into motion by actions that the responsible party made at the original installation of the software, up to and including the OS installed on that host. 

An example shown in a 2008 Computerworld article (“Update: Two-thirds of Oracle DBAs don’t apply security patches” [1/14/08]):

“The results, which come even as Oracle is scheduled to release its next batch of quarterly Critical Patch Updates tomorrow, showed that 206 out of the 305 surveyed said they had never applied any Oracle CPUs.  Just 31 said they had installed the most recent security update from the company.  In total, only one-third said they had ever installed an Oracle CPU.” 

Considering this survey deals with administrators who are skilled in technology, but may be fearful of uptime consequence by introducing the patch, it doesn’t bode well for end users who feel ambivalent towards their responsibility to update their systems.  Whether the cause of the updated state erosion is active or passive, recidivism is high for all of these hosts.

To read the full paper on Kraken, click here.