If the concern is obfuscating passwords used in logon scripts, wouldn't passing them as command line parameters in the logon script definition hide them better? Then they are never in the script itself and the only people who can see them are people with access to the user database.

As for hiding the working of your script, an option to compile to pseudo-code, or byte-code would be interesting. It would hide the workings from a casual browser, and speed up the run-time enormously. Of course on the downside a de-compiler for byte-code is very simple to write.

my 1,5 cents

Unfortunately, users' login scripts are considered "public" information by NT. Despite the fact that this information is stored with the user's account in the domain SAM, ANYONE could view the password argument.

Check it out from the command line:
net user <username> /domain

This procedure would be useful, say, to provide an admin password to use with su.exe. However, any password made visible to the user's security context would be visible to the user, regardless of whether that password were passed as a command line argument, or if it were contained in a file. Again, strong encryption is the only possible solution. Decryption should be handled inside the script, so that it executes in the client's memory space & not transmitted clear text over the network.

NET USE [devicename | *] [\\computername\sharename[\volume] [password | *]]

I put this in a script

NET USE X: \\server\share /user:fred /domainname

and "/domainname" was actually the password. Looking at it, you would just think of it as another switch. Often you don't see what is in front of you.

I wouldn't recommend this type of security in the workplace though, but it give you an idea..

cj

RUUD,,,, what about something built in with an update, KiXtart 2001a ?

I could see knocking off something that compiles to psuedo-code in the timeframe of 2001, but expect that strong encryption would run us into 2002.

So just like there is a console-less version (wkix32.exe), there could be secure version (maybe wkix32s.exe).

I have a question?

Shut up and finish your test!

Yeah, I'm sure it is not an easy task, but having something built-in I think is probably about the only real solution... or a Service Pack that would support all Windows clients with this type of support.

In all I can't think of a secure solution that doesn't require that the decrypting is done on the fly within the interpreter.

2) it won't allow to "extract" files to change some things within, but only execute them.

3) A "builder" must me created, as it will be needed to create the exe with the specified file, and the command the exe will run

4) find someone to create a such thing

Advantage of this one is that it would be completly independant of any scripts language

That was my € 4 cents
A last thing : before thinking about the size, it should be interesting to see what size it show after an UPX (exe compressor, with an incredible rate. 2 Mb => 150 kb)

[ 13 September 2001: Message edited by: Popovk ]

If you have a robust operating system which will allow a process to allocate a private area of memory and place security controls on it so that no other process can read it even if the process is spawned by the same user, then you are safe from memory scanning. Unless your smart user forces a crash and preserves a swap file with the information in it of course.

If your operating system won't allow this then the memory (including RAM drives) can be read, and possibly changed.

The other problem is, if I can read the program I can take a copy to another computer which I have complete control over and fiddle to my heart's content.

A quick search at www.download.com gave me WinHack and MemoryBrowser, both of which will allow you to browse your local PC memory and RamDump which will dump the contents so you can play with it off-line.

Of course you need to be quite a sophisticated user to think about cracking the encryption that way, or using a debugger to step through the code and interrogate internal buffers.

You need to decide whether you simply want to deter accidental disclosure of passwords and the script code, or if you need a highly secure solution.

While safeguards could be put in place to test whether KIX is running from logon, whether the speed of execution is reduced by an external debugger, etc., these too could be overridden by a good hacker. I think what is needed is a server-side service that the client-side service sends security requests to.

We use a term called "due diligence" which means we need to take all reasonable effort to secure our environment. FE, I use SSL on my intranet to secure confidential HR and Payroll information. Maybe nobody sniffs packets on my network to pick up clear text, but I would be remiss to use "security by ignorance".

I think Ruud knows by now that we are all looking for something that would be handle our needs.

Have a Nice Day...

Like you, I enjoy playing the Devil's advocate. I am simply echoing the sentiments I see on this board. I also don't like to see security by ignorance. By that I mean the user's ignorance. Mind you, my / our ignorance is the greater sin.

Aside from conveying our needs / thoughts, I believe this thread has helped to raise awareness of different perceptions of "security".

In the end, Ruud will decide if / and / or what level of security and encryption to implement. This decision, we eagerly anticipate.

[ 14 September 2001: Message edited by: LLigetfa ]

-Shawn

[ 14 September 2001: Message edited by: Shawn ]

Richard, I was toying with this idea, but never got around to implementing it. When you say small.. what have you found? I had an idea to use the EXECUTE() function with an entire script inside, but I found a size issue there too.

