ICodeFactory Labs

UAC Revealed ~ .elevation of rights from .NET as commonly misunderstood.

by Sergio 8. June 2009 09:19

Recently we had a project that involves impersonification of windows users.

Idea was to create a tool that will allow non admin domain user to start single executable that requires administrative rights without need to add domain user to administrators group.
So, we were planning to create command prompt tool that may process parameters, impersonate some other user (administrator) and starts another process with new user’s credentials.

We made a small proof of concept and it all worked well. Nice, I sad, let’s test it with Vista’s User Access Control. Whoops!

Newly started process, starts as admin user, but without elevated rights. That means user is administrator, but run with rights of regular user!

So we got “this process needs elevation” error in console window.

After some investigation on internet we found ProcessStartInfo.Verb property as point of interest in this case.
According to number of articles, you just need to set this property’s value to ‘runas’ and new process will be started with elevated rights. As if.
This approach would not help you in this case. Actually there is no solution for UAC!

We contacted Microsoft’s forums, and after number of posts and responses we discovered the awful truth.
There is no way to start another process from .net code, impersonate another user to execute that code and elevate rights for that user.
Actually there is no way to do it with UAC enabled. It is constraint of UAC itself. UAC will not allow you to do this.
Microsoft claims that this is security measure, but in my opinion it does not have too much sense since my code already knows administrator user’s credentials!
So, what kind of protection is this anyway?
Next thing that was really strange to me is why so many articles claim opposite?
(Take a look at: http://victorhurdugaci.com/using-uac-with-c-part-1/ for example.)

Problem is that there are some administrative users that are not controlled by UAC!
Built in local administrator user or build in domain administrator user are not constrained by UAC.

This means that you may start another process from your .net code, impersonate built in administrator user and new process will start elevated!
So this code snippet:

ProcessStartInfo processInfo = new ProcessStartInfo();
SecureString securePassword = new SecureString();
foreach (char ch in “testpass”)
{
securePassword.AppendChar(ch);
} // foreach
processInfo.UserName = “administrator”;
processInfo.Password = securePassword;
processInfo.Verb = “runas”;
processInfo.FileName = @”c:\windows\system32\cmd.exe”;
processInfo.UseShellExecute = false;
Process.Start(processInfo);

Will run cmd.exe elevated on Vista, because this user is not run as regular user, but as full rights administrator!
But, if you try to use any other member of administrators group as as new process user it will not work!

Unfortunately it has been an ‘show stopper’ for our project. Too bad.

By my first investigation it will  be possible by default on Windows 7! Now, that is interesting.

I wonder did we found a bug in UAC design or .NET implementation? Maybe. The World will know;-)

 

Currently rated 4.6 by 11 people

  • Currently 4.636363/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET

Comments

Add comment


(Will show your Gravatar icon)  

  Country flag


  • Comment
  • Preview
Loading




Page List

Tag cloud

    About the authors

    Proud members of ICF crew.

    Contact

    Development and Sales
    ICodeFactory d.o.o.
    Trg Marije Trandafil 24/2
    21000 Novi Sad
    Serbia, Europe
    Phone: +381 (0)21 41 77 08
    info[at]icodefactory[dot]com

    Headquarter
    T.C. Bagljaš, Lok. 11
    23000 Zrenjanin
    Serbia, Europe

    Working hours
    Monday - Friday
    8am - 4pm (GMT+1)