Tell if the process is running in a Guest account
in [Win32 API]
|
From: nki00 on 29 Jun 2010 15:37 Jackie, I appreciate your train of thought. > I hope you plan on changing privileges or something for the guest account > so that it's impossible for someone to gain access just from reverse > engineering your application and removing the limitations in it. I believe the correct way in this case is to do all the checks in a service part of the program by impersonating a client running with lower privileges. Of course, this is not a 100% proof method but it's much safer.
From: nki00 on 29 Jun 2010 16:23 > I need to get some sleep now so I'll check back later. > Yeah, that's important :) Please do. > I think the system should deny/allow access to things rather than your > application checking whether an account is a member of the Guests group. > Just saying, in case you were thinking about doing this. Like I mentioned > in my last post. > Yes, I agree. But this is not just a single hole in the Windows security. They may change it in Windows 8, or 9, or maybe even 10 :) "Jackie" <Jackie(a)an.on> wrote in message news:4c2927e4$0$4305$c3e8da3(a)news.astraweb.com... >I found this but I think you'll have the same problem: > http://www.installsetupconfig.com/win32programming/accesscontrollistaclexample3_4.html > Thanks. I compiled all the samples given here so far and this is what I came up with (but it still doesn't work). What am I not doing right? BOOL DetermineIfRunningFromAGuestAccount(void) { BOOL bRes = FALSE; HANDLE hUserToken; if(OpenProcessToken(GetCurrentProcess(), TOKEN_DUPLICATE | TOKEN_QUERY, &hUserToken)) { HANDLE hAccessToken; if(DuplicateToken(hUserToken, SecurityIdentification, &hAccessToken)) { DWORD dwSz = 0; GetTokenInformation(hAccessToken, TokenGroups, NULL, 0, &dwSz); if(dwSz) { BYTE* pData = new BYTE[dwSz]; if(GetTokenInformation(hAccessToken, TokenGroups, pData, dwSz, &dwSz)) { PSID psidGroupSid; SID_IDENTIFIER_AUTHORITY siaNtAuthority = SECURITY_NT_AUTHORITY; if(AllocateAndInitializeSid(&siaNtAuthority, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_GUESTS, 0, 0, 0, 0, 0, 0, &psidGroupSid)) { PTOKEN_GROUPS ptgGroups = (PTOKEN_GROUPS)pData; for(DWORD x = 0; x < ptgGroups->GroupCount; x++) { if((ptgGroups->Groups[x].Attributes & SE_GROUP_LOGON_ID) == SE_GROUP_LOGON_ID) { if(EqualSid(psidGroupSid, ptgGroups->Groups[x].Sid)) { //Got it bRes = TRUE; break; } } } FreeSid(psidGroupSid); } } delete[] pData; } VERIFY(CloseHandle(hAccessToken)); } VERIFY(CloseHandle(hUserToken)); } return bRes; } Sorry, I had to remove formatting because otherwise this thing wraps it up even worse... PS. I bought myself this book: "Programming Windows Security" by Keith Brown, so I'm waiting for it to arrive in the mail. Hopefully after reading it I'll be able to better understand this world of Windows security APIs :)
From: Jackie on 29 Jun 2010 18:39 nki00 wrote: > Yeah, that's important :) Please do. Thank you. :) > Yes, I agree. But this is not just a single hole in the Windows security. > They may change it in Windows 8, or 9, or maybe even 10 :) I guess we need to take it into our own hands then, yeah. Silly but what can we do about it... > I compiled all the samples given here so far and this is what I came up with > (but it still doesn't work). What am I not doing right? > ... I don't think it'll work after all. Since it appears like -- and someone else pointed this out too -- it's not the guest account that is elevated (good thing, of course), but "the administrator". Do you type in a username/password to elevate the application? If so, the application is running under a different user. If not, maybe the "Administrator" account does not have a password and thus the application runs under that account? > Sorry, I had to remove formatting because otherwise this thing wraps it up > even worse... There are many "pastebin" services, but I use pastebin.com. :) > PS. I bought myself this book: "Programming Windows Security" by Keith > Brown, so I'm waiting for it to arrive in the mail. Hopefully after reading > it I'll be able to better understand this world of Windows security APIs :) I don't mean to imply that you made a bad purchase, but are you aware that it was published almost 10 years ago? Maybe it can still be useful for all I know. -- Regards, Jackie
From: Dee Earley on 30 Jun 2010 09:10 On 29/06/2010 21:23, nki00 wrote: > Yes, I agree. But this is not just a single hole in the Windows security. > They may change it in Windows 8, or 9, or maybe even 10 :) Or maybe Windows version 7... -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems (Replies direct to my email address will be ignored. Please reply to the group.)
From: nki00 on 1 Jul 2010 00:15
> I don't think it'll work after all. Since it appears like -- and someone > else pointed this out too -- it's not the guest account that is elevated > (good thing, of course), but "the administrator". Do you type in a > username/password to elevate the application? If so, the application is > running under a different user. If not, maybe the "Administrator" account > does not have a password and thus the application runs under that account? > Yes, you right-click the exe file and run it as administrator, then it asks for the password. So let's leave it at that. Still, I appreciate your help. >> Sorry, I had to remove formatting because otherwise this thing wraps it >> up >> even worse... > > There are many "pastebin" services, but I use pastebin.com. :) > You're right, I'm just too lazy to sign up and post there.... I know, it's just me :) >> PS. I bought myself this book: "Programming Windows Security" by Keith >> Brown, so I'm waiting for it to arrive in the mail. Hopefully after >> reading >> it I'll be able to better understand this world of Windows security APIs >> :) > > I don't mean to imply that you made a bad purchase, but are you aware that > it was published almost 10 years ago? Maybe it can still be useful for all > I know. > I know that, but there's really nothing else out there..... |