Skip to content

Unlock any user’s session without losing data or killing processes

UPDATED Feb. 2nd 2008 : There is an enhanced version out, with better code, features and documentation.

A friend of mine wanted a special group of users to be able to unlock a workstation without losing any data. Putting those uses in the administrator groups was not a solution, because the default behaviour of Windows was to close or terminate every process and give the administrator a brand new session. Fast user switching added some tricks, but in the end there was no way to recover an open document with modifications in it from a locked Windows workstation.

The project has its own page now. If you are a computer historian, read on for the original first release.

He asked me if I could write a screen saver to do this, but the answer was a little deeper under the hood, and a lot more fun. I wrote a replacement Graphical Identification and Authentication DLL (GINA DLL) that hooks the standard Microsoft Windows Gina DLL of Windows XP and Windows Server 2003. It also supports Terminal services sessions. It allows you grant members of a group (any group) to unlock any user’s session. No need to be an administrator. Any user can unlock now (Aucun).

Microsoft replaced GINA DLLs with credentials providers (ICredentialProvider), somewhat like the Solaris pluggable authentication modules PAM. This Gina DLL will never work in Vista, by design.

Turns out it is pretty easy. You can get the source code and a compiled binary here. I recommend that you don’t trust me with your password and work with the source. Anonymous Subversion access with this command

svn co http://src.paralint.com/aucun/trunk aucun

I started with the Gina Hook sample from the SDK, and added support for terminal services. Then I stripped away all the unnecessary hooks and updated the dialog detection code. A few registry calls later and some basic group membership checking later was all that was needed.

To allow any user from any given group to unlock a Windows session, you have to:

  1. Hook every function of the regular Gina, msgina.dll
  2. Export every function yourself, forwarding them all to msgina.dll as is except for WlxNegotiate and WlxInitialize
  3. In WlxInitialize, hook the Windows provided function WlxDialogBoxParam (so msgina.dll will call your DLL when it creates a dialog box)
  4. In your version of WlxDialogBoxParam, let everything go through except requests to create the unlock dialog
  5. Hook the DLGPROC and wait for WM_COMMAND with wParam == IDOK
  6. Check the user’s password (LogonUser with LOGON32_LOGON_UNLOCK)
    • If it doesn’t match, let the call go through the regular GINA
    • If it matches, and the user is part of the group you want to be able to unlock (CheckTokenMembership), call EndDialog with IDOK
    • It it matches and the user is not in the group you want to be able to unlock, let the regular GINA handle it

That’s about it. The third bullet of item 6 is actually what will happen most of time. The same user that locked its station comes back and enters a password that matches, but that regular user is not part of the unlock group. MSGINA.DLL handles it and unlock the session as usual. (UPDATED january 8th 2008 ->) If you audit logon events, succesfull or failed, they will be logged under the name of the person unlocking the session, not the original user. It is a deterrent measure only, it will not give you non-repudiation of actions made after the session was unlocked.

I insists there is no need for the users to be members of the administrators group for this to work. With my implementation, you merely set a registry key with the name of the group you want to use. Add any user(s) or group(s) to this group.

HKEY_LOCAL_MACHINE\SOFTWARE\Paralint.com\Aucun"GroupName"="paralint.com\DG_SESSION_UNLOCKERS"

I might add a blacklist feature, so that members of the the administrative group can never be unlocked. It is not hard to do. If I see interest in this project, I write it happen.

The code is all plain old, good old C. Function pointers, hooked procedures. All the fun stuff .Net hides from you ;) Remember: Gina were introduced in Windows NT 3.51, some 15 years ago. And yes, I was already a Windows programmer back then…