Shawn, LTNH, how's tricks. I was thinking of the VBsecure thing too.

cj

The reason the size is an issue is because the first thing the script does is to delete itself. For this to work the entire script must have been read into memory, and Kix must not attempt to refer to the original text again.

For the password issue, the passowords can be assigned to variables in a very small encrypted script which kicks off a larger unencrypted script. The large script would have to be read only, have a hard coded path and you'd need to include sufficient controls in the smaller script to ensure that someone hasn't copied it and set up a psuedo-domain at home to emulate yours with a trojan kix32.exe which simpy prints the script rather than running it.

Even better, resources requiring passwords would be established in the very small script first.

I should have the code in a running state in the next few days - it's quite simple but my 'C' coding is pretty rusty so it's taking a while. Oh, and there's work getting in the way too. Then I'll need to compile it for Windows (I'm developng it under Linux) and faff about with differing variable type lengths, file semantics etc then I'll drop it somewhere for those interested to play with.

If there is enough interest I may even publish the source code

[ 14 September 2001: Message edited by: Popovk ]

Oh! and don't forget to leave a backdoor in the program for all the Government Authorities.... they all seem to want to try and keep pushing that <LOAD OF CRAP> I'm sure they will try to Capitalize and use the recent tragedy in the US as another reason to have these backdoors... even though so far it has not been shown that they have used any encrypted software to accomplish their deed, and as usual it will only handicap the legal users. Criminals don't pay attention to any of these laws anyways.

Jumping off soapbox now...

[ 14 September 2001: Message edited by: NTDOC ]

...stepping down. There are differing rules for encryption in some countries and restrictions on 128-bit exportation, but we all know that. How to build a scalable secure KIX to satisfy these restrictions is the challenge.

my €0.0012

my 2 bits.

A short reaction on this soapbox.

• RE-LLigetfa: decrypt in batch that a memory dump would defeat it.
  - people who analyze memory dumps aren't normal users. kacking of any
  program is always possible. TIP: only not existing programs are secure.
  Richard Howarth calls it: a sophisticated user.
  Popovk tals about: You have users, not hackers.
  - it is true to create a high encruption to reduce possible
  attacks, but it is also important that a decryption doesn't cost
  too much time.
  
• RE-GCrumply: passing passwords to scripts as command line arguments
  This isn't necessary. We have think about some modifications to our
  tool codec.exe, which will personalize your CODEC version.
  Suggestion 1:
  By such a personalizing we think about f.e. domain-name or other
  unique element of your environment.
  During the encryption with this personalized version and YOUR password
  a file will be created, which can only decrypt with CODEC when the
  environment is correct. Reason: environment characteristics and password
  will be inserted as scramble information on random locations in your
  encrypted file and the general version of CODEC recognized this additio-
  nal information. So you can keep your personalized version secure.
  Benefit
  

  code:

  ---

  
  copy such encrypted file isn't interesting because such script can't never
  be decrypted in another environment.
  

  ---

  
  Possible problem is by using of kixtart call command (see later
  for a suggestion about the possibility of reading plain text scripts or
  one-way encrypted scripts by kix32.exe).
  
• RE-CJ: used passwords that do not look like passwords
  Such way of thinking we like, but by the usage of username + passwords in
  f.e. BAT file we encrypt it with BAT2EXEC + SECURE21 andin f.e. kix-scripts
  we do it with CODEC + Compress.
  
• RE-Richard Howarth: generates a self decrypting executable
  - you can use any location for your temporary decrypt scripts. It isn't
  necessary to use the %temp% location.
  Suggestion 2:
  create a BAT file which decrypts your script and runs script by
  kix32.exe. the location of source and destination are possible
  unexpected location on your server and clients.
  with BAT2EXEC + SECURE21 we make those information secure.
  See topic:
  http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=1&t=002750 how to make your script secure
  - In another topic we mention a possible SECURITY LEAK for kix32.exe
  Problem: how can an user steel your script.
  Simple: when an user can replace the kix32.exe file. it is easily to
  read the script file and write it to a floppy-disk. the input for kix32.exe
  will never be an encrypted file. it is plain text.
  Most user can have problems with a script file with very very long lines.
  Special tricks must be done to read in such cases all lines.
  Also it is easily to catch parameters which were added by the kix32.exe
  call.
  Suggestion 3:
  A self decrypting executable with kix32.exe and script included
  can be a good solution.
  Popovk talks about: it would be completly independant (an EXE file
  created by a builder which combine kix32.exe and specified script file[/i]
  See topic
  http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=1&t=002053 security leak
  
• RE-Shawn: MCA mentioned that VBScript (WSH) has an encryption feature.
  Indeed it was a topic, but we discover that it doesn't its work very well and
  also the way of encryption is very poor.
  Also in a topic we warn that such encrypted file can be hacked easily.
  For us is the way of encryption/decryption by VBScript not an acceptable
  result.
  
• RE-Richard Howarth: a trojan KIX32.EXE which simpy prints the script rather than running it.
  Suggestion 4:
  

  code:

  ---

  
  encrypt your scripts with an additional program (one-way)
  and
  make it possible that kix32.exe can handle plain text scripts or an encrypted scripts.
  possible kixtart CALL commands can also handle both script files.
  temporary files are not necessary by such method.
  

  ---

  
  Benefit: for a torjan KIX32.EXE is an one-way encryption not interesting.
  Only the released KIX32.EXE program can decrypt your encrypted file and he
  isn't using any temporary file at all.
  

We hope that above suggestions and reactions give Ruud more ideas.
Greetings.

See also topic
http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=4&t=000093 one-way encryption

We were missing the contents fo second page. Later we will a reaction on it. After analyzing the release KixCrypt.exe.
Greetings.

Encryption / piping...

On the topic of piping, this too parallels the client/server idea mentioned here. Mainly that the client would have instructions "piped" to it from the server.

The "client" could be running in the user's context or a spawned script running in the local admin context.

The server-side script could handle admin-like functions not available to the user or local admin. Security checks would need to be instituted to prevent spoofing.

Another idea was adding some parameters to check for before unpacking kix and the scripts. They could be the domain name, or other things, so it will only work in a particuliar network and nowhere else. And of course, encrypted into the exe package. You could even add a forced reboot if it not what wanted
Something else too : scan when executed for thread name to seek particuliar programs, the most common (like ?Ice, or other memory dump utilities) to defeat less-experimented hackers
Remember that nothing won't resist longer to an experimented hacker, but as said, they work for us

If correctly done, it can be a little more heavy than 150k (well, 200-250), but i think it will be the cost to
1) secure scripts with full admin password within
2) No trouble with a Kix.exe trojan, as it will always be executed from the whole package
3) No other IT altering some stuff and resulting after with dozens of call from users saying : it doesn't work!!!
4)Possibility to have kix run under admin right

