#85842 - 2002-06-07 10:52 AM
Re: Is there a need for an ActiveX crypto Kix object?
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
At Shawns behest I'll throw my tuppence in...
KiXcrypt is not an absolutely cracker proof mechanism, as at some point in the processing the script file is exposed. It is a very short period, but it is there.
The password problem is solved with KiXcrypt by passing the password as a command line parameter, something like:
code:
kix32.exe logon.kix $Password=secret
The password never appears in the script, only the variable name. If someone did manage to rip the script, they still wouldn't have the password.
Back to the topic...
There are a couple of solutions I can think of, depending on what you want to do. File timestamps are easily faked - a copy of touch.exe ported from Unix will do the job nicely.
You could write the entire command that needs the password into the object, then you would never need to expose it back to the script. Something like:
code:
$Crypto=CreateObject("KixFunctions.Crypto") $Crypto.Password="lshdf872lads" $ret=$Crypto.Use("S:","\\SERVER\SHARE","Administrator")
If you need the password in the script, the securest method of ensuring it isn't hijacked is to use the MD5 hash of the script to peturb or salt the algorithm used to encrypt/decrypt the password. Of course the decryption routine will need to be able to securely identify the script that it is called from to be able to read it and generate the hash.
The encrypt/decrypt routine will ignore line 1 when generating the hash, as that is where you'll set the password.
One other thing to say of course is that if you use the password to execute another program (su.exe for example) you are asking for trouble unless you take precautions.
A cracker will simply replace the su.exe with a trojan which records command line parameters and environment variables then calls the real su.exe. Chuck in a copy of postie or blat to send the info to a Hotmail account and some code to copy itself to administrative shares on other machines in the domain. This can run silently capturing passwords for as long as he wants, and if he's lucky will spread itself through your entire company without being detected.
|
Top
|
|
|
|
#85843 - 2002-06-07 02:36 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
ah, ok, so this is getting interesting ... this line here:
code:
kix32.exe logon.kix $Password=secret
Where would that normally be kept ? Hardcoded in user manager for domains, or tucked away in a bat file somewhere ? Because, to be honest, I can imagine a couple of ways for a domain user to snoop around that, no ?
-Shawn
|
Top
|
|
|
|
#85844 - 2002-06-07 02:48 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
In the case of KiXcrypt you define it when you create the crypted version of the script. The command line is encrypted within the executable, and is used to start the interpreter - it is never actually written out anywhere.
A full example of a command line to encrypt a script with a password passed via the command line is:
code:
kixcrypt logon.kix kix32.exe %s $Password=mypassword
This creates an executable which when run will extract and execute the logon.kix script, passing the password "mypassword" in as the variable $Password.
You can do a similar thing with batch files. To pass a password to an encrypted batch file:
code:
kixcrypt -k logon.bat %s mypassword
Now, the password "mypassword" is available in the batch file as positional parameter "%1".
The "-k" switch stops KiXcrypt adding the KiXtart commands to delete the file, which if course would cause an error in a batch file.
The drawback is that if you change the password you need to recreate the encrypted script.
|
Top
|
|
|
|
#85846 - 2002-06-07 03:16 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
You can obfuscate it further if you like.
How about:
code:
kixcrypt logon.kix kix32.exe %s $SecretCode="USE S: \\server\share /user:secretuser /password:mypassword"
You can then EXECUTE($SecretCode) in your script, an no-one will know what it was, heh.
However we're drifting away from the original topic, which was far more interesting. [ 07 June 2002, 15:17: Message edited by: Richard Howarth ]
|
Top
|
|
|
|
#85847 - 2002-06-07 05:10 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Hmm. you make good points, Richard. I like the idea of never passing the password back to the script. However, in this case there would be limited functionality as to what the Crytpo object could be used for. I can think of a few methods that might be handy.
Starting with: $Crypto=CreateObject("KixFunctions.Crypto") $Crypto.Password="lshdf872lads"
1. mapping shares $ret=$Crypto.Use("S:","\\SERVER\SHARE","Administrator")
2. running a program that requires different permissions $ret = $Crypto.Run("file.bat","domain1\Administrator")
3. Accessing an object that might otherwise not be able to be accessed $ret = $Crypto.GetObject("....{whatever}....")
The only problem I see with doing it this way is that it is only secure if it can only be run in the context of a logon script. Otherwise, what would prevent someone from simply writing their own script and copying in the encoded password to do whatever it is they wanted to do with full admin rights? Also, it may be helpful if the info was domain-specific...
Brian
|
Top
|
|
|
|
#85848 - 2002-06-10 05:24 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
Stevie
Starting to like KiXtart
Registered: 2002-01-09
Posts: 199
|
On the topic of someone replacing an executable with a Trojan Horse, since this is not airtight anyway, it is incumbent upon network administrators to place these apps in NETLOGON or a subdir with read only access for the users. If that is done, they won't have the permissions to replace the files in question.
Still, though, I keep coming back to a method of encryption that doesn't rely on packaging the script into an executable. Certainly not as a replacement but as another option for admins out there.
The big sticking point seems to be how to stop the users from decrypting the passwords themselves.
I currently have an object working on my testbed that I think satisfies this. I'm sure you'll all let me know how reasonable (or unreasonable) this sounds.
As mentioned earlier, encryption can only be done if you are a member of the Domain Admins group.
Decryption only works if: -You are a member of Domain Admins -You are currently logging on (via logon script) to the domain (I finally cracked the nut on this one)
Further, the key to create the encryption is based in part upon the SID of the domain itself. Therefore, someone couldn't create their own "dummy" domain, and as a domain admin, decrypt the password. Since the decryption is based off information tied directly to the original domain. (I'm using more than just the domain SID so spoofing the SID will not work).
Having said all that, how would this be circumvented? Of course there are probably a dozen ways to do it but what would the easiest exploits be? Or have we decided that there is no way to safely implement this?
Steve B
_________________________
Stevie
|
Top
|
|
|
|
#85849 - 2002-06-10 05:42 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
My thought on how to prevent spoofing of the domain SID (and your other information), would be to have a server-side service running that would be able to send a unique code to the .dll assuming that .dll was called from the logon script. It could be seeded by a number chosen randomly when installed, or by one chosen by the person installing the service.
Brian
|
Top
|
|
|
|
#85852 - 2002-06-10 08:19 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
You could possibly have multiple modes of use. One mode may allow anyone to use it generically, yet another mode may require domain admin privilege and/or server service and/or logon script privileges. These can be determined by passing a second parameter.. so you can customize just how secure you want it to be.
Brian
|
Top
|
|
|
|
#85853 - 2002-06-11 10:09 AM
Re: Is there a need for an ActiveX crypto Kix object?
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
If you are going to use the service/SID method then there is little point in passing encrypted data.
The scheme isn't portable, so you can make the process much more simple and lightweight by just asking for the data you require. The local (login) part of the connection will provide the security credentials and the service will simply return the data asked for.
You would use is like:
code:
$sPassword=$oSecureLink.getPassword("ADOMAIN\SecureUser") Use S: \\SERVER\SHARE /user:ADOMAIN\SecureUser /password:$sPassword
or even:
code:
Execute($oSecureLink.getFile("Secret.kix"))
The data repositry is of course not visible to anything except the server service.
For simple password encryption I'd favour using the MD5 hash of the calling script as the salt or seed. The hash will ensure that the script has not been tampered with, so no-one can hack the script or create their own to decrypt the password.
You would use it like this: 1) Create a script called login.kix
code:
use s: \\server\share /password:$oSecure.decrypt("$sPassword")
2) Generate the encrypted password using the script as the seed/salt:
code:
passwordgen login.kix mypassword
This outputs "HIhdohs78721lksdf1nc0as765"
3) Execute the script: kix32 login.kix $sPassword=HIhdohs78721lksdf1nc0as765
The decrypt routine will read in the script file to generate the hash to use in the decryption routine. If someone changes a single character of the script file the hash will change and the password returned will be garbage.
The only tricky bit is securely identifying the script file so that you can read it in the decrypt routine.
The major benefit is that you don't require the server or even access to the domain - you can run the script anywhere including stand-alone so long as you have access to the decrypt object. That means you can access local password protected objects like ODBC databases or whatever.
|
Top
|
|
|
|
#85854 - 2002-06-11 09:21 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Am I misunderstanding you, Richard?
Is this much different than having a service that simply gives different credentials to a program or command being run in KiXtart? Kind of like a "hidden" SU?
$Object.Execute("kixtart command line","domain\administrator")
Basically specifying the permissions you want to use to execute a KiXtart command. (How to implement something like this sounds tricky, though.)
Brian
|
Top
|
|
|
|
#85855 - 2002-06-12 10:11 AM
Re: Is there a need for an ActiveX crypto Kix object?
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
quote: Am I misunderstanding you, Richard?
Maybe. Maybe not. quote: Is this much different than having a service that simply gives different credentials to a program or command being run in KiXtart? Kind of like a "hidden" SU?
It is more like a secure data server
The point that I was making was that if you are going to tie the solution to running on a specific domain during login, passing the data to a service to decrypt it is redundant and actually lessens security as the encrypted data is visible.
The data *might* be a domain password, but it could be anything you don't want people to see.
|
Top
|
|
|
|
#85856 - 2002-06-12 10:32 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
I think I see your point... (emphasis on I think! lol).
We can have a service running by which the kixtart script can pull info from provided the script has been "validated" by the service. Is that basically it?
Brian
|
Top
|
|
|
|
Moderator: Shawn, ShaneEP, Ruud van Velsen, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Mart
|
0 registered
and 248 anonymous users online.
|
|
|