OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NTBugtraq And NTSecurity Archives: Re: Any Protection against t

Re: Any Protection against the Phrack 55-5 hack ?

David LeBlanc (dleblancMINDSPRING.COM)
Sun, 3 Oct 1999 19:59:51 -0700

At 08:22 PM 10/1/99 -0500, Matthew Mucker wrote:
>It seems to me that anyone who would ask this question does not truly
>understand the exploit.

I agree - the way to stop this attack is to prevent someone from obtaining
admin access to your machine and installing SoftIce on it. If someone can
either become an admin, or get LocalSystem to run code for them, all is
lost. There is little to nothing the OS can do to even slow down an
attacker at this point. Once you get rooted (or "administrated", as a
friend of mine and I refer to it on NT), your best allies are your tape
backup and your install CDs.

We've gone on and on and on about this sort of thing in the past - somewhat
like saying "If someone comes in through the front door of your house, they
might go around and unlock all the windows". Any 'exploit' which depends
on first obtaining full admin access isn't really an 'exploit' in my book -
it is an inevitable consequence of whatever _real_ exploit that got them
admin rights in the first place.

All that we can consider at this point is detecting the changes, and
containing the extent of the damage as much as possible.

I've had some time to think about this particular issue, as Greg asked for
my comments and input quite a while before he published this in Phrack. I
consider that this technique is merely an illustration of what can be done
- it isn't a particularly good example of a good rootkit technique - too
much chance that someone would notice. What he's pointing out here is
something that UNIX admins (as well as just about any other OS) have known
for years - if someone completely compromises a system, then they could
tamper with the operating system in a number of extremely subtle ways.

Some admins make the extremely foolish assumption that getting a hacker out
of a compromised system is as easy as fixing the hole they used to get in.
That might get an extremly clumsy script kiddie out, but it certainly won't
get a more adept attacker back out - they'll come up with subtle ways to
stay in, or even something as simple as cracking all your passwords. One
of the things Mudge pointed out in his speech at Black Hat was that the
hacker might even make things run BETTER! They could apply all your
patches for you, since the worst thing that could happen would be for
someone to notice the system was behaving strangely - or for some less
adept hacker to come along and screw up all your hard work.

If you want to detect the changes, then you have to have some way of
baselining the system. If a system is internet-exposed, highly
mission-critical, or is otherwise security-sensitive, then benchmark both
the file system and the registry. Get something that deals properly with
alternate data streams. [BTW, no I don't have any products I can recommend.
 I know there is an NT port of tripwire, but haven't used it personally.]

In order to contain the extent of the damage, then you have to design your
networks to be tolerant of failure. Assume that one day you will have a
bad day, and either one of your admins will screw up, or there will be some
hole found in the software you're running. Take the attitude of _when_
this internet-exposed machine gets hacked, I shouldn't lose more hosts
because [fill in blank]. If the answer to what happens if a certain
machine gets hacked is that your whole internal network goes down, too,
then that's the WRONG answer. Don't tolerate such designs.

Think about how hard it is to get a hacker out of ONE system. Now think
about getting them out of thousands of systems! (see my "Fix your servers!"
rant from a couple of months back).

This is going to be an ongoing spy vs. spy game that will be never-ending -
for every way Greg can think up to add an undetectable rootkit to my
system, I can think up a way to catch him. So then he'll go think up another.

BTW, a comment to Felix - do not dismiss Greg as a script kiddie. He is far
from it.

>I found the method of attack proposed by this author rather obvious, and am
>amazed that something like this hasn't been published earlier.

There aren't that many people who are as skilled as Greg is at twiddling NT
at the assembly code level outside of Microsoft. This sort of thing has
been out there - getadmin was another example of something very similar.
Greg's just nice enough to actually _publish_ what he's working on.

>He's simply substituting untrusted code for trusted
>code.

Precisely.

>Also, the author implies that compromising a PDC will grant admin rights for
>everyone to the entire network. I don't think this is true.

That could be open for debate, but in general, it is true. As soon as I
can get domain admin, I'll start cracking password hashes, and can probably
compromise most of the workstations or member servers in the domain. Think
about the ordering here - in order to get this patch inserted, you have to
be an admin on a DC. If you're an admin on a DC, then you can do just
about anything to the domain, and any domain that trusts you is probably in
hot water. Any domain that you trust is also in jeapordy. Whether it is
true that this specific hack grants that level of access (and I think it
could, because then anyone ought to be able to open the LSA with full
access), the point is largely moot, because the level of access required to
get the patch there in the first place is enough to nail the rest of the
network.

>I hope someone
>could say with authoority: when I access a local resource (logged on as a
>domain user), where does the authentication (grant/deny decision) take
>place?

Locally, based on the logon token that the DC gave your local system for
you when you presented your credentials.

>What if I access a network resource?

At the remote system, based on your credentials with respect to that
system. It has to work that way, because home\david user might well be an
admin on the local system, but a plain user on another system.

>I'm quite sure that the PDC
>doesn't handle EVERY security check for EVERY request to access EVERY object
>by EVERY user.

No, it won't, but it will handle the access check to requests to its own
resources. One of its own resources is its copy of the domain account
database. If this patch were made, anyone could open the LSA and add a
user to the admins group. It would then cheerfully propogate the change in
status for that user to the rest of the DCs.

>The author states "If this patch were applied to a running
>PDC, the entire domain's integrity would be violated." Can anyone out there
>clarify to what extent this is true?

It is only limited by the imagination and skill of the person who put the
patch on the DC. Note that getting admin status on a DC is currently a
violation of the integrity of the entire domain, without this patch existing.

David LeBlanc
dleblancmindspring.com

This archive was generated by hypermail 2.0b3 on Mon Oct 04 1999 - 10:53:05 CDT