OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Laura A. Robinson (larobins_at_bellatlantic.net)
Date: Fri Jan 24 2003 - 18:50:46 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    One last P.S. and then I'm off for the evening. <G>

    For those who aren't familiar with anonymous access, what it's all about and
    what the ramifications of not restricting it are, I'd highly recommend a
    perusal of Thor's site.

    http://www.hammerofgod.com

    Very enlightening. :-)

    Laura

    > -----Original Message-----
    > From: Laura A. Robinson [mailto:larobinsbellatlantic.net]
    > Sent: Friday, January 24, 2003 5:34 PM
    > To: 'Hall, Randy'; 'focus-mssecurityfocus.com'
    > Subject: RE: Bypass Traverse Checking?
    >
    >
    > BTW, as a quick side note, I do not wish to imply that Domain
    > Users = Authenticated Users, because they are significantly
    > different (different types of groups, different membership,
    > different capabilities in terms of population), and if an ACL
    > contains only the SID for Authenticated Users, an account
    > without that SID in its token would not be able to access the
    > resource.
    >
    > So, to reiterate, by changing "Everyone" to "Authenticated
    > Users" in an ACL, you are affecting Anonymous Logon (null
    > connections) and the _builtin_ Guest account (one account,
    > not the guest groups). That's it. You are not affecting
    > Guests, nor are you affecting Domain Guests.
    >
    > Just wanted to make sure I wasn't being unclear. :-)
    >
    > Laura
    >
    > > -----Original Message-----
    > > From: Laura A. Robinson [mailto:larobinsbellatlantic.net]
    > > Sent: Friday, January 24, 2003 5:05 PM
    > > To: 'Hall, Randy'; 'focus-mssecurityfocus.com'
    > > Subject: 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
    > > Guests(S-1-5-21-839522115-484763869-1343024091-514)
    > >
    > > 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>
    > >
    > > 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.hallintel.com]
    > > > Sent: Friday, January 24, 2003 12:28 PM
    > > > To: focus-mssecurityfocus.com
    > > > Subject: RE: Bypass Traverse Checking?
    > > >
    > > >
    > > > I thought I would weigh in on this discussion, mostly
    > because I see
    > > > some dangerous assertions being made.
    > > >
    > > > A very good web article that clears the distinction between
    > > > Everyone, Users, and Authenticated Users is at:
    > > >
    > > >
    > >
    > http://www.windowswebsolutions.com/Articles/Index.cfm?ArticleID=23581
    > > >
    > > > I read it and agree with its findings.
    > > >
    > > > Cheers,
    > > >
    > > > --R
    > > > --
    > > > Randy Hall MCSA, MCSE (randy.hallintel.com)
    > > > Network/Web Manager, Corporate Demos
    > > > Intel Corporation, Santa Clara, CA USA
    > > > All views expressed herein are MINE MINE MINE!!!
    > > >
    > > >
    > > > -----Original Message-----
    > > > From: Laura A. Robinson [mailto:larobinsbellatlantic.net]
    > > > Sent: Friday, January 24, 2003 5:35 AM
    > > > To: 'Shane Brooks'; 'Williamson, Scott';
    > focus-mssecurityfocus.com
    > > > Subject: RE: Bypass Traverse Checking?
    > > >
    > > > As an additional item, since I've been challenged on this one via
    > > > e-mail, I would encourage reading of this:
    > > >
    > > > http://www.microsoft.com/windows2000/techinfo/reskit/en-us/def
    > > > ault.asp?u
    > > > rl=/ windows2000/techinfo/reskit/en-us/distrib/dsbc_nar_lmxa.asp
    > > >
    > > > or
    > > >
    > > > http://tinyurl.com/4ubt
    > > >
    > > > Particularly this:
    > > > "Note
    > > > For anonymous access to be available for Internet users,
    > anonymous
    > > > access must be enabled on the Internet Information Services (IIS)
    > > > Web server."
    > > >
    > > > Again, note that Authenticated users does _not_ include anonymous.
    > > >
    > > > Laura
    > > >
    > > > > -----Original Message-----
    > > > > From: Shane Brooks [mailto:shanefloridacomputerservices.com]
    > > > > Sent: Monday, January 20, 2003 7:11 PM
    > > > > To: Williamson, Scott; focus-mssecurityfocus.com
    > > > > Subject: Re: Bypass Traverse Checking?
    > > > >
    > > > >
    > > > > You should definately make this change. If anything, the other
    > > > > admin is confusing Anonymous access of web-pages by the
    > > > > IUSR_[computername] account. However, IIS manages the
    > password of
    > > > > this account automatically and the account is therefore a
    > > member of
    > > > > "Authenticated Users", since IIS authenticates every
    > page as IUSR
    > > > > automatically if Anonymous access is enabled. The only
    > > account that
    > > > > is affected by Everyone is the guest account which is
    > disabled by
    > > > > default. Hope this helps, Shane
    > > > > ----- Original Message -----
    > > > > From: "Williamson, Scott" <scott.williamsonhtcinc.net>
    > > > > To: <focus-mssecurityfocus.com>
    > > > > Sent: Wednesday, January 15, 2003 1:10 PM
    > > > > Subject: Bypass Traverse Checking?
    > > > >
    > > > >
    > > > > > I'm working on procedures for servers in our
    > > organization. I keep
    > > > > > coming across the recommendation to set the following on
    > > > a Windows
    > > > > > 2000 Server.
    > > > > My
    > > > > > problem is I have another administrator who believes this
    > > > > could cause
    > > > > > problems in IIS. What are the lists opinions? Anyone
    > > > heard of this
    > > > > causing
    > > > > > problems?
    > > > > >
    > > > > > User Rights Assignment - Set "Bypass Traverse Checking"
    > > - Remove
    > > > > > Everyone and Replace with Authenticated Users.
    > > > > >
    > > > > > Thanks in advance for your time,
    > > > > >
    > > > > > Michael Scott Williamson
    > > > > > Systems Administrator
    > > > >
    > > >
    > >
    >