Bugtraq mailing list archives
Re: Loading Rootkit using SystemLoadAndCallImage
From: Fernando Trias <fernando () pedestalsoftware com>
Date: Tue, 5 Sep 2000 17:11:14 -0400
1. A new release of IPD now traps the ZwSetSystemInformation call and prevents rootkit.com's latest rootkit. Get the developer's version at http://www.pedestalsoftware.com/intact/ipd/index.htm 2. I think rootkit.com's code has a bug. On line 19, it says "typedef unsigned long NTSTATUS" when that should be "typedef long NTSTATUS". Otherwise, the macro on line 20 will always be true since an unsigned value is always greater than or equal to 0; this means you will never know when the rootkit fails to load. 3. Other comments: When we wrote the Integrity Protection Driver (IPD), we were trying to develop a framework to try to address the issues that Greg Hoglund and other rootkit developers bring up. Perhaps I don't understand why Greg Hoglund thinks anti-rootkit software is useless, but to argue that protection against existing rootkits is useless because there's no protection for future unknown rootkits is missing the point. IPD is analogous to anti-virus software. Anti-virus software only stops known viruses. Does that mean it is useless because it lets new ones through? No. It still reduces your overall risk and every company uses anti-virus software. We are committed to providing the security community with free and open tools to combat the serious deficiencies in NT/2000 that make rootkits possible. Others are committed to pointing out these deficiencies so that, presumably, they can be addressed and Microsoft will be forced to alter it's kernel. Long term, altering NT/2000 is the right way to proceed. But until that day, people still need to protect themselves. We therefore ask that if anyone discovers a method to bypass IPD to please let us know before publishing it so that we may provide a patch. This is similar to the accepted vendor notification norms of BUGTRAQ. At 12:31 PM 8/29/2000 -0700, Greg Hoglund wrote:
Greets, For a while there has been a thread on NTBUGTRAQ about kernel-mode protection from rootkits. This is good - the whole point of our rootkit.com project is to get people thinking about the problem. For example, there is now an ANTI-Rootkit (called Integrity Protection Driver) from Pedestal Software. At the Blackhat Briefings this year, more than a couple smart people talked about how many ways you can load code into the NT kernel - the obvious reaction to the whole "anti-rootkit" idea. Most of the rootkit developers were in on this - so we decided to change the windows rootkit in response. Up until now, the windows rootkit has been a driver. BUT, there is no reason that a rootkit has to operate as a driver - or a loadable module. Last year we released rootkit to prove that user-mode 'integrity' software is completely meaningless. Think about it - anyone who hacks your system is going to be able to load a kernel mod - period. This is 100% guaranteed. If an attacker gets into your system using a user-level account, they will then obtain administrator - which has all the power you'll ever need to load kernel-mode code. Given this fact, it is easy to see that your 'host' based solutions are completely vulnerable to modification without your knowledge. The idea of putting your integrity protection into the kernel is a very good one - but that isn't going to be done 'right' until Microsoft does it themselves. And, _when_ they do, a whole 'security' market vanishes. One of the ideas presented to load kernel mode code was to use an undocumented entry point into kernel-space - such as the /dev/physicalmemory device, or a syscall that uses 'SystemLoadAndCallImage'. We could continue to beat this down, but the fact is there is no OS-supported leverage point to control access into kernel mode - and becuase of this, new entry points can always be discovered. Assuming Microsoft actually fixes the NT architecture to protect against this sort of thing - there is still the idea of finding buffer overflows in the kernel itself. Every third party driver you install opens you up to possible buffer overflows thru IOCTL() commands and even normal read/write messages. Even the default drivers in NT may be vulnerable to this. While the rootkit was being handled as a driver, we used the service control manager to load or remove the driver from kernel space. This is standard, and it requires that the rootkit driver have a registry key in the CurrentControlSet/Services tree. This has been changed. We have changed the rootkit such that it loads into kernel space with no driver or registry key required. We no longer use the service control manager. Instead, rootkit now loads into kernel memory using a single interrupt call - an NT system call known as ZwSetSystemInformation(). Using this call we cause the rootkit to be immediately loaded into memory and activated. -Greg Hoglund http://www.rootkit.com
---------------------------- Fernando Trias Pedestal Software, LLC fernando () pedestalsoftware com Phone: +1 (508) 520-8960 http://www.pedestalsoftware.com Fax: +1 (508) 520-8638
Current thread:
- Re: Loading Rootkit using SystemLoadAndCallImage Fernando Trias (Sep 05)
- Re: Loading Rootkit using SystemLoadAndCallImage Jon Gary (Sep 05)