14 Comments

  1. Martin wrote:

    As a “security consultant” it would be expected that you would be helping people harden the security of thier systems instead of showing them how to completely compromise it. I am not sure how you find this to be helpful. This is very much the same as posting virus code for “educational” reasons. It actually does a lot more harm than good. Reading this guy’s blog I see that he is very intelligent and knows a lot about Window’s security. I really wish he used that talent in a more positive way.

    Reply

    Tuesday, January 8, 2008 at 7:49 | Permalink
  2. ixe013 wrote:

    First, let me thank you for taking the time to read and post a comment.

    This replacement GINA is indeed a security hole in most scenarios.

    When user Bob unlocks Alice’s session, he can impersonate her. Windows will not be able to tell what human is really using the mouse and keyboard. Same goes for any machine on the network.

    Caveat: an ordinary user cannot replace the GINA on is own. Windows architecture is not to blame. The administrator who installed it and I are to blame.

    The context in which this is helpful is when there is high availability requirements and low (if any) confidentiality concerns. For example: Alice has some resource locked by an application and she went home. Bob needs to be able to use or somewhat unlock it. This GINA will allow him to do that. He can then either resume operation on the original computer or go back to his and use the resource over there.

    I should have mentioned that an unlock security event is generated in the name of Bob. I will update the text.

    Reply

    Tuesday, January 8, 2008 at 10:37 | Permalink
  3. Martin wrote:

    I understand what you are saying but still feel you are doing a great a great disservice by providing code so that any “kiddie” hacker can comprise systems. Of course only an admin is able to change the GINA but we must be realistic and realize that too many users have admin access to machines.

    Pointing out the dangers of allowing others to change the GINA is helpful. Including a sample GINA to prove your point is acceptable. Giving source code that others can modify to make a system easily accessible is not.

    I stand by my origional point. Security experts should help harden systems and not help others exploit them.

    This is only my option but I truely question the ethics of someone posting such well written code that allows others to such great security holes. I truely wish you did not make the source code available and had your same “proof of concept” demo clearly display that the system is not locked in the usual (and assumed) sense.

    Reply

    Tuesday, January 8, 2008 at 14:48 | Permalink
  4. ixe013 wrote:

    When my friend took over system administration at this small company, users wrote their password on a billboard at the office entrance. This GINA filled a need they had in the most secure way I could think of.

    A note to all script kiddies reading this: If you have administrative rights to a machine and want to compromise it for other users, do not bother with my replacement GINA. Install a key logger and unlock the session with the user’s password. Same effect, but it leaves no trace. And you will be able to log on on your own if need be. There are good, free and open source keyloggers.

    It all boils down to trusting administrator of the machine your are loggin into. There are so many ways an administrator can subvert a machine. Same goes for the root account on *nix.

    In closing, may I suggest reading this on trustworthy administrators : http://www.microsoft.com/technet/community/columns/secmgmt/sm0705.mspx

    Reply

    Tuesday, January 8, 2008 at 20:20 | Permalink
  5. Flemming Hjorth wrote:

    This tool is somewhat what I have been looking for. Except that what I am looking for is actually just a solution that allows ordinary users to unlock a computer locked by another user (unless locked by an administrator). I mean, the original user should be logged off, accepting that all unsaved work will be lost (we are running Citrix Presentation server, so sessions are just disconnected).
    I am not a Windows programmer, so I was hoping maybe you have a solution for this?

    Kind Regards
    Flemming Hjorth Andersen, System Consultant from Denmark

    Reply

    Wednesday, January 9, 2008 at 2:02 | Permalink
  6. ixe013 wrote:

    A force log off is easy to add. Probably just use WLX_DLG_USER_LOGOFF in the EndDialog call in GinaDlg.c and some logic to return a WLX_SAS_ACTION_FORCE_LOGOFF from WlxWkstaLockedSAS.

    Let me look into it. I will also add an optional warning feature, as suggested by Martin.

    Come back in a day or two, or better yet, subscribe to the feed !

    Reply

    Wednesday, January 9, 2008 at 7:41 | Permalink
  7. Flemming Hjorth wrote:

    Sounds really great!!
    Looking forward to it :-)

    Reply

    Thursday, January 10, 2008 at 3:11 | Permalink
  8. anon wrote:

    Wake up Martin, this is no bigger a security risk than the 80,000 other ways to compromise a system when you’ve got admin/root privileges. Sheesh!

    Reply

    Thursday, January 10, 2008 at 7:38 | Permalink
  9. Mark wrote:

    This goes part way to solving a problem that we have. Users sessions are locked by the screensaver and as an admin we can get access to their machine but only by logging them out. This may lead to loss of data.
    If we need to do something we would like to unlock their session, check, maybe close, save, then do what we have to do. We already have access to their data, so security is not an issue. We would like to have it restricted to admin group and with AD support

    Reply

    Sunday, February 3, 2008 at 21:13 | Permalink
  10. Guillaume wrote:

    I think my replacement GINA is just the ticket you need. I just posted an updated version with more documentation here :
    http://www.paralint.com/projects/aucun/

    If you have trouble setting it up, send me an email, I will try to help you.

    Reply

    Monday, February 4, 2008 at 8:38 | Permalink
  11. I think this is an excellent GINA hook.

    in some environments, most typically an office here is a good example of your tool being a success….

    its a monday, and the admin/tech support is at a meeting and isnt on site. Claire however has an important letter to print out and send at 2:00PM, but at 10:30 went home i’ll. However her workstation was still left logged on, and bearing in mind each pc workstation holds no personal data except those of the clients (on the letter for exmple). Now John comes along and CAN unlock her workstation, print the letter and send it off, few days later company gets contract as the letter was sent in on time.

    thats just one scenario, but I feel that within careful use you can incorporate it very well, and if someone DID misue it within the office say, Jim used it to alter something, then he would be caught as his name would be logged as a system event.

    very good stuff! incorporating it at home.

    thanks very much.

    ben :)

    Reply

    Friday, July 4, 2008 at 15:28 | Permalink
  12. Guillaume wrote:

    Glad you find it usefull, thank you for leaving a comment !

    Reply

    Friday, July 4, 2008 at 20:58 | Permalink
  13. Chris wrote:

    Thanks for sharing the code! I may borrow a couple ideas for an upcoming GINA project and was amused at the French function/comments dropped into the middle of UnlockPolicy.c. It brings back a few memories. :)

    Reply

    Tuesday, October 21, 2008 at 0:26 | Permalink
  14. Guillaume wrote:

    Content de t’avoir aidé ! Assure-toi d’utiliser la derniere version (use project link on top of page)

    Reply

    Tuesday, October 21, 2008 at 0:46 | Permalink

Post a Comment

Your email is never published nor shared.