From: Greg Hoglund [hoglund@IEWAY.COM]
Sent: Monday, October 11, 1999 2:13 AM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Response to Phrack 55-5 feedback

Well, it certainly seems that the SeAccessCheck patch has raised some
concerns.

Paul wrote:
>Don't give people admin access or physical access to the machine, so that
>they can't patch the kernel.

Of course, this isn't the issue.  What truly is the issue here is that your
OS can be modified in such a way that it cannot be trusted.  As everyone on
this list knows - having physical access is not needed to patch the kernel.
 A few hundred bytes and a stolen EIP is all it takes.  Or, in the absence
of a good stack smash - maybe a virus or trojan.  Regardless of the
injection vector - we are talking about something else here.

Russ substantiates this:
>Clearly he believes its possible to find an exploit that will give him
>the required access. While this point is debatable, its hardly the
>point of his article.

And, I might add, this is nothing new.  Most of the feedback has agreed - a
few byte patch is usually all it takes own a binary.  All I managed to
point out is that the skills that software crackers have taken for granted
since 1985 - is just as easily applied to code in TCB - and once that
happens I don't care what integrity tools you have in place - THEY WON'T WORK.

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

I couln't have stated this better!  Yes it's obvious.  What baffles my mind
sometimes - is that the obvious is so easily overlooked.  My good friend JD
Glaser recently told me a joke - two guys are walking in the jungle when
they come upon a lion.  The first guy stops and pulls out a pair of running
shoes.  He puts them on.  The second guy is baffled - "Why, my friend, you
cannot possibly outrun this lion!" - and the first guy replies - "I know -
but I can outrun you."

Matthew goes on to say:
>I honestly don't see that it would be possible, even in theory, to 'fix'
>such a hole.

David adds:
>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.

I agree with this.  You see, once you begin to play chess in ring-0, it's
all over.  As David LeBlanc pointed out - we can play white hat-black hat
games all day and neither of us is going to win.  I actually named this
phenomenon "The Shiny Red Button" problem.  Essentially there IS a magic
button that you can never fully remove - all you can do is place controls
over it.  And, as soon as you fix the shiny red button, I will regret to
inform you that I wasn't talking about *that* shiny red button - I *really*
was talking about the *other* one - ad infinitum.

>KeAddSystemServiceTable can be called by just any user, or the referenced
>paper "Adding New Services to the NT Kernel Native API"

You need to be admin in order to this call.  The paper that Joey wrote is
available for download from my website http://www.rootkit.com -

> All that talk of segments and offsets is COMPLETELY irrelevant to the hack.
> It's just filling space in the article. (It is, however, good technical
> reading!)

If all I wanted to do was post a script or an exploit - I wouldn't have
been writing an article for Phrack.  Mike wouldn't have had anything to do
w/ it.  First of all - I spent ALOT of time reversing this call - and in
order to reverse ANYTHING w/ SoftIce you had better understand everything I
wrote about in that article - hence - in my opinion the was nothing
irrelevant stated.

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

The extent is true if the domain user passwords are stolen - or virtual
circuits between workstations and the PDC are exploited.  There are trust
relationships between workstations and the PDC.

Paul elaborates on this:
>However, if all accesses are allowed by the PDC, then the
>attacker can change any password on any account to whatever they like, and
>become any user they need to be to get past any ACL on any other server in
>the network which trusts the domain of the compromised PDC.

The PDC is a concentration of trust.  Paul makes a very good point.

Paul also states:
>However, even patching the LSA would not let them access files on a file
>server other than the PDC. They'd have to patch out the check for correct
>challenge/response in the LSA to make that work.

Keep this in mind - if I apply my Phrack-55 patch to the kernel - I can now
establish a session w/o a password thru the IPC$ - and having only a NULL
user session, mount the registry, download the SAM (yes- nothing is sacred
anymore) - or issue any RPC call - or elevate my Access Token to
Domain-Admin - and then log into any workstation from the PDC.  I will then
be admin on the workstation.  So indeed, exploiting the PDC is the keystone.

Felix opens up:
>No danger there. I also wonder why you extol the rather mediocre
>technical discussion in the Phrack paper; that was script-kiddie level.

Hmmm, I have never been called a script-kiddie before.  That's a new one.

Now - the feedback seems to offer a integrity assesment as a solution to
all of this.  Tripwire is mentioned several times.  I myself work for
Tripwire - yet I do not think Tripwire will solve this problem.  Once again
- anything that can be made - can be un-made.

Ryan points this out:
>You can check against naive kernel patching with the use
>of hashing software, such as tripwire.

