Page 2 of 2 <12
Topic Options
#85838 - 2002-06-03 07:56 PM Re: Is there a need for an ActiveX crypto Kix object?
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
ok - done !
Top
#85839 - 2002-06-03 08:00 PM Re: Is there a need for an ActiveX crypto Kix object?
Stevie Offline
Starting to like KiXtart
*****

Registered: 2002-01-09
Posts: 199
You da man!
_________________________
Stevie

Top
#85840 - 2002-06-05 08:49 PM Re: Is there a need for an ActiveX crypto Kix object?
jtokach Offline
Seasoned Scripter
*****

Registered: 2001-11-15
Posts: 513
Loc: PA, USA
Steve, checking to see whether the user is in the admin or domain admin group is invalid, b/c a normal user would not be allowed to run the admin script your trying to run thereby foregoing the effort.

It seems as though this process has been moved to running the script from a DC. If that is the case, then rather than checking the process, would it not be feasible to place the decryption algorithm in a folder and assign the everyone(G) execute rights only? This would eliminate the need for a dll or ocx, however, I guess this method may be suspect to eavesdropping as mentioned above...
_________________________
-Jim

...the sort of general malaise that only the genius possess and the insane lament.

Top
#85841 - 2002-06-06 07:48 PM Re: Is there a need for an ActiveX crypto Kix object?
Stevie Offline
Starting to like KiXtart
*****

Registered: 2002-01-09
Posts: 199
The admin check is just to allow admins to run a script outside of the logon process. Since a user doesn't normally run a script outside of the logon process it won't matter to them.

The user will only be able to run the decrypt function while logging on. That's to prevent them from just writing their own script to decrypt it later.
_________________________
Stevie

Top
#85842 - 2002-06-07 10:52 AM Re: Is there a need for an ActiveX crypto Kix object?
Richard H. Administrator Offline
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 Offline
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 Offline
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
#85845 - 2002-06-07 02:55 PM Re: Is there a need for an ActiveX crypto Kix object?
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
wow - ok - I'm on the same page as you now. Very clever ... so the only time your ever really exposed is during that brief period of de-compression, and then again, the password is never really exposed in the script anyways (its a $var) ... wow ...
Top
#85846 - 2002-06-07 03:16 PM Re: Is there a need for an ActiveX crypto Kix object?
Richard H. Administrator Offline
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 Offline
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 Offline
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 Offline
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
#85850 - 2002-06-10 05:57 PM Re: Is there a need for an ActiveX crypto Kix object?
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
I like where this heading Steve, but there is one common scenario we forgot to mention - when a domain admin writes an admin script to hand-off to say, a help desk, the help desk folk wouldn't have domain admin access (maybe) - but like Howard Bullock might remind me - probably just splitting hairs here.

-Shawn

oops - someone has a long line ... but since I begged Richard to comment - what the hell eh ?

[ 10 June 2002, 17:59: Message edited by: Shawn ]

Top
#85851 - 2002-06-10 06:37 PM Re: Is there a need for an ActiveX crypto Kix object?
Stevie Offline
Starting to like KiXtart
*****

Registered: 2002-01-09
Posts: 199
Brian's idea is more secure since you're putting custom data into the domain information. Which begs the question: does it provide enough additional security to justify the administrative overhead associated with adding an additional service onto the domain controllers? vs. using existing SID info? Thoughts?

Shawn, I thought about whole local vs. domain admin thing. If it decrypts for someone with local admin rights then anyone with admin access to their own machine (which would have to be a member of the domain in question) could decrypt the data. IMO, it's better to require domain admin access. It's a lot harder to come by. The security benefits outweigh the cost of not being able to give domain maintenance scripts to local admins.
_________________________
Stevie

Top
#85852 - 2002-06-10 08:19 PM Re: Is there a need for an ActiveX crypto Kix object?
BrianTX Offline
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 Offline
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 Offline
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 Offline
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 [Wink]

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 Offline
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
Page 2 of 2 <12


Moderator:  Shawn, ShaneEP, Ruud van Velsen, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 248 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

Generated in 0.071 seconds in which 0.025 seconds were spent on a total of 13 queries. Zlib compression enabled.

Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org