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: Christopher L Buono <cbuonoALBANY.NET>
  • Date: Tue, 24 Mar 1998 09:27:10 -0500
  • Reply-To: Christopher L Buono <cbuonoALBANY.NET>
  • Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>

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
>