I was trying to get a Uuid via NtAllocateUuids or simply calling UuidCreateSequential,
but Windows wasn't able to get an Ethernet or token-ring hardware address for my laptop.
And so, when the system is booting, windows sets the UuidSeed to a random number instead of a given MAC.
--> uniqueness is guaranteed only until the system is next restarted.
I was trying to manual set the UuidSeed with NtSetUuidSeed but i was getting a STATUS_ACCESS_DENIED error.
"Windows NT/2000 Native API Reference" has following remarks:
--The token of the calling thread must have an AuthenticationId of SYSTEM_LUID
Is there any way to achieve this from a process, running as Administrator?
Something like ImpersonateLoggedOnUser() could work but afaik this is also only accessible as LocalSystem :/
Thx ;)
You can create a program and schedule to run it using the AT command. The scheduling service run as the local system account. On Vista things are different and I'm not sure if that is possible any more. You could write your own service of course.
ImpersonateLoggedOnUser worked fine with a token handle returned from:
HANDLE GetLSAToken() //duplicate a system token from the "System" process
or
BOOL CreatePureSystemToken(HANDLE &hToken) //create a new system token
http://www.codeproject.com/KB/system/RunUser.aspx
CoreCode.cpp
Related
I am creating process using create process does anyone knows how to use create function if process is already running not create or externally having any other way to detect process is running.
On Windows, you use the Process Status API (PSAPI) to search through all the processes running on the system. The degree of access you have to this resource will depend on the privileges that the program is running under.
See the MSDN article
Specifically, you would invoke the EnumProcesses function to get a full list of the running processes IDs, then, using those IDs use other functions in the API to get information about them. For example, to get a processes name, and have it's ID already, you could call GetProcessImageFileName.
Beware that these functions have ASCII and Wide-character versions.
My Windows application uses
NetUserAdd to create a local user account
LookupAccountName to get user sid
NetUserGetInfo to get level-2 user info
NetUserDel to delete the local user account
In real environment, the application works fine, because nobody would add the user and delete it right away. However, my test does that, so it sporadically fails at NetUserGetInfo or NetUserDel in an unexpected way. There is no error code returned. The application just terminates silently in Windows 7 and Windows 10.
I could imagine that when NetUserAdd returns, the user account might not have been fully constructed yet in the background. Is there a recommended way to check whether a user account is in a stable state before calling NetUserDel?
LookupAccountName always succeeds, so it is not a good guard. NetUserGetInfo itself sporadically fails unexpectedly. I failed to find other API in MSDN documentation (very few examples there).
Instead of using those unstable win32 API, calling DOS command "net user" via system() can circumvent the issue.
Is it possible to get a C++ application running in Windows to request administrator privileges from the operating system at run time?
I know it can be done at compile time, but can't seem to find anywhere whether it can be done at run time.
Thanks for your help!
EDIT: What if I want the current instance to have elevated privileges? For example, I might have data stored in memory which I want to keep.
If you want the application to always elevate, you can give it a manifest, either by building one in (not compiling technically) or by putting an external manifest in the same folder as the exe. If you want to decide, as a person, to run it elevated, you right click the exe or short cut and choose Run As Administrator. If you are launching it from code, then as #vcsjones comments, you use the runas verb when you launch that process. For example:
ShellExecute( NULL,
"runas",
"c:\\windows\\notepad.exe",
" c:\\temp\\report.txt",
NULL, // default dir
SW_SHOWNORMAL
);
You can elevate a process only during its creation. When a process already runs, there's no way to change its security token: it either runs elevated or not.
If your application needs to perform an administrative task, and it usually runs non-elevated, you have to create another .exe which will request elevation with its manifest. To start a process elevated, you have to use ShellExecute or ShellExecuteEx function. From your main process you will need a way to pass the commands to that new process that will run elevated.
For more information about UAC, read Designing UAC Applications for Windows Vista series.
Not quite, but you can do the opposite—you can drop privileges if you already have them. So, you can have your program start out running as an Administrator, using one of the methods listed by Kate Gregory. Then, drop your unneeded privileges; see Dropping privileges in C++ on Windows for how to do that.
Add a manifest file into your EXE as described here.
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Your process (and threads) have a token assinged to them. That token already have all your groups set up. Under UAC, the Administrator group is disabled. UAC will remove that disabled group so you end up with a full administrator token.
To acheive the same, you must have the TCB priviledge. In other words, to elevate a process at runtime, you will need help from a process running under the SYSTEM account, and Microsoft isn't providing one, nor an API to control the current UAC implementation. Otherwise, it would defeat the purpose.
For the sake of completness, there is a whitelist of process that can perform some elevated operations without prompting. In short, your executable needs :
To be signed by Microsoft
To perform predefined operations, like with IFileOperation
The best explanation I found is this hack. It has been fixed since then, but is sheds some light on the whole thing.
Is it possible to get a C++ application running in Windows to request administrator privileges from the operating system at run time?
I know it can be done at compile time, but can't seem to find anywhere whether it can be done at run time.
Thanks for your help!
EDIT: What if I want the current instance to have elevated privileges? For example, I might have data stored in memory which I want to keep.
If you want the application to always elevate, you can give it a manifest, either by building one in (not compiling technically) or by putting an external manifest in the same folder as the exe. If you want to decide, as a person, to run it elevated, you right click the exe or short cut and choose Run As Administrator. If you are launching it from code, then as #vcsjones comments, you use the runas verb when you launch that process. For example:
ShellExecute( NULL,
"runas",
"c:\\windows\\notepad.exe",
" c:\\temp\\report.txt",
NULL, // default dir
SW_SHOWNORMAL
);
You can elevate a process only during its creation. When a process already runs, there's no way to change its security token: it either runs elevated or not.
If your application needs to perform an administrative task, and it usually runs non-elevated, you have to create another .exe which will request elevation with its manifest. To start a process elevated, you have to use ShellExecute or ShellExecuteEx function. From your main process you will need a way to pass the commands to that new process that will run elevated.
For more information about UAC, read Designing UAC Applications for Windows Vista series.
Not quite, but you can do the opposite—you can drop privileges if you already have them. So, you can have your program start out running as an Administrator, using one of the methods listed by Kate Gregory. Then, drop your unneeded privileges; see Dropping privileges in C++ on Windows for how to do that.
Add a manifest file into your EXE as described here.
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Your process (and threads) have a token assinged to them. That token already have all your groups set up. Under UAC, the Administrator group is disabled. UAC will remove that disabled group so you end up with a full administrator token.
To acheive the same, you must have the TCB priviledge. In other words, to elevate a process at runtime, you will need help from a process running under the SYSTEM account, and Microsoft isn't providing one, nor an API to control the current UAC implementation. Otherwise, it would defeat the purpose.
For the sake of completness, there is a whitelist of process that can perform some elevated operations without prompting. In short, your executable needs :
To be signed by Microsoft
To perform predefined operations, like with IFileOperation
The best explanation I found is this hack. It has been fixed since then, but is sheds some light on the whole thing.
I've written some sample code which when I call from the windows command prompt under the context of a normal user account, dump's all the user's saved credentials using CredEnumerate(). However, I really want to be able to do this from SYSTEM user context so I've tested my program from a SYSTEM cmd prompt.
When I running my program as SYSTEM, I run LogonUser like so:
bLoggedOn = LogonUser(userName.c_str(), domain.c_str(), password.c_str(), LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, &userToken_);
Then I run ImpersonateLoggedOnUser() on the token to give me the security context of the local user. After this I do:
bOk = CredEnumerate(NULL, 0, &count, &pCredentials);
And I'd expect this to return the credentials in the same way as if I'd not gone in from system and impersonated. Can anyone spot anything that I've missed to truly put myself in the user's context?
I guess I aught to answer this question myself since I've now spent ages working out how to do this and I'm not sure it's widely known. CredEnumerate/CredRead will never provide password information for domain passwords no matter what process context you're in or what token you have despite what it seems to hint at on MSDN. The only way to get access to the saved credential information is to do so using the undocumented function LSAICryptUnprotectData() which is in lsasrv.dll. This can decrypt the files you find in %APPDATA%\Microsoft\Credentials and can provide an identical data structure to CredEnumerate except with the password filled in. The only catch is that this must be done in the process context of lsass.exe (The windows security subsystem), no setting of privilledges etc is enough to give a normal process the rights to do this. If you're a hacker you can do this by performing a CreateRemoteThread() to inject a thread into lsass.exe or if you're trying to do this in a legitimate way, i.e you're extending the Windows operating system in some way for a third party application, like I was, you can do this by creating a Windows authentication package which lsass will load. This AP can then use a named pipe or some such method to allow interaction with the rest of your code.