Re: Loading Rootkit using SystemLoadAndCallImage

[Jon Gary <jgary () CLICKTOSECURE COM>]

As a member of the rootkit team, I feel I should respond to this.  The
fundamental misunderstanding that I believe has been made from the beginning
is that the Windows 2000 Rootkit project hosted at http://www.rootkit.com is
_the_ windows NT/2000 rootkit.  It is not the only one, and may not even be
the best one.  I don't know.  The reason I don't know is that most likely
the most effective rootkits are not public.  Some of the most talented
hacker groups in the world have "no disclosure" policies, meaning that the
exploits they find and the tools they develop are kept secret, available to
only a small internal group.  The Win2k Rootkit was started to show a few
large problems, not hundreds of little ones, and while this "anti-virus"
approach is interesting, until there is central control for kernel-mode
access, it can probably never address everything.  All this has been said
before, so I'll move on to addressing this post specifically:

> 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.

Yep.  It's an Open-Source project, under GPL.  Submit a patch, and it will
be fixed.  You seem to think that vendors should be notified, but we were
not notified of anything here.  I could continue to be pedantic, but since
this bug was mentioned mostly in the form of a low blow, I'll leave it at
that.

> 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.

I didn't read that in Greg's post.  What he said was that "user-mode
integrity software" is meaningless.  IPD is not user-mode.  He later
mentions that "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."  Which implies that the IPD _is_ a good idea, but not a
perfect solution.  I agree with this.

> 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.

Ok, this one I have a problem with.  I totally agree with notifying vendors
of security vulnerabilities and giving them the time to fix them, however,
this is not that type of situation.  Greg's post was not an advisory about
the IPD, and in fact, only mentioned the IPD in passing as one product meant
to stop rootkits.  In fact, I don't believe that he ever claimed directly
that the IPD was defeated by this method.  More importantly, the rootkit was
not changed solely to defeat the IPD.  The changes that were made had been
in discussion before the IPD was even announced, for several reasons:

1. Decreased size.  This means that the rootkit is now small enough that the
kernel-injection mechanism could theoretically be used as the payload of a
buffer-overflow exploit.
2. Ease of hinding.  The rootkit used to have to go to a lot of trouble to
hide it's tracks in the registry, and we couldn't be sure if we were hiding
everything.  Now, there is no trace in the registry.
3. Completeness.  The rootkit should interact with as few APIs as possible
to ensure that it works correctly on all systems.  This means that
interacting with SCM was not desirable.

More to the point, the IPD _was_ changed solely in response to the rootkit.
Therefore, it would seem appropriate that the rootkit team be notified of a
perceived shortcoming in the rootkit.  I'm not suggesting that this is
necessary, only that there was more reason for us to be notified than for
Pedastal Software to be notified.

On a personal note, I believe that the IPD is a step in the right direction,
and as far as I know, it's the first of its kind.  However, I'm in this to
see a total solution.  I tend to only see things as "secure" or "insecure".
Idealistically I don't really buy into the risk-management idea.  However, I
realize that in the real world, it's necessary, and the IPD is very good for
this.  I'll be truly impressed when someone (presumably at Microsoft,
although not necessarily) fixes this issue for good.  Until then, I suppose
this chess match is going to continue.


Jon Gary
http://www.rootkit.com

-----Original Message-----
From: Bugtraq List [mailto:BUGTRAQ () SECURITYFOCUS COM]On Behalf Of
Fernando Trias
Sent: Tuesday, September 05, 2000 2:11 PM
To: BUGTRAQ () SECURITYFOCUS COM
Subject: Re: Loading Rootkit using SystemLoadAndCallImage


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