RE: Bypass Traverse Checking?

Not to drag this out further, and Brett is a friend of mine so I don't want to sound like I'm disagreeing, but there's a significant distinction that isn't in his article, and there is a small incorrect statement, as well.

Note: Guest != Guests

If you use the builtin Guest account and log on, this is what your access token looks like (the guest account in this domain is renamed "Administrator", which you can verify by looking at the SID of the account. That was done for easy searches in auditing.):

User : SOMEDOMAIN\Administrator
(S-1-5-21-839522115-484763869-1343024091-501) Owner : SOMEDOMAIN\Administrator
(S-1-5-21-839522115-484763869-1343024091-501) Primary Group SID SOMEDOMAIN\Domain
Users(S-1-5-21-839522115-484763869-1343024091-513) LUID for this instance of token 141654864 LUID for this logon session 140666464 Token is type PRIMARY
Token source is <User32 Äv>

Retrieving Group information from current process token SID 0 Group: SOMEDOMAIN\Domain
Users(S-1-5-21-839522115-484763869-1343024091-513)

SID 1 Group: \Everyone(S-1-1-0)
SID 2 Group: BUILTIN\Guests(S-1-5-32-546)
SID 3 Group: BUILTIN\Users(S-1-5-32-545)
SID 4 Group: NT AUTHORITY\INTERACTIVE(S-1-5-4)
SID 5 Group: NT AUTHORITY\NONE_MAPPED(S-1-5-5-0-1406586)
SID 6 Group: \LOCAL(S-1-2-0)
SID 7 Group: SOMEDOMAIN\Domain

Privileges associated with this token (1) SeChangeNotifyPrivilege - (attributes) 3

So, yes, if you use the guest _account_, the Authenticated Users SID is not added to your access token. The _Users_ SID, however, is, contrary to Brett's article, as is Domain Users. Since Domain Users are, by definition, authenticated users, it becomes irrelevant that the Authenticated Users SID is not in the access token. _However_, if you create an account, make it a member of Domain Guests (and Guests, should you have the burning desire to do so), _remove_ it from the domain users group, then log on with the account, this is what your access token looks like:

User : SOMEDOMAIN\guestmember (S-1-5-21-839522115-484763869-1343024091-2611) Owner : SOMEDOMAIN\guestmember
(S-1-5-21-839522115-484763869-1343024091-2611) Primary Group SID SOMEDOMAIN\Domain
Guests(S-1-5-21-839522115-484763869-1343024091-514) LUID for this instance of token 159218764 LUID for this logon session 153701964 Token is type PRIMARY
Token source is <User32 ÷s>

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

Retrieving Group information from current process token SID 0 Group: SOMEDOMAIN\Domain
Guests(S-1-5-21-839522115-484763869-1343024091-514)

SID 1 Group: \Everyone(S-1-1-0)
SID 2 Group: BUILTIN\Guests(S-1-5-32-546)
SID 3 Group: BUILTIN\Users(S-1-5-32-545)
SID 4 Group: NT AUTHORITY\INTERACTIVE(S-1-5-4)
SID 5 Group: NT AUTHORITY\Authenticated Users(S-1-5-11)
SID 6 Group: NT AUTHORITY\NONE_MAPPED(S-1-5-5-0-1536850)
SID 7 Group: \LOCAL(S-1-2-0)

Privileges associated with this token (2) SeChangeNotifyPrivilege - (attributes) 3 SeMachineAccountPrivilege - (attributes) 0

Note the membership in the Authenticated Users group and the inclusion of that SID in the access token. I should have been very careful to note this difference, but again, Authenticated Users _does_ include Guests. The rest of Brett's article says the same things that I said in my post (right down to the differentiation between the IUSR_ user and Anonymous Logon <G>).

I encourage you to duplicate my tests, as even though my testing has been consistent, I'd like to see it validated by another.

Laura

> -----Original Message-----
> From: Hall, Randy [mailto:randy.hall@intel.com]
> Sent: Friday, January 24, 2003 12:28 PM
Received on Tue Jan 28 12:49:01 2003