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
Or, if you're running BSD, set kern.securelevel to 1 or 2.
/dev/mem, and if you set it to 2, disable access to raw disk devices.
That will prevent loading new kernel modules (so you can still load them early in the boot process), cut off access to things like
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?
And that's why you apply a few simple security measures, such as denying LocalSystem access to CMD.EXE and other powerful utilities via NTFS permissions. You can do this to bring LocalSystem down to a level lower than Administrator, and virtually nothing breaks if you do it with a little bit of forethought. Yes, it takes a little bit of work to do the initial planning, but once it's done you script it and bingo. And there are plenty of examples on websites of sample lockdowns plus the scripts (using XCACLS.EXE, typically). Take those examples and customize them to your environment as needed -- you've saved yourself a whole load of the initial work.
You can open up these permissions on a system-by-system basis if really necessary, or even better just set applications that support it to use named service accounts. Cuts out a huge number of vulnerabilities.
You can secure a Windows system, and it's really pretty easy to do a lot of these things. You just have to know a bit of what you're doing and be prepared to put in the work. That's the biggest flaw in most MS administration shops: people who shouldn't be admins get lulled into a false sense of security because there's a pretty GUI and they don't understand what's going on behind the scenes.
Wouldn't a firewall (e.g. Zonealarm) pick up and/or block the outgoing traffic?
Not if the rootkit binds to the network interface at a lower level than the firewall (i.e. traffic between ZoneAlarm and the interface passes through the malicious code, not the other way around). If it does that (which *is* possible IIRC - I think kernel-level/ring 0 code is required though) the firewall won't detect or block the traffic, because it won't see it.
> System (more accurately LocalSystem) can't access network resources.
Hahaha, I see you have little understanding of Windows.
System can load device drivers, and access ring 0.
System can do anything it wants, including working with any and all network connections already running, and grabbing any kerberos tokens present on the machine.
I grant you, it would take writing actual code.
Maybe you meant, System cannot access network resources as long as System doesn't do anything bad.
But, of course, if we assume nobody is bad, we don't really need security anymore now do we?
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.
This is already in development. It's the Trusted Computing initiative, formerly known as Palladium, and it's a very big security effort. The benefit of its features are high: on-board high-speed encryption and authentication, easily available to users. The danger is also high: this is supposed to integrate with Dirital Rights Management and provide hardware level control of access to DVD writers, hard drives, boot loaders, system kernels, and secure operations called from withing software. That means that unless you can get the autohrization and the money to buy a highly authorized key from, say, the Microsoft key provisioning service, you will have difficulty writing and especially publishing open source tools that access those features.