Slashdot Mirror

Do you really think that the makers of an operating system which requires 3rd party AV to correct its own security shortcomings devised secure boot to protect users from malware?

You mean the Linux folks designed UEFI Secure boot?

http://www.rootkit.nl/projects/rootkit_hunter.html

I repeat it again, If you want to secure the bios put a jumper before the write pin of the eprom/flash memory/whatever. Those who can't open the case and locate it are surely not qualified for a bios upgrade.
I made one firmware upgrade in the last 15 years on my machines, and that upgrade was necessary only if I wanted 64bit linux.

Secure boot is not about the BIOS, it is about bootkits. You don't know what you're talking about and still get modded +4 interesting, typical Slashdot, really. See below for an example.

TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

Another bit:

The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.

Traditional rootkits exist for most unix systems, although they typically do not spread on their own - someone has to manually root your system and install them. There are even tools dedicated to finding/removing unix rootkits, eg http://www.rootkit.nl/projects/rootkit_hunter.html has a long list of rootkits it knows about.

Ahem. Rootkit. It's not called that because Windows got 'em first.

Heck, there are even tools that deal with *NIX rootkits and the like. Several of them, in fact.

In addition to the other tools mentionned by /.ers, there are 2 root-kit checking tools that are worth mentioning :
- chkrootkit
- rkhunter

They are scripts that scan the system for known root kits, weird behaviours and hidden files in unusual places.
They can both be used to scan an offline system (booted from a live-cd and the system mounted under some directory),
and a live online system (they check the system for suspicious behaviour that may reveal a root-kit trying to hide it self - for example the "ps" command doesn't show the same processes as the "/proc" directory could mean a root-kitted "ps").

They are available in a lot of distributions (Debian Etch has them in the repository - probably the corresponding Ubuntu has them too) and the packages usually come with "cron" entries that can automatically scan the system and email a report to the administrator.
They are also downloadable and installable from their websites and feature configuration files that cover the most frequent distributions.

You should install them, run some initially check, (eventually edit the script to remove some false positive, i.e.: hidden files about which the script complains but which are normal part of the system), and add crontab entries to do daily checks and e-mail you positive results.
This will help you against having your server rootkited.

-----------------------

Another tool worth mentioning is ClamAV.
That's an open-source signature-based virus scanner, whose maker have been praised for their very fast response time in case of new emerging threats.
You could set it up to periodically check files in the directories that are served. (/srv/www, /srv/ftp, etc.)
The scanner is not very fast, but supports some specialized-hardware acceleration (it might be worth considering it if the server is rather important, and gets significant mail-traffic too). Some teams are also working on GPGPU hardware acceleration (mentioned in nVidia's book "CPUGems 3").

This will help you get some protection against website that you're hosting that may have been hacked into (with bugs in PHP pages, for exemple) and are now serving malwares.

-----------------------

Because the way malware evolve, you may have to upgrade the above softwares to later versions than those shipped with your OS.
Some distribution propose it in their security updates.
For Debian, keep in mind that this kind of "later version requirement" packages go in the "volatile" repository and not the "security" one, modify your sources accordingly.
("security" : we keep the exact same version for stability reasons and only patch critical errors.
"volatile" : for security reasons, some packages (mostly various scan engines) may require updating to a later versions.
"volatile-sloppy" : warning, the packages are really different. b0rkage of config files may ensure (mostly software like gaim/pidgin).

This is a page with a top 100 of various security tools which may also inspire you (for example they mention a webserver scanner called Nikto).

Also, always keep in mind that a compromised machine is not a machine that you can trust. Thus in addition to creating new entries in you crontab, you should also test your machine offline as part of the security checks.
For example, occasionnaly, when you have to take your server offline for planned updates (rebooting to newer kernel version or non hot-plugable hardware upgrades) you may want to scan your system while booting on a LiveCD in case the root-kit are efficient enough to go undetected once they are active.
(That is, if the conditions allow you to perform such a scan : the machine is physically accessible, you can plan in the

Oh.. well I guess rkhunter http://www.rootkit.nl/ does not run on Windows. Nevermind. :-(

apt-get install chkrootkit rkhunter

Instead of windows they could switch to Linux or a *BSD or MacOS.

Oh wait, almost all OS's out there right now have rootkits for them.

That's a bit silly. There have been tons of local and remote holes in Unix-like OSes. rkhunter is the first example of Unix "anti-virus" software that comes to mind.

RKHunter is another good RootKit checker for your Favourite Unix flavour.

http://www.rootkit.nl/projects/rootkit_hunter.html

And there's also root kit hunter. Be interesting someday to see a well written comparision 'twixt chkrootkit and rkhunter.

Initial reading implies rkhunter is, "...more user-friendly and comprehensive...". See This PDF (Dealing with Rootkit Attacks on Linux).

Don't forget RootkitHunter, which has a much more active development cycle going on at the moment. Not that chkrootkit's any less useful; use both; don't trust either too much, though!

If you're aware of any real rootkits spreading for OS X, let me know, I'd be interested in hearing about them.

In any case, the Linux/BSD Rootkit.nl checking tool has been available for OS X for a long time now, if you're genuinely concerned or looking for another layer of security.

Download ROOTKIT HUNTER now.

run 'rkhunter --update'

run 'rkhunter -c' and scan your system

when rootkit is found, reinstall OS, and restore critical data from backups

Everyone's posts are pretty good, but don't forget about rootkit hunter. Oh, this isn't a configuration tool, but it's good to make you sleep better at night.

Another good rootkit checker, which seems to have a more active development cycle, is Rootkit Hunter. Here's a Newsforge article on it, with a few more details.

A few other comments:

Virus scanners won't help on jot against a custom hack (as Valve found out, for instance). They can be helpful, but don't put full reliance on them.

Running an Intrustion Detection/Prevention System such as Snort, Samhain, Prelude, etc. will help you manage the monitoring side of things; more than a few machines becomes a pain without additional help. Also take a look centralising all your logs on a syslogng server or something similar, if you don't already (note that there are various solutions out there to get Windows boxes to log to a syslog server).

A honeypot may distract the hacker from your production servers for long enough for you to identify that there's a problem.

Also take a look at "HoneyTokens": specifically created database records that trigger alarms if they're accessed - usually high profile fictious targets that would make excellent trophy hacks - there's more info on this over at SecurityFocus.

If you suspect that a machine has been compromised, as other have said, the ONLY WAY TO BE SURE is to rebuild the box from scratch. While this may be a real pain, hopefully it'll help you get the procedures in place to make this as painless as possible, so it's not all bad.

Perform security audits/pentests every now and again. Tools like Nessus help: here's a good series on using Nessus (part 2, part 3).

Get familiar with security tools such as the top 75 recommendations at Insecure.org (home of Nmap).

Remember that security is a PROCESS, so be thorough; get an entire plan together and cover all the bases that you can, taking special care to identify and cover the weak points. Your company's security is only as good as its weakest link; for instance, priviledge escalation of weak user account passwords is a good one.

Read SecurityFocus, PacketStorm, CERT and the like, and try to get involved in their communities; they can be invaluable! They're also got a lot of good tutorials, such as how to lock down Apache, IIS; securing PHP, ASP; etc.