Download our in-depth report: The Ultimate Guide to IT Security VendorsIve been reading a lot about undetectable malwarerootkits and the likerecently. Without a doubt, these attack tools have been iteratively improving over the years. Like most such security nasties, however, a bit of safe computing goes a long way. Lets explore a bit.
First off, let me explain what a rootkit is so we can consider the facts and not get caught up in the hype. A rootkit is a tool, or (more commonly) a collection of tools, that an attacker can install on a compromised computer. The functionality of rootkits vary pretty tremendously from one version to the next, and theyre available for just about any computer operating system and architecture in existence today.
What they have in common, however, is generally a small set of features: 1) they hide their (and the attackers) presence on the compromised computer and 2) they enable the attacker to log back onto the compromised computer. Most rootkits include tools for removing historical indications the attacker has been on the computer as well, but I think of that as just one aspect of hiding their presence.
A subtle but important issue here is rootkits typically dont have their own collection of tools for providing the attacker with elevated privileges, but they do require those elevated privileges to already be in place in order to install on a victims computer. So the attacker has to somehow get elevated (e.g., root or administrator) privileges before a rootkit can be installed.https://o1.qnsr.com/log/p.gif?;n=203;c=204650394;s=9477;x=7936;f=201801171506010;u=j;z=TIMESTAMP;a=20392931;e=i Ever since I first saw a rootkit installed a computer during a system compromise back in the 1994-1995 time frame, Ive been watching them and following new rootkit technologies as theyve been unleashed. The earliest rootkits accomplished their goals by replacing normal system tools on the victims computer with altered versions. Since most of the early rootkits were UNIX-based, their (altered) tools included login, ls, ps, df, netstat, and so ontools a UNIX user or administrator would routinely run to look at files on a system, processes running in memory, disk utilization, and so on. The rootkit versions of these tools did all of these things and more. Specifically, they carried out the features I described above.
Pretty soon after these started appearing, the IT Security community got wise and started running login, ls, ps, df, etc., from CD so they could be sure theyre using tools that havent been tampered with.
So, the attackers responded by modifying the underlying system shared libraries and leaving the tools intact. So, when ps runs, it returns a list of all the processes on the system, except for those owned by the attackernot because it has been tampered with, but because the system calls it made returned erroneous information.
More recently, rootkits have been installed as kernel loadable modules and such. This has made things increasingly difficult for the IT Security folks to detect rootkits, since they keep going lower (in a software abstraction sense).
In fact, with modern microprocessor technology, any softwarelegitimate or maliciouscan pass along deceptive or erroneous data to software that calls it, so long as it is the first in line. In other words, if your software loads first and intercepts system calls, then you can control what others see. If someone else comes along and can find a way to butt into the line, then they can control what others (and you) see. Thats the nature of the beast, Im afraid.
So what can we do about it? On the surface, the answer is simple (dont run a rootkit or allow one to be run on your computer), but in practice its not quite so trivial. Heres a few things that can help in preventing bad stuff from happening, however:
Of course, those are just a few things that can be done. The list cant guarantee safety from rootkits and other malware, but it sure can go a long way to reducing the risk, if the recommendations are well thought out and implemented.