Of course, you cannot assume that kernel patching will be 'naive'.

Ryan goes on:
>These won't help against kernel patches designed to defeat
>such checks.  It's possible to patch the kernel so that files
>hand out a different byte stream depending on which process asks.
>(i.e. give the real kernel files when MD5.EXE reads them.)

Exactly.  I know of at least one attack in the last 2 months that involved
a linux loadable module to defeat Tripwire.

Adam is quick to point out that having such a centralized point of control
only facilitates a smaller - quicker to deploy - patch.

Adam:
>No argument with the assertion that you can quickly patch any OS;
>perhaps not in 4 bytes, but I'll admit that I'm glad to see
>authorization really is centralized.

I tend to agree - obfuscating anything in the kernel w/ regards to this
isn't a solution - and software engineers have played this game for years -
a losing game - trying to stop software piracy.  For an incredible
discourse of some of the 'tricks' that have been reverse engineered visit
Fravia's page of reverse engineering:
http://www.phase-one.com.au/fravia/entran.htm

Also, within the last few weeks someone has released a newer version of the
4-byte patch - apparently whiddling it down to a mere two-bytes ( bow. )
They have also addresses the NTLDR issue (which compares checksums during
startup).

Robert suggests:
>Therefore, a simple defense would be to simply have a logon script on your
>servers. When WinNT clients connect, the script attempts to run with admin
>privleges. If it succeeds, it then logs the user out.

That's an interesting idea.  Obviously this doesn't solve the "shiny red
button" issue - as any host-based IDS you may be using can be tampered
with.  But, anything you do to increase your ability to see what is going
on - only mitigates the risk.  Just never trust a single solution.

Kruk adds his two cents:
>It reeks of digested information from various sources, for example, books
with
>titles that begin "Undocumented ...".  I think Andrew Shulman should sue them
>:-)

Digested is correct.  Digested and integrated.  And - The only reference
materials I used for that paper were my SoftIce manuals - my Experience -
and the NCSC texts.  In fact, why don't I offer you some good reading:

Read Fravia's site (URL was posted)
Read Mammon and +Orc (linked from Fravia I am sure)
Read Mark Ludwig - the giant black book of computer viruses (worth every cent)
Read the Mindshare books - I own every one - 'Protected mode software
architecture' is particularly useful. The pentium architecure volume is
nice as well.
Read Barry Kauler's book 'Windows Assembly Language and Systems Programming'.
And for Windows NT architecture - you can't beat the Device Driver books -
OSR's is the best, but there are three others.

> Didn't selectors go the way of the dodo and 16 bit programming?

No.

Mikael states:
>Now I've tried to post to this list about getting services to
>run as users other than LocalSystem before (Hi, Russ!) without
>success, but I'd still like to see service vendors writing services
>that can actually do this.

Absolutely Brilliant!  Actually, NT isn't so bad - in terms of an OS.  It
has some great features - the memory manager isn't too bad - and the SRM is
great - the auditing architecture is very sound.  Why, then, does NT suck?
Applications.  The apps break it - and as Mikael points out - IIS is one of
the worst.  Just drop a process list - and find inetinfo.exe running as NT
AUTHORITY/SYSTEM.  And using the impersonation API to drop the context of a
thread is USELESS - I was talking w/ Dominique just the other day about
this.  Dom pointed out how trivial it would be to simply call
RevertToSelf() within your buffer overflow payload.  I guess the
impersonation token is fairly useless then, isn't it.

On to a WIN2K issue:
Paul adds:
>Windows 2000 has "System File
>Protection" (SFP), whereby every OS file is digitally signed, and monitored
>for modification by an integrity checker. If a file is modified, it gets
>replaced with the original automatically.

Good idea - I actually patched the kernel under Win2K and saw it magically
get replaced before my very eyes.  Kinda neat - except it's not going to
solve the problem.  Also, after my SANS talk last week - at least two
people came up and told me they had defeated that mechanism under Win2K
quite by accident (perhaps by crashing the mechanism?).  Maybe all the bugs
aren't worked out yet - but it stands to be patched along w/ everything else.

Also, in terms of people hiding 'rootkit' material, David suggests:
>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.]

The NT Tripwire does deal w/ alternate data streams.  Good point, BTW - it
seems alot of people haven't got it thru their head that data streams are a
heavily exploited feature of NTFS.  Executables can even be launched in
this way.

L8tr,
-Greg Hoglund (hoglund@ieway.com)

ps. check out my site: http://www.rootkit.com