I'm looking for a way to check that a remote process has administrator privileges from my (fully managed) code. It's safe to assume that my code will run be run with administrator privileges, so I don't care how invasive the technique to achieve my goal is, however I'm looking for a fully managed way which must be compatible with XP SP3 x86 all the way down to win7 x64.
Thanks in advance!
Edit: in order to clarify, I'm talking about a process running on the same machine, regardless of the user who started it. I want to make sure that either the identity associated with the process belongs to the Administrators group or that the main thread has full privileges, with special regards to inheriting handles opened by elevated processes and writing to the storage without any restriction but those applied to processes spawned with the "Run as administrator" option.
OpenProcess(PROCESS_QUERY_[LIMITED_]INFORMATION)+OpenProcessToken(TOKEN_DUPLICATE) to get the token, then DuplicateTokenEx(TOKEN_QUERY,SecurityImpersonation,TokenImpersonation) to get the impersonation token, then pass that token and the SID from CreateWellKnownSid(WinBuiltinAdministratorsSid) to CheckTokenMembership.
To be able to open (almost) every process for PROCESS_QUERY_INFORMATION access you need to be running as administrator and with debug privileges. On Vista and later you can use PROCESS_QUERY_LIMITED_INFORMATION.
Example code available in this answer.
You could use GetTokenInformation or IsUserAnAdmin API calls.
To check if process started with user from Administrative group you should use the way described by Anders. To check integrity level on Vista or Windows 7 use GetTokenInformation with specifing TokenIntegrityLevel token class to get TOKEN_MANDATORY_LABEL struct which contains SID associated with mandatory integrity level of the token.
I have created Process.Extensions.dll extension using solution offered by Anders
https://stackoverflow.com/a/53460693/3855622
Related
I just try to understand the Google update service (aka Omaha) and can't find any information about how Omaha updates Chrome without the UAC Prompt?! Or without any Administrator privileges.
I am looking for a way to lunch a update service that can Update a Application in the Program folder (without UAC / Administrator privileges) just like Omaha does, but i can't find any documentation regarding that topic. Tried browsing the source code a bit thought but i couldn't find anything that helps.
In fact only the Installation should require Administrator Rights, but the update should not.
Any "easy" way to achieve this in C#?
Chrome installs a Windows Service, which is always running and preforms the update. The service runs as SYSTEM and so can perform the update without UAC prompt.
See:
https://support.google.com/installer/answer/98805?hl=en
http://omaha.googlecode.com/svn/wiki/OmahaOverview.html (Execution model section)
I would like to enumerate child windows of a given process to check for dialog windows. For reasons I won't go into here, if it finds any, I'd like to subsequently kill that application.
Running a standalone application to do this works without any issues. The application has access (via some P/Invoke calls) to a process's windows and I can subsequently kill that application.
Running the same code as a service, however, does not work as expected. It seems that the user running the service is not able to interact with the desktop (which is a setting I can only see for the LOCAL system account).
Does anyone know of any workarounds to this? Is it possible for me to enumerate a process's windows from a windows service?
FYI -- the code (at least an adaptation of) I'm using is available here: https://stackoverflow.com/a/1405088/2115261
You're probably running Windows 7 (or 8 or Vista), because the ability for Windows Servcies to interact with the desktop was last supported in Windows XP.
There is a white paper on MSDN that describes the changes made for Vista and upwards. Basically, it is now not possible to interact with the desktop in any way.
However, there is an example on CodeProject that demonstrates how to interact with the Task Scheduler from a Windows Service, and the process executed by the Task Scheduler can interact with the desktop. Perhaps this would be a suitable workaround for you.
You can only enumerate windows on the same terminal services session (aka Remote Desktop session) as your process. However, given appropriate privilege, you can launch a subprocess in another terminal services session to do the work on your behalf, although you need to be aware of the potential security issues depending on how you do this.
Assuming that you've already got a handle to the target process, the simplest approach would be to use OpenProcessToken to get a token in the target session, DuplicateTokenEx to duplicate it, and CreateProcessAsUser to launch the subprocess. Since all you need is a yes/no answer, you can use the process exit code rather than needing an IPC mechanism.
Security implications: since your subprocess is running in the user's context, a knowledgeable user could prevent it from running properly. Also, if you do use an IPC mechanism, you'd have to treat the input from the subprocess as untrusted (check for buffer overruns, etc.).
An alternative approach would be to launch a subprocess in your own context but in the target session. IIRC, you can do this by duplicating your own token and using SetTokenInformation on the duplicate to change TokenSessionId before launching the subprocess with CreateProcessAsUser.
Security implications: the subprocess, and through it the service process and the service account, could be subject to shatter attacks (malicious window messages) and other risks, although the integrity level mechanism may mitigate this to some extent. It is my understanding that creating a separate window station and desktop (with appropriate ACLs) eliminates these risks, but I'm not sure offhand of the impact on the code you want to run. Another mitigation would be to use CreateRestrictedToken to remove all groups and privileges from the token before launching the subprocess.
Unless it is absolutely essential that the user not be able to subvert your ability to detect the existence of the dialog window, I strongly recommend the first approach.
If you give the service a local system account to log on with, you will be able to tick the "Allow service to interact with desktop" checkbox in the service's properties (from Service Control Manager).
See the "Log On" tab of the Service's Property Pages.
That might work for you. But unfortunately, it probably won't. Still worth a quick try?
We are developing a .net application to run on startup for all users. Now we want to hide this application from task manager -> process list so that logged in user cannot delete it. We are using windows-xp
Please let me know if this is feasible
It's definitely possible to hide a process; you're talking about designing a rootkit. If that's actually what you want to do, see this question.
It's usually not the right way to approach this problem however: if you're the admin of a machine and you don't wish other users to kill a process, you simply don't give them permissions to do it.
Have your users log on with a limited user account and have your application run under a different account.
To get logon time reliably, you can use some either the windows security logs or if you're on a domain, active directory services:
Getting Local Windows User login session timestamp in C#
Getting idle time is more complicated because it depends on what you consider "idle" to be, but if you consider GetLastInputInfo() sufficient, this question describes a good way to do it, with a user process reporting back to a system process:
Getting user Idle time in C#?
Since the user cannot kill the system process, you could have that watch the user process and recreate it if necessary.
That's what Windows security is for. Define user account's permission in a way that he/she cannot manage services or kill processes.
If the case is as you described in comments under Colin's answer, then you can run a service-level process that respawns user process every time it is killed (by user). This way it is even simplier. You can use CreateProcessAsUser from WinApi to execute process on behalf of the user: http://msdn.microsoft.com/en-us/library/ms682429%28v=vs.85%29.aspx
Hide it in plain sight : make it run as a service with name that looks like it should be part of windows.
Then have another service that watches for the this one shutting down and restart it.
I am trying to get my silverlight application running with elevated privileges in browser. However, no matter what I do, it doesnt get elevated.
I have tried to add registry key AllowElevatedTrustAppsInBrowser (as DWORD with value 1), and signed the XAP file using VS 2012. I also came across a blog that mentioned the clientaccesspolicy.xml file, but I was not able to allow elevated privileges with this either. I put the xml file inside the web project hosting the html file that displays the XAP.
Has anyone actually managed to get this to run?
I also tried following this: http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2011/04/27/silverlight-5-beta-rough-notes-trusted-apps-in-the-browser.aspx but im unsure about where to run the commands he runs on windows.
There is a good summary on how to enable in-browser elevated trust by Mister Goodcat here, where he also provides some troubleshooting tips:
One thing to keep in mind is that even if your application runs as trusted in-browser app, it is still subject to the security restrictions the browser itself imposes. That means that its possibilities may be much more restricted than if they ran out of browser, for example by Internet Explorer's Protected Mode. In addition, the Silverlight runtime itself restricts use of certain features for in-browser trusted apps, for example you cannot use the Window class and/or create additional windows when you're running in the browser.
If none of the above applies to you and you still run into problems, one thing to do is check whether your certificate(s) have been installed correctly. There's a snap-in for the management console for this. Here is an article that describes how to get there (note that you should add a snap-in for your user account, not the computer account as in this description).
You can also check whether your registry key is actually and successfully queried, for example by using a tool like Process Monitor from the Sysinternals Suite. Watch for operations of type "ReqQueryValue" of your browser executable that access the key we created above, and make sure the Result is "SUCCESS".
We have just discovered that code that calls the Win32 SetDateTime function needs to run in elevated mode in Windows 7, i.e. even when logged in as an administrator, one still has to choose to run the Set Date code as Administrator for the call to change the date.
Is there anything I can do in code to always call this function under elevated privileges?
You can use the ShellExecute API call to launch an executable with elevated privileges.
However, if UAC (user access control) is enabled on the machine, the user will still get the UAC prompt asking for permissions to run elevated.
So I don't think you can avoid the prompt for elevation permission, but at least your user doesn't have to manually run the program as an admin.
Please let me know if you need help in how to launch an executable as an admin.
This is just not how security works. Changing the clock is a very intrusive operation, it has a very large number of side effects. There is no mechanism in Windows, or any other operating system for that matter, where you could start a process with limited privileges and then just arbitrarily bypass these limitations and suddenly gain administrator rights. There wouldn't be any point whatsoever to running programs with limited privileges if that was possible.
If you want to do something like this then you'll have to run your program with elevated rights. On Vista and Win7 that requires you to run as a service or a scheduled task. Which require an administrator to get installed. UAC provides a way gain admin rights for regular programs, you have to include a manifest in your program so the user is notified about your privilege elevation. Google 'requireadministrator', take the first hit.
Like others have said, you need to spawn a new process to get elevated permissions, which will result in a UAC dialog.
If this is something you need to run unattended you could try running as a service. That would give you the elevated context you need.