It's not really good for slow WAN connections, but at this point seems we don't have choice if we don't want to handle the possible kix trojan.

Last days i put everything on paper to get a little clearer, if you are interested

[ 15 October 2001: Message edited by: Popovk ]

We read the rest of this topic and here is our long reaction:

• RE-TheLanMan: knows anybody how ScriptLogic bypass the problem with
  (local) administrator rights or other rights?
  We think that it will not be a simple call, but something like an
  "username/password" will be used before execution starts.
  Without using such kind of info, it can be possible that any kixtart-
  writer can create and run a kixtart script with any type of rights.
  Such situation isn't wanted and is for most organization unexpectable.
  
• RE-Popovk: we like also the idea of a compressed with kix32.exe and
  (encrypted) script files.
  Our earlier suggestion is that you don't need any additional parameter
  during the kix32.exe call. Kix32.exe can handle plain text and those
  encrypted scripts.
  By the one-way encryption you must have the capability to specify which
  elements of your environment should be checked and what will happen
  by an incorrect result.
  Check f.e. @domain, @wkstat, @userid, @ipaddress, @os, .....
  Result by incorrect result f.e. mail administrator (= specified mail
  address), remove package from client, reboot client, ....

  Structure:
  

  code:

  ---

    - create a script
    - encrypt script with an additional program. you can specify elements
  to check for and what to do by an incorrect result.
  encryption will be one-way.
    - (idea Popovk): compact kixtart binaries and encrypted scripts to one file (= package)
    - by running package the file will only be copied to memory
  and the encrypted script will not be decrypted.
  a memory dump with encrypted scripts aren't interesting.
    - run encrypted script with kix32.exe or wkix32.exe file.
  kixtart recognize the encrypted file and it will first check the verification
  elements.
  by a correct result kix32.exe or wkix32.exe will decrypt your encrypted script
  internally and run your code.
  

  ---

  
  
• RE-Richard Howard: some remarks about KixCrypt.
  - by calling it without any parameters it is unwanted that your program
  waits for user input. most programs we know returns some help information.
  - the result is always the same by the same parameters. such situation
  gives 'hackers' the capability to analyze "how are password be stored".
  

