(imported topic written by SystemAdmin)
I need to run a command in the context of the current user instead of the normal system context. I have the executable from BigFix, but do not have the syntax to use it. Is it similar to the run quiet syntax?
(imported comment written by SystemAdmin)
Hi Lewis,
The syntax from a bigfix action script is:
wait RunAsCurrentUser.exe
Example (6.0 only):
waithidden RunAsCurrentUser.exe cmd.exe /C powercfg.exe /change
(imported comment written by SystemAdmin)
Also, you may be able to do a search of your Fixlets for examples of Fixlets that use RunAsCurrentUser.exe. I found a few Fixlets in my BES Console that use it.
(imported comment written by BenKus)
Also, any Fixlet or action that uses “RunAsCurrentUser.exe” should have the relevance “exists current user” attached because “RunAsCurrentUser.exe” will not work unless a user is logged in the local computer.
RunAsCurrentUser.exe is available at http://support.bigfix.com/download/bes/util/RunAsCurrentUser.exe and it makes a nice tool for some tricky Fixlets that require a local user context.
Note also that you accept the local user privileges when you are running as the current user and if the user doesn’t have access to install or run certain applications, then your Fixlet or action will not work.
Also note that RunAsCurrentUser.exe immediately returns (without waiting for the sub-process to finish). If you want RunAsCurrentUser.exe to wait, give it a “–w” command as the first argument:
wait RunAsCurrentUser.exe --w cmd.exe /C powercfg.exe /change
Ben
(imported comment written by SystemAdmin)
Is there any way to run a custom Fixlet with the local systems administrator account? Similar to the RunAsCurrentUser.
(imported comment written by BenKus)
Hey David,
Unfortunately you cannot do this securely. There is a MS utility “RunAs” (available on most newer Win OSes), but it will require you provide the user password and there is not a way to make sure that user password isn’t available to a knowledgable attacker.
Ben
(imported comment written by brolly3391)
Ben,
That makes me think of a new console wizard or an addition to the existing Windows Software Distribution Wizard.
The wizard would prompt for the acount name and password that you want to impersonate and the file name and parameters that would be passed to the deliverable.
It would then run an automated compile job to embed the sensitive account information into a temporary wrapper .EXE.
This wrapper would perform a sha1 and size check against the deliverable to insure it only runs against the original deliverable and if they match then use the native RunAs function to launch the deliverable with the passed parameters under the supplied user context. The wizard would then publish the temporary wrapper and deliverable to the uploads directory and generate a fixlet to utilize it. Because the temporary wrapper is a compiled exe, the account information would never be exposed as cleartext.
You would need a compiled language where the compiler was either free or very liberal with it’s licensing in order to use it as a BigFix supplied wizard. I do not know of one off the top of my head.
(imported comment written by SystemAdmin)
Hi Brolly, this is a pretty good solution but unfortunately it doesn’t completely resolve the security vulnerability.
What can and does happen is that you end up creating many copies of that executable with different usernames and passwords in each. Someone can then collect a bunch of them and start doing bit comparisons between the executables. The bits that change are the ones that correspond to your usernames/password. A very determined and clever hacker could then use these bits to get the username and password out of the executable by looking at the bits directly.
This would likely be very hard and you might not be able to do it until you collect enough executables but it is still possible to do.
(imported comment written by Doug_Coburn)
Also I did testing with the RunAs program that comes with the operating system. The RunAs does not support scripted passwords and will give you an error message if you try to use one. As of yet I have not found a way around this, if some one else has I would be interested to hear this.
(imported comment written by brolly3391)
Tyler,
That is a good point. There are ways of further obfuscating the embedded password to prevent this type of attack but any delivery of account information via automation will present some sort of attack surface, however minimal. There is no way to totally eliminate this issue that I know of. It becomes a risk analysis/acceptance item.
Doug,
I did some quick research on RunAs and now realize that you are right. It does not support passing the password via scripting. You might check out an API call CreateProcessAsUser used in combination with LogonUser. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocessasuser.asp
You would be essentially writing your own RunAs with the credentials embedded instead of prompted.
Note: Avoid using the much easier CreateProcessWithLogonW. It has issues on XPsp2 and Server 2003 when called from the SYSTEM context. Also, it appears that the Secondary Logon service is a prerequisite to using these.
I guess every good idea comes with it’s share of issues.
Cheers,
Brolly
(imported comment written by BenKus)
Hey Brolly,
On the topic of embedding passwords into executables (or distributing passwords through any mechanism): This is a very BAD idea from our view.
One of our customers is a major bank on the east coast with 65,000 computers. They used this embedded-password-in-executable technique extensively (before using BigFix) and swore up and down it was “secure”. I made a bet with them that I could find their password and I won the bet within a few minutes (I just looked at the string table of the .exe file). There are ways to make the password more obfuscated in different ways, but they are fairly trivial to beat with a few methods (look through the executable, look into memory as the application runs, run the app step-by-step in a debugger, etc). Yes, it takes an advanced user to do these things, but you don’t want the security of your company easily defeated by an advanced user.
Any method you use to distribute a password to a computer will inherently be insecure… Just think that if the end computer can figure it out, then the end-user at the computer can figure it out… And those executable files can easily be copied around and you can take your time figuring out the passwords.
We take these types of security issues very seriously, which is why we strongly recommend that you don’t do this sort of thing…
Ben
P.S. We are willing to put our money where our mouth is… Post your .exe with password embedded and we will try to pull the password from it. Ryan Russell is one of our employees and he is pretty good at this kind of stuff… Check out his books: http://www.oreillynet.com/pub/au/1321
(imported comment written by brolly3391)
I agree with you Ben. There is additional attack exposure anytime you put a password into a file that can be examined over a long period of time in a remote location. There is no way to make it 100% uncrackable.
I will take your challenge for the fun of it though.
I whipped together this executable that launches one of the standard windows applications under an administrative account on my test machine. It will of course fail to launch anything on your test machine unless the user account exists with the correct password.
None of the information in this exe is sensitive, so you can publish the account name, password and name of the application that it launches on the forum here. I think the best you will be able to do will be a list of possibilities. I will acknowledge a win for you if the list contains is the correct account and password.
Windows Crypto API could also be used for an even more effective layer of security at the price of some learning curve and sweat equity.
Maybe there is a way to use a realtime encrypted communication between the BESRelay supplying the deliverable and the BESClient at action time that could hand off the account information over some sort of secure communications protocol? Beyond my current skills to write or even speak about in the most vague of terms.
In the end though, your point still stands. No matter how secure I can make it, any password embedded in a file can be broken with enough time, ingenuity and power.
Cheers,
Brolly
(attachment simply does not want to work for me here. even as a zip file I will E-Mail it to Ben as jessewk’s email is board only and has no attachment either)
(imported comment written by jessewk)
having trouble with the attachment?
if you can’t get it to work, email it to me and I’ll post it for you.
(imported comment written by Doug_Coburn)
Brolly how big is your attachments? I believe I set a 1 MB limit as the default for attachments.
(imported comment written by BenKus)
Thanks, Brolly. I will see what we can do when I get back to the office on Monday.
I will try to attach the file you sent me.
Password to the zip file is “BigFix”.
Ben
(imported comment written by SystemAdmin)
Can you, and will it work, to add an Admin rights to a local user account before running the RunAsCurrentUser utility and then take it off when finished installing the application?
I know you can do use the “ADMINISTRATOR ADD” and “ADMINISTRATOR DELETE” commands.
(imported comment written by BenKus)
Hey 52Merc,
I think that would work, but you gotta be worried about something going wrong and the administrator privileges being left on. For instance, there is an error in the script, the power is turned off at the wrong time, and so on.
Ben
(imported comment written by ryanlrussell)
looks like the embedded details are:
username: localadmin
password: ownrh#wln)lwn0
domain: .
(imported comment written by BenKus)
Hey Ryan,
Cool! Thanks for backing up my big talk on this subject!
Is this correct Brolly?
Ben
(imported comment written by ryanlrussell)
Nope, I don’t have it yet. I’ll be back with the right one…