Slashdot Mirror
No Defense Against Windows Rootkits?
An anonymous reader writes "Spyware bad guys (and also phishing people) started using rootkits technology to stay hidden in a system. The problem is that at the moment the technology to defend a Windows system from these things is very poor. In fact antivirus companies have just started adding basic anti-rootkits technology. So the problem is serious, and well outlined by this question: Is the closed source code of Windows preventing us from actively defending our systems?"
.. RootkitRevealer is your friend.
Let us not forget the wonders of ActiveX controls not to mention IE's ability to install items with out authentication. As far as that is concerned ANY installer should have to be authenticated as an ADMINISTRATOR before the install can proceed. I think this small step would curb many of the issues with spyware, adware, toolbars, etc.
Right. We should rename them, "SystemKits".
(For those who don't get it, "System" is a login with higher privleges than even Administrator. There's nothing that System can't do. Just to brighten up your day, it's also the default user for Windows Services. Feel safe yet?)
Javascript + Nintendo DSi = DSiCade
Strider Ghostbuster,, a Microsoft developed technique for detecting all persistant and stealthy rootkits .
Just convince Microsoft to make it available.
There is also SysInternal's Rootkit Revealer, which although not quite as general, is still hard to fool.
Test your net with Netalyzr
" They've been dealing with rootkits seemingly forever. How did they manage?"
t ations/i002.02.html
tripwire - there's a commercial version available, and I've used the free version. Creates checksums to compare your system against...
A brief description here... (with download and install instructions)
http://www.cert.org/security-improvement/implemen
Sam
http:/// www . iamsam . com
I administer a network with about 50 workstations. We run Windows2000 with Symantec Anti-Virus Corporate (aka Norton). Symantec registered an internal attack by a root kit only two weeks ago. This stuff is in the wild now!
Yep, all servers i've built which use Linux which are accessible from the outside do not have loadable module support enabled at all.
It prevents a large swathe if not all rootkits from running.
This is one of the areas where I think Linux (and open source software in general) has closed source software beat, you can easilly customise the kernel to your own particular situation in which the machine will be running. Being able to have your own custom built kernel with stuff like grsecurity etc is invaluable.
Yes, Microsoft has a Shared Source program. I'm not 100% sure of the exact requirements to join the Shared Source program (you could look it up on their website I'm sure) but the requirements are fairly hefty. You have to sign some pretty thorough NDAs, of course. To the best of my knowledge, an individual acting by themself rarely gets access, although I'm pretty sure that several book authors got access to Windows source. Companies can gain access, but they normally have to pay for the priveledge (if you recall the Win2k source code getting lose a year or so back, that was on account of a company that had purchased a liscense to the code losing it). A large number of Universities have access to the code, as do governments and government contractors.
Yes, you can, and it's even recommended.
/bin and /usr/bin on some ro media (either a CD or on a seperate server mounted ro), and checking them ageinst you're working copies regularly. :-) /tmp and /var (not to mention /home) but this will defeat 99% of the automated root kits, of course, if the attacker gets in personnally, all bets are off...
Other steps you can take are :
-not having dev tools installed on your servers (quite often source root kits require them)
-keeping copies of
-running chkrootkit
-Mount / ro. You need to set up seperate space for
The Unix folk - Ritchie, Pike et al ditched Unix and root years ago and made a new system plan9 (though Ritchie was, by his own admission, more a famous name than an architect in plan9 - though he did do the compiler)
Spending years being not-free as in beer, plan9 languished during the Linux FOSS years until belatedly being opened up for version 3
Then Lucent lost loads of $$ in the dot-com crash and wound down Bell Labs (such as taking out every other light bulb) and the staff retired or left (mostly to Google)
as Rob Pike said "Not only is UNIX dead, it's starting to smell really bad." - circa 1991
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
So when my mother, who uses her computer for playing bridge online and printing e-mail pictures of her granchildren buys a new printer, you think she should have to recompile her kernel.
On sane operating systems *cough*Linux*cough* printer drivers aren't kernel modules - they don't need that sort of low-level OS/hardware access. Of course, it'd still be an inconvenience adding other hardware, but that's not a good example. With Linux, newbies at least will probably only want to run the kernel modules their distro supplies, so why not have a list of valid modules and their checksums loaded at startup, and refuse to insert a module that's not on the list?
Great advice... some other things you can do:
/tmp and /var with the noexec option - if you have developers who don't understand security, this can save your bacon. (someone used a hole in a PHP script to upload and execute a file to /var/tmp - the upload happened, the execute didn't. I ended up with a copy of the rootkit (fairly new at the time) as well as how he got in, which was shown to the web developer responsible in an attempt to get him to take security more seriously.)
mount
use a separate account for each daemon (some distros I've seen run apache as 'nobody', for example - don't use 'nobody', create a separate user for each daemon) This prevents your daemons from overwriting each others data, and allows the following:
use --uid-owner and/or --gid-owner in iptables to restrict your daemons from opening *outgoing* connections, or listening on random ports. If one of your daemons is compromised, it makes it harder for an attacker to connect to take over complete control.
Never have executables or data owned by the same user that the daemon runs as. I've seen this done mostly on game servers (the docs recommend running the game as 'unreal', and have all the game files owned by 'unreal') but some others (squidGuard comes to mind) also recommend (or even require!!?!?) having data files owned by the daemon. If there was a hole in the daemon, an attacker could theoretically use it to gain higher priveleges (such as the UID of the account used to start the daemon - frequently root) the next time the daemon is started.