OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: NT Screen Saver Password Protect Bug
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NT Screen Saver Password Protect Bug


  • To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
  • Subject: Re: NT Screen Saver Password Protect Bug
  • From: Andreas Klein <andreklMICROSOFT.COM>
  • Date: Tue, 24 Mar 1998 07:13:15 -0800
  • Comments: To: Christopher L Buono <cbuonoALBANY.NET>
  • Reply-To: Andreas Klein <andreklMICROSOFT.COM>
  • Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>

I am sorry but I don't understand how LockWorkstation is not going to solve
the problem. If you lock the workstation the screensaver is NOT in the
picture.

Maybe you can elaborate?

Relying on the screensaver to lock the workstation for you is not what I
would call "acting responsible".

just my $0.02 worth.
ciao,
  Andreas

> -----Original Message-----
> From: Christopher L Buono [SMTP:cbuonoALBANY.NET]
> Sent: Tuesday, March 24, 1998 3:27 PM
> To:   NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
> Subject:      Re: NT Screen Saver Password Protect Bug
>
> I want to address some of the responses to my original posting. Instead of
> responding to them individually I cut and pasted them into this one email.
>
> >"Maybe I'm missing something here, but isn't this another one of those
> >"once you  have admin access you can crack the system" exploits?  Don't
> >you need admin to connect to C$ or Admin$?  And if you're admin already
> >you can just override the locked console."
>
> Just below the procedures I outlined in my original email I wrote almost
> the
> exact same thing. However, below that I identified a scenario where it
> could
> be exploited. It involves the difference between a resource domain admin
> and
> a master domain admin. See the original posting below.
>
> >Why did you wait for your "screen saver" to kick in?  Definitely a
> >false sense of security.  CTRL-ALT-DEL and hit enter - "Lock Workstation"
> >is the default.  Very easy, and comes with practice.  All your processes
> >can still run, and the only one who can open it (besides you) is another
> >admin.  However, when they log in, NT logs you out (and kills all your
> >processes - can't have everything).
>
> Locking the workstation manually yields the same problem. So I'm not sure
> I
> understand your point. Yes another admin can log you out, but the
> situation
> I identified allows another admin (i.e. resource domain admins) to
> effectively become you.
>
> Another point here is that if the abuser renames the .scr file back to its
> original name and chooses "Lock Workstation" the "victimized" user will
> never know.
>
> Maybe the lesson to be learned here is simply not to rely on the "Lock
> Workstation" feature (or password protected screen savers at all). If that
> is the case then Microsoft should just remove the feature. Otherwise, MS
> should fix the feature so it can't be exploited.
>
> Christopher Buono, CNE, MCSE: cbuonoalbany.net
> Anemone
>
> -----Original Message-----
> From: Christopher L Buono <cbuonoALBANY.NET>
> To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
> Date: Monday, March 23, 1998 9:10 PM
> Subject: NT Screen Saver Password Protect Bug
>
>
> >I don't know if this bug has already been identified. Because it still
> >exists in NT 4.0 SP3 I'll assume it hasn't.
> >
> >On NT 3.51 SP4, SP5, and NT 4.0 SP3 Server and Workstation (and I assume
> all
> >versions in between) screen saver password protection can be disabled
> simply
> >by renaming the .scr file that is in use by the logged on user. For
> >reproduction purposes this is what I did:
> >
> >1) Logon to a network connected NT workstation or server and set the
> screen
> >saver for 3D Text (or any valid PW protectable screen saver) w/ password
> >protection enabled and w/ a timeout value of one minute greater.
> >2) Allow screen saver to activate.
> >3) Logon to another network connected machine and map a drive to the
> machine
> >referenced in step #1 (C$ or ADMIN$).
> >4) Within the mapped drive rename %systemroot%\system32\sstext3d.scr to
> >*.scx.
> >5) Deactivate the screen saver on the first machine by moving the mouse.
> >6) Wait for the screen saver timeout period to elapse.
> >7) Press Ctrl-Alt-Del and select Cancel from the Windows NT Security
> window.
> >8) You're in!
> >
> >
> >I reproduced this outcome on various machines, with various screen
> savers,
> >and with various :~) NT versions.
> >
> >This is one of those situations where if you already have administrative
> >privileges enough to connect to C$ or ADMIN$ then who cares if you can
> >remove somebody's password protection. I thought of at least one
> situation
> >where this could be abused.
> >
> >"I am a Domain Admin for a master domain. I travel to a remote site with
> a
> >resource domain that trusts the master domain. I logon to an NT
> workstation
> >to do some work. Lunch time comes around and I verify that my screen
> saver
> >has activated and is locked with password protection enabled. I leave the
> >workstation. The local LAN Administrator, who is an Administrator for the
> >resource domain, maps a drive to the workstation I am logged onto and
> >performs the above procedure. The person is now able abuse all of my
> >privileges as if s/he were me."
> >
> >Microsoft has been copied on this.
> >
> >Christopher Buono, CNE, MCSE: cbuonoalbany.net
> >Anemone
> >