|
|
|||||||
Is there a way to pipe files in kix without using cmd.exe. This is what I currently have.... Code: Shell 'cmd.exe /crunas.exe /user:xdomain\xuser "\\server\enablefps\ntrights.exe -u @DOMAIN\@USERID +r SeNetworkLogonRight">&2|sanur.exe $pass' but I don't want to use cmd.exe?? Thanks [ 16. October 2003, 21:43: Message edited by: sliver ] |
||||||||
|
|
|||||||
why not? you might be able to do it without compsec but don't see no reason. |
||||||||
|
|
|||||||
I don't use cmd.exe either because the correct syntax is %COMSPEC%. However, I do have to wonder about your understanding of security that you are willing to write passwords in plain text into a script. |
||||||||
|
|
|||||||
I actually use kix editor to compile the password as a variable so the password is encrypted. The problem is that when I run this command using cmd.exe or %comspec% (which ever you chose)ntrights.exe displays a box saying that it is granting the rights....we want this command to be completely silent but sanur .exe needs the password piped somehow...it's kind of an odd problem. I tried /I and wkix32.exe but since it is calling NTrights.exe the box still gets displayed. |
||||||||
|
|
|||||||
HA! Security by ignorance! quote:It is NOT encrypted. Just look through the temp files! |
||||||||
|
|
|||||||
We should just outlaw SU and all the different RUNAS utilities. |
||||||||
|
|
|||||||
Actually I will disagree with you on this one. I am aware that the kix script itself can be seen in the temp files but when compiled (or made into and .exe however you prefer) with the kix editor there is the ability to choose to pass command line variables. And so $pass=password in the .exe package creator would provide some level of security...I checked the temp files and it just shows up as $pass in the temp file (just like it says in the script so the password certainly is not in clear text. How good the encryption is (It's actually not encryption but just compiled...but not clear text) is another story. You could also encrypt into a .vbe file and get the same effect. So is piping through DOS the only way to pipe in kix??? [ 17. October 2003, 07:32: Message edited by: sliver ] |
||||||||
|
|
|||||||
no. but you don't pipe via dos in your example either. but via command-translator-proggy. |
||||||||
|
|
|||||||
quote:Are you sure? Unless the execution string is encrypted in the executable you will be able to view it as plain text. There are many tools to do this, but the simplest way is to open the file in an editor and page through it. Your command line parameter will probably be easily located, either by search for "pass", or "p^@a^@s^@s", where "^@" is a null (for unicode executables). I've had to do this two or three times in the last year to get access to "compiled-in" information. People are generally shocked that what they had assumed to be secure was in fact trivial to reveal. |
||||||||
|
|
|||||||
I've looked through both text files and I do not see any semblence my password whatsoever. Also...the account is a local admin on pc's here but only on client machines (it's not a domain admin or anything). Our GPO settings prevent this account from accessing machines remotely so the worst a user can do is mess up his own client machine. You could just as easily have a user throw lophcrack on a machine and crack the local admin password...then remove it. I've never had one problem with using the editor. Also....the temp files remove themselves when the script is complete and users do not have the ability to access a machine remotely nor can they access their console while the script is executing so it would be very hard for them to even get to these text files in the first place. A good hack can get in just about anywhere but if he hacks the local admin pass I'm not that worried about it.....I think it has happened twice since I've been here and both times due to loph crack (so we shut that sown with another GPO setting). |
||||||||
|
|
|||||||
What text files? Open the compiled exe with notepad. You will see all the text strings in the executable, including the command line (and the password). If the command line is encrypted then it is more secure, otherwise it doesn't take much of a hack, does it? quote:How do you stop them opening the executable after they are connected? Or copying the executable and taking it home to play with? Or re-running/terminating it until they get the temporary files? You (and anyone else who comes across this thread) need to understand that finding plain text passwords in executables is as simple as opening them with notepad. It may well be that this level of obfuscation is sufficient in your environment, but if you have users sophisticated enough to use L0phtCrack they won't be misdirected for long. If you understand the implications of what you are doing and feel that the risk is acceptable then go ahead, but I know our security auditors would blow a fuse. |
||||||||
|
|
|||||||
I absolubtly do not see this pass in clear text anywhere in text file.....I'm not sayin it's impossible to get...I just don't see it. I did a search for the password...the first letter of the password and the first 2 letters and nothing. How about this...I will send you an .exe with a dummy pass and if you can tell me what the pass is I will reconsider my stance on this issue. I am not going to outline our whole security policy but if they did get this *local admin* password...we would know about it...that's how we caught the 2 with loph crack. This is a really touchy subject for you guys huh!! |
||||||||
|
|
|||||||
I didn't try the unicode one yet..I will check that now |
||||||||
|
|
|||||||
Touchy? Us? Not at all. We are actually trying to help. Consider this constructive criticism The security implications of using KiXtart for administrative purposes comes up on the board regularly, so we've got quite a good idea of the pitfalls. You are welcome to send me an exe (rename the extension or it will get bounced) and I'll review it for you. Email address is in my profile. It will have to wait until Monday though... the weekend is just starting here, hoorah! |
||||||||
|
|
|||||||
Can't find it in unicode either. It's not that I don't believe you...I am sure that you are probably right...that there are ways to read the compiled code...I just want to see if it's as easy as you make it sound.....if it is I will consider changing the policy. What about a .vbe file??? |
||||||||
|
|
|||||||
OK...I sent you .exe....please only use notepad for this challenge since this is the app in question (or something native to 2k\XP). And thanks for all the info. you can get some great stuff on this site and you guys have always answered my questions. |
||||||||
|
|
|||||||
Ok, first the good news The contents are not encrypted but they are compressed (zipped). This means that the command line and script contents are protected from casual browsing of the executable. However, just so that we don't get too complacent, your password is (please supply your own fanfare...): code:I'm not going to give away how I cracked the password as there may be quite a few people using the packager as a way of securing tasks. Suffice it to say that it took about 15 minutes and the tool I used to crack it was...KiXtart.gltm844hy@#4t Now that I have the method of course it would take seconds to crack new versions. I should stress that this is not in any way a failure of the Kix editor product. The problem is that there is not yet any secure way to execute a KiXtart script. Off the top of my head, the only secure way or running a script with elevated privileges is:
Administrative security is always going to be a balance of risk against practicality and cost. If packaging the files and obfuscating the password is sufficient in your environment, and the cost of the security being breached is less than the cost of implementing a more secure solution then you should implement it. You should however ensure that the powers-that-be buy into it. |
||||||||
|
|
|||||||
There is a way to have a client initiate running a script on the client under administrative privileges without exposing the password at all. However, it does require some setup as it employs a client-server solution. Here it goes: Create a Kixtart script on a server with the following requirements:
|
||||||||
|
|
|||||||
Yes, where you have access to a logon server and the task is machine oriented that is a pretty good solution. The same caveats about only running executables (such as KiXtart) and scripts from a trusted server share apply. |
||||||||
|
|
|||||||
The server component does not necessarily need to reside on a logon server or DC. A member server would be sufficient. However, you would need access to the login script in order to add the client component. Security is relatively easy to implement in the server script by adding validation logic to the install requests, e.g. cross-checking computer names, user names, and IP addresses, to ensure that only authorized computers/users receive the requested application. |
||||||||
|
|
|||||||
Very nicely done Richard....that is the correct password. And thanks again for opening my eyes to this. |
||||||||
|
|
|||||||
Any thoughts on using a .vbe file to do this??? |