RunAs security solution please

[ant2ne]

I would like to use AutoIT to kick of installers via the RunAs function. I'd like to distribute these InstallerKickOff.exe to employees so that if they require a program they can basically install it them selves.

Of course, I'm concerned about security and having my little kick off installers decompiled and the password extracted.

I've done some googling but haven't come across anything definitive. I'm wondering if any of you who may have used autoit for something like this. And how you compensated for this possible security flaw. Or if AutoIT's current version support some sort of internal encryption.

Thanks

[Triblade]

Maybe if you are in a network you could run the InstallKickOff.exe as a special user. Then read the password from a file on the network with read-only access for that special user.

[PsaltyDS]

I would like to use AutoIT to kick of installers via the RunAs function. I'd like to distribute these InstallerKickOff.exe to employees so that if they require a program they can basically install it them selves.

Of course, I'm concerned about security and having my little kick off installers decompiled and the password extracted.

I've done some googling but haven't come across anything definitive. I'm wondering if any of you who may have used autoit for something like this. And how you compensated for this possible security flaw. Or if AutoIT's current version support some sort of internal encryption.

Thanks

There is a limited encryption, but it should not be trusted with admin passwords. Login credentials do not belong inside a script.

[ant2ne]

There is a limited encryption, but it should not be trusted with admin passwords. Login credentials do not belong inside a script.

Please linky me to information about this encryption and how it is used.

Like I said though, "I'm wondering if any of you who may have used autoit for something like this. And how you compensated for this possible security flaw."

[PsaltyDS]

Please linky me to information about this encryption and how it is used.

Like I said though, "I'm wondering if any of you who may have used autoit for something like this. And how you compensated for this possible security flaw."

Whatever encryption is used must be reversible, and therefore the keys required to reverse it must be stored along with the data. While you can make it a little difficult to decompile your script with Obfuscator, it will NOT be impossible. Even if you encrypt the password with _StringEncrypt() or something of your own design, the method to decrypt it must be there too (reversible again), and will be traceable if the .exe is decompiled.

Passwords do not belong in your scripts.

I have no link for you, as this is based on principles, not AutoIt policy.

[Jos]

\Like I said though, "I'm wondering if any of you who may have used autoit for something like this. And how you compensated for this possible security flaw."

I have build many scripts that had to run installers using adminitrator credentials.

We always used a Local PC account that had these credentials to mitigate the risk of exposing the AD.

On top of that we ran a login script that wouyld report any user that would login with admin scredentials.

Jos

Edited February 25, 2009 by Jos

[PsaltyDS]

I have build many scripts that had to run installers using adminitrator credentials.

We always used a Local PC account that had these credentials to mitigate the risk of exposing the AD.

On top of that we ran a login script that wouyld report any user that would login with admin scredentials.

Jos

I like the idea of a login script to report usage of the account. But unless the script is custom compiled for different credentials on each machine, cracking it once (by hypothetically decompiling the .exe) would give usable access to every machine on the network with that account. And using those credentials for remote penetration, privilege elevation, or creation of a new privileged account would not trigger any login script-based reporting.

I still don't like it personally, but then I work around a bunch of paranoids anyway.

[Triblade]

Like I said before.

Run the script from the logonscript with admin privileges.

Then point the script to a password file on a network share that only that admin account can see and read.

This way there should be NO way anyone can hack something to see the password.

(Except if the admin pwd is the same as the local admin pwd. Cause local passwords are ALLWAYS EASILY hackable)

[PsaltyDS]

Like I said before.

Run the script from the logonscript with admin privileges.

Then point the script to a password file on a network share that only that admin account can see and read.

This way there should be NO way anyone can hack something to see the password.

(Except if the admin pwd is the same as the local admin pwd. Cause local passwords are ALLWAYS EASILY hackable)

That, and many other methods, are viable if the Admin is initiating the process.

I think the crux of this issue is that a non-privileged user is initiating the script. In that scenario, credentials providing elevated privilege have to come from somewhere, and would have to be gotten before accessing something like an admin-only share.

I don't believe there is a "secure" way to do it unless at some point the user has to request action from an admin. Once the admin is involved, there are a thousand ways to go, one of which you pointed out.

[Triblade]

Ok as someone pointed out to me via pm, everything is hackable.

My statement was meant to be 'unhackable' for local files reading and reverse engineering autoit-exe's.

It is hackable via sniffing or other methode's I didn't think of.

I am still, however, of opinion that that is the easiest way of doing what you want the safest way I can think of now. Ofcourse you still should encrypt the password so thats it's at least not plain text readable via sniffing.

Edit:

I'd like to distribute these InstallerKickOff.exe to employees

I think this sentence made me think the admin with his mighty rights distributed it via some automated distribution system. Edited February 26, 2009 by Triblade

[Jos]

I like the idea of a login script to report usage of the account. But unless the script is custom compiled for different credentials on each machine, cracking it once (by hypothetically decompiling the .exe) would give usable access to every machine on the network with that account. And using those credentials for remote penetration, privilege elevation, or creation of a new privileged account would not trigger any login script-based reporting.

I still don't like it personally, but then I work around a bunch of paranoids anyway.

Its simple to hack any PC's admin account with standard software available so cannot see why that would be a worry.

So, if somebody screws around with the PC and get caught then its a violation and gets reported.

Jos

[PsaltyDS]

Edit:

I think this sentence made me think the admin with his mighty rights distributed it via some automated distribution system.

Yeah, the rest of that sentence was what I was on about:

...if they require a program they can basically install it them selves.

So the user would have access to and run the script.