[ 21 October 2001: Message edited by: MCA ]

ScriptLogic 3.XX overcomes the Administrative issue with writing to the registry by installing a DC-based service (running as a Domain Admin) which remotely modifies the client's registry, when requested by a client-side command line utility.

ScriptLogic 4.XX can run any program as an administrator, much the same way other management apps (like SMS) do. By using a server-side and client-side service, and then making the request using a client-side command-line program.

---------

Regarding encryption: during my last phone conversation with Ruud, he mentioned that tokenizing is on the top of his priorty list for the next version of KiX.

---------

Hope this helps,
Brian

Thanks for your input and specially the reaction from Ruud.
Greetings.

Thanks for your comments and for taking the time to download and check out the KixCrypt binary.

I'm aware of the short-comings of the KixCrypt process. For a start the password is included in the binary as clear text. The password won't allow you to decrypt the file without knowing the contents of the code tables and peturbing parameters but it will help reverse engineer the encryption *if* you get an encrypting version of the binary. Secondly, and more importantly the source code is published. Anyone can take it and change it so that the decrypted file is not deleted. Now all they need to do is to grab the encrypted script off the end of your file and tack it onto their hacked version. If you have the encrypting binary you can also use a char(0) attack to expose the XOR tables. Together with the password this will give you a decrytion key.

KixCrypt is not intended for use by "normal" users, so the fact it dumps to the console is not a problem. Anyone who runs it without reading and understanding the associated help pages should expect to have problems. The instructions on use are simple and quite explicit. There is even a specific warning about binary output to the console

If you want to *really* use it you should take the source code and change the encryption tables and peturbing parameters and use the customised version in your own organisation. Now no-one has your personal encryption algorithm.

After you create a distributable version of kixcrypt with your encrypted script attached the kixcrypt program will not encrypt again. This means your cracker type cannot create simple scripts and keep pushing them through to determine the algorithm, unless you publish your personal version of kixcrypt.

I don't know if you've looked at the source code for KixCrypt, but the encryption algorithm while simple would be devilishly hard to crack without clues, moreso with long scripts. The encryption is a simple XOR, but the password is not used to do the XOR itself, the password is used to generate a key which gets the encryption values from a set of "one time pads". There are also bitshifting processes and the sequence of the password characters used is not linear - sometimes the characters are skipped.

KixCrypt is not a finished product - I tried to emphasise this as often as possible in the files and on the download page, heh . It works and you can use it in it's current state in a live environment, although you would want to compile your own version so you don't have the same encryption algorithm as is in the download binary and source files. The purpose was to show that something can be done quite simply, and to encourage more debate. Other than bug fixes and updating the hash checksum for new relases of KixTart I probably won't be adding any features to KixCrypt. I released the source code so that anyone who wished to can have a hack about with it and customise it for their own use.

Some things you might like to add are:

• Encryption or obfuscation of the password
  
• Denial of binary or repeated characters to avoid exposing the code tables, in case someone gets hold of your encrypting version.
  
• Replace the "one time pads" with a pseudo random number generator.
  
• Peturb the data so that it is not 1-to-1 with the original script. Perhaps some sort of block switching.
  
• A more intelligent method of determining that the kix32.exe you are running is not a trojan
  
• Adding a simple compression routine
  
• Create an encrypted script without requiring the redirection and catenation process.
  
• Setting internal values in the binary part of the encrupted script so the values aren't so easily exposed.
  
• Including a kixtart binary as part of the distribution.
  
• An option to set a command line argument so that passwords and even short pieces of script which can be "execute()" can be passed into your script as variables so that they never appear in your script itself.
  
• Compile a "decryption only" version which cannot be hacked back into an encrypting version.
  
• Change the output file name generation so that it is not so predictable.
  
• Include a check that the file *can* be deleted once created. If I was cracking something like this, or any other process which creates a temporary script the first thing I'd try would be to run it in a directory which has add but not delete permissions.
  
• An asynchronous forked process to remove the decrypted script after KixTart has loaded it.
  

quote:

---

FYI - Ruud stated to me a while back that tokenizing scripts is high on the ToDo list. I would suspect that it will be part of the next point release, since it ovbiously did not make it into 4.10.

Of course, whatever Ruud does should not be considered high encryption, so perhaps this thread still has purpose...

-Brian

---

quote:

---

Regarding encryption: during my last phone conversation with Ruud, he mentioned that tokenizing is on the top of his priorty list for the next version of KiX.

---