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
OK so how is this different from netstat -an?
2 74,3275,3276,4500
Listening on a port != rootkit. Windows listens on dozens of ports - some of which you can't switch off without crippling the system.
Mine's fairly locked down, and listens on:
TCP: 135,139,445,1025
UDP: 445,500,1026,1137,1138,1251,1900,2419,2420,3273,3
And that's just the ones listening on 0.0.0.0...
Okay class, let's review.
When you perform any operation on a file system object - getting the contents of a file, size, modification date, etc - you're, after all the layers of indirection, making a system call to the executive. Most real rootkits on Windows NT derivatives are kernel rootkits - that is they modify core system calls to hide themselves and perform nefarious activies - you can't really detect them with something as naive as a file content check.
``It's well known that the *nix operating system model is more secure by default, through good design.''
Is it the Windows design that is insecure, or the implementations? Of course, that begs the question if there actually _is_ a Windows design to speak of. Well, what is there in the APIs that Microsoft publishes that is necessarily insecure, and what is there in the Unix APIs that is necessarily insecure?
I can answer parts of the Unix side; the fact that software needs to be all-powerful to do a single privileged operation (such an binding to a port below 1024). Functions like tmpnam(3), which generate predictable filenames.
Things like the general lack of bounds checking (leading to buffer overflows) are implementation issues, and could be overcome by using better programming languages.
Please correct me if I got my facts wrong.
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
He did mention "normally unconnected read-only media". So you not only put your checksums on these, but also a minimal rescue system, which you boot whenever you want to check integrity of your main system (on Linux, such a system might be a Knoppix CD, for instance...).
Granted, on Windows, this might be a tad more difficult, as the Windows rescue CD's may not be usable enough to run checksumming utilities...
Ok, but Knoppix does support NTFS so just use a Knoppix CD to check your windows checksums. But then another problem on windows is that lots of files do change even during normal operations, so it's difficult to distinguish those changes performed by a rootkit from the innocent changes performed by the system itself because "the mouse has moved"...
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
To reiterate: The name of the game is reduced user permissions. The biggest problem with windows security (second biggest?) is that non doman users are Administrator by default. This means that any vulnerability can be exploited to install files where they should not be.
/windows or /program files, or write global registry keys.
Reduced user permissions (aka: creating a user account with permissions of "User") means that the user cannot install files to
Lets review: Administrator/root accounts have good authentication measures and are not used for everyday use. User accounts have limited ability to foobar your system, and ARE used for everyday work.
Unless you run Knoppix/ubuntu from CD/DVD, in which case just reboot.
http://hxdef.czweb.org/about.php
Yes, taking the system offline with a "rescue disk" and comparing cryptographically-secure checksums against known good values does work. That's the standard for rootkit detection.
However, it's hella inconvenient, on many servers, to boot to a "rescue disk". Do you have any:
- servers that cannot tolerate the downtime required to scan?
- servers at remote locations where you can't insert bootable media easily (CDROM, floppy, etc.)?
- servers or workstations that just don't have bootable media capabilities (headless/PXE boot systems, anything w/o CDROM and floppy drives)?
So while it's a theoretical solution, it's also a shitty solution in practice. How many administrators are going to take the time to take ALL of their servers offline for this kind of review? None, that's right. Because none of their managers are going to be willing to tolerate that kind of expense, effort, man time, and downtime in order to check for something that they can't even understand.
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?
I'm not familiar with Bastille but the Security Configuration Wizard included with W2k3 SP1 does a lot of this. It will help you by identifying services that you can disable, modify the registry to secure the machine and will help build your firewall rules for the things you want to have runnning.
It's not perfect, but it provides a good starting point and can roll back the changes you make. It also creates an XML file with the changes it recommends if you want to simply review it and make any changes yourself.
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.
I've had to deal with a highly infested windows system a few times. There are a lot of ways to deal with it; my favorite is reformat and hand them Mepis (or another easy distro) but some people can't handle that. I had one system in particular I couldn't completely clean up, I had logged in safe mode and cleaned, but there was still something (with no services or processes I could see running) going on. So I grabbed this Rootkit Revealer and it found my problems. It was a cinch to log in under dos and get rid of the problems (although in retrospect I could have used Knoppix or another LiveCD.
So there are good Windows rootkit revealers, you just have to look for them.
"That design being ?"
For one, better user accounts and software that doesn't require root access to run (Windows is just getting there now). For another, better separation of executables making it very easy to lock out system binaries while still giving access to applications (sbin and bin). Let's not forget that with XP Home, Windows still defaults everyone to being an administrator. I think even Pro does that for the first user created.
"On the server-side - and particularly the non-Windows server side - the single biggest vulnerability and attack vector - the user(s) - have a substantially different profile."
Maybe, but we're not always talking about social engineering. There are plenty of real software vulnerabilities. Social engineering must be dealt with by proper training.
"This is before even getting to the simple fact that unix has had 20 years more to harden itself from attackers."
Are you conceding that Unix is more secure, but using this as an excuse? Even if it's a valid excuse, it still means Unix is more secure, which is all that's important.
"Targets are not only chosen because they're easy, but also because they're useful."
I'd say that huge databases of credit card numbers and other personal information is very useful. I reckon that Unix servers are probably the most useful to break into since they're run by banks and the government as well as large corporations. Some turd's desktop is ok at sending spam, but the big hackers would be after the big servers.
The global economy is a great thing until you feel it locally.
> 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?
A persistent outgoing connection (if they were lurking in IRC for instance), is still using an ephemeral port. You can't use a single port both for an incoming and outgoing connection, so that would still be picked up regardless of who initiated it.
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.
rootkit revealer.
There's nothing that System can't do.
:o)
Oh yeah? Delete a file when there's a read-lock on it.
for those who don't get it, this is a fundamental problem with Windows - a file that's locked can't be modified or deleted. It's why you have to reboot after installing a service pack, or sometimes removing a virus.
The main problem when trying to get rid or detect rootkits on Windows XP/Server 2003 is that the "Safe Mode" is not at all safe at all.
By the time the system has booted far enough to get into "Safe Mode" it's already loaded so many DLL's, including the obfucating rootkit ones, that there's no way of accessing the filesystem to see the malware.
Now, if Microsoft had added a single-tasking, statically linked command line emergency system which would allow you to just manipulate an NTFS filesystem this would be the greatest step forward in rootkit/malware removal.
Alternatively, "Safe Mode" should load only those DLL's which are hard coded into the kernel to load, along with signatures and checksums to make sure (as much as you can) that those files haven't been tampered with.
As it is, the only way I've found of de-rootkitting machine is using Knoppix 3.6 and captive-NTFS!
Agrajag: "Oh no, not again!"
Actually, if fewer people ran 2K/XP as admin, there'd be a lot fewer problems with viruses and trojans - many (most?) are unable to install using "normal means" (ie: through a browsers or email client) using non-admin accounts.
I've given some serious thought to doing that myself, but I've never been hit badly enough to worry about it.
That said, some of the new rootkits are very, very good and kind of frightening. Do a bit of investigating at some of the hacker websites (like the guy who wrote the trojan which was used at Valve for the famous HL2 theft), and you'll see how sophisticated they've become since that very early version that was relatively easy to detect compared to what's out now...
For the newest trojans, aside from actually physically booting windows from a clean source (ie: bootable clean CD-ROM that can check file signatures and such), these new trojans are undetectable by even the most current scanning software (including scanning tools from sysinternals and such). They hook the OS early enough, and at such a low-level that they're completely invisible when you're running the OS itself.
N.
"Nothing strengthens authority so much as silence." - Charles de Gaulle
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.
"Simple solution to detect rootkits is to do an API call for file directory (dir, ls, whatever), and compare it side-by-side to a direct hardware request for a file directory."
That's cute, except you're assumiung your active memory is safe. So long as I'm running in memory, I don't even need to hook the API calls to fake return data. Jamie Butler demonstrated a technique at this year's DEFCON for hiding an active in-memory rootkit using the TLBs built into modern processors. Good luck on that one.
Unless you plan to use magnetic extraction techniques in a cleanroom to look at every bit and byte of data on the drive, you're no going to detect high-end rootkits. The old format and reinstall trick is still the only sure way.
-- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
The anti-spyware product SpyCatcher 2006 (free as in beer version) will detect rootkits when they are being run. It also uses some rootkit technology to foritfy itself from spyware trying to detect anti-spyware products.
--NerdMachine
Good point, but /proc/kmem can easily be disabled too.
--- Hindsight is 20/20, but walking backwards is not the answer.