Since it’s impossible to verify whether the torrent of Snowden ‘revelation’ excerpts we have been shown are genuine or accurate, as the reporters themselves have opted to redact anything of use to security researchers, I’m going to base this post on the assumption that some pretty serious malware is for some reason evading signature-based anti-malware systems when it shouldn’t be, and a huge part of the problem to begin with (as Mikko Hypponen pointed out at TEDx) is that society has given up control of the software they use, and has (mis)placed far too much trust in commercial entities to protect their personal information.
I recommend giving my earlier posts on this a once over for a primer on Linux rootkits. My point is that, sophisticated as the Linux operating system is, there are certain places a rootkit must hide, and certain things it must do to hide itself. It’s near impossible even for the NSA to install and run persistent malware on a target system without detectable changes being made, unless we’re talking about really low-level stuff like BIOS and EEPROM malcode. We can sift through a Linux system for traces of malware activity, in a thorough, reliable process that works independently of third-parties or signature databases. Of course, it’s like searching for a needle in a haystack, and this is where the rootkit detection programs here come in.
I should mention that certain Linux-based products, such as the recent Amazon Kindles and some Android phones, are supplied with vendor-installed rootkits. There’s not much that could be done in this case without rooting the device.
One method, which should have a detection rate of around 99%, is to stick a box on the local network running a packet capture and analysis program (like Wireshark). The idea behind this is that a Remote Access Tool must send the infected system’s IP address in order for the attacker to communicate with it, unless the target has a static IP address. This is sometimes referred to as ‘beaconing’, and the packets generated would be broadcast around the local network and picked up by the packet capture system.
However, this method only indicates that a system might be infected. Actually finding the rootkit on an infected system is more tricky.
First up is the Rootkit Hunter, and as the name suggests, it hunts for rootkits. The standard check, using the
#rkhunter --check command, does the following:
* Scans files in /bin and /usr/sbin
* Scans for known rootkits and malicious kernel modules
* Checks network interface and ports
* System boot components
* Checks for anomalies in user accounts, file permissions and password changes
The full scan details are recorded in /var/log/rkhunter.log.
Since rkhunter performs some comparisons with a data file, it should be updated occasionally with
The unhide utility primarily looks for discrepancies between /bin/ps and procfs, system calls and kernel components. Any mismatch indicates that a process is being hidden, which is a telltale sign of a rootkit infection.
It can also be integrated with integrated with rkhunter, so that’s another reason to install both. As with rkhunter, the results of unhide scan could be dumped to a log file with the -f option.
A collection of executables that perform a quick (and most likely less thorough) scan of the system, which might pick up something overlooked by the previous two programs. It does the following tests:
* Modified or replaced system binaries
* Network interface activity
* Log deletions
* Comparisons between process data in /proc and user-space
* Strings associated with malware
In addition, chkrootkit could be run against a static installation from another booted OS, making it a useful tool in a rescue CD.
Warnings and False Positives
False positives are almost inevitable, so if there are warnings, don’t panic. Stay calm, Google (or rather IXquick or StartPage) whatever’s been flagged and look at whatever files the scan points to. System updates and some legitimate software applications will trigger false positives – the Java Virtual Machine, unhide.rb and sysinfo.procs did this on both Linux machines I tested.
In the event there is a confirmed rootkit/malware infection, the system has been compromised and should be treated as such. Personally I’d make sure my important files are backed up, nuke the current installation and create a fresh one. It’s unlikely that any non-system file in the home directory would present a risk on a Linux system.
Never rely on just one of the anti-malware programs I’ve mentioned, but instead perform regular scans using all three (not simultaneously), and always be prepared to re-install everything from scratch if a rootkit infection is confirmed.
Prevention is the easiest solution – removing unnecessary services and programs from the system means fewer potential vulnerabilities to exploit, and incidentally that makes patching quicker and easier. These measures alone will vastly reduce the attack surface.
We could add another layer of security that might prevent an attacker running an exploit against any remaining vulnerabilities in a similar way Microsoft did with Windows Vista and NT 6.1. Have a look around for stuff like AppArmour, stack protections and Security Enhanced Linux (SELinux). Ironically the latter was largely developed by the NSA.