Sign in to follow this  
Followers 0
twinnis

Security question?

13 posts in this topic

Hi.

I would like to know if there is a way to secure a .exe file when I execute it. I am using RunAsSet in my script to start a new schell(explorer.exe) to make a SU for WIndows. My idea is to run a compiled autoit script from a share with a .lnk shortcut distributed with the logonscript in a NT 4 domain with WIndows XP clients. When I run the .exe from a users PC I would like to be really SURE that it is MY .exe and not an .exe someone else wrote with a keylogger for example that have tha same GUI as my .exe.

I have another question regarding the .exe above. In UNIX, when you want to logon with ROOT you also have to logon with a user account. Is there a way in Windows to do the same? What I am looking for is way to confirme the domainadmin account with a valid user account that are logged in the DC logs.

Thanks in advance.

Twinnis

Share this post


Link to post
Share on other sites



Hi.

I would like to know if there is a way to secure a .exe file when I execute it. I am using RunAsSet in my script to start a new schell(explorer.exe) to make a SU for WIndows. My idea is to run a compiled autoit script from a share with a .lnk shortcut distributed with the logonscript in a NT 4 domain with WIndows XP clients. When I run the .exe from a users PC I would like to be really SURE that it is MY .exe and not an .exe someone else wrote with a keylogger for example that have tha same GUI as my .exe.

Place a password in your script. Then you can make it ask for a password, if correct answer given continue else exit.


Get Beta versions Here Get latest SciTE editor Here AutoIt 1-2-3 by Valuater - A great starting point.

Time you enjoyed wasting is not wasted time ......T.S. Elliot
Suspense is worse than disappointment................Robert Burns
God help the man who won't help himself, because no-one else will...........My Grandmother

Share this post


Link to post
Share on other sites

Place a password in your script. Then you can make it ask for a password, if correct answer given continue else exit.

I really like this forum, people really are helping, thanks everyone.

And Thanks BigDod. A simple and good idea.

But a password in the .exe file would be static unless I change it manually and then compile a new .exe.

Is there a way to use another domainaccount as "password" and if valid, continue and logon using a domainadmin account, else Exit? Then I can place every IT-technician at the IT-department in a group without domainadmin rights and have the script to check if the account is in that group. Otherwise Exit.

Thanks in advance.

Twinnis

Share this post


Link to post
Share on other sites

Do you think autoit has the ability to create base 64 encryption? cuz if so u would just be able to have someone be able to create a password it could save it to some .txt on the comp but encrypt the passwords with some simple encryption so it would be able to decrypt and re encrypt and stuff

Share this post


Link to post
Share on other sites

I really like this forum, people really are helping, thanks everyone.

And Thanks BigDod. A simple and good idea.

But a password in the .exe file would be static unless I change it manually and then compile a new .exe.

Is there a way to use another domainaccount as "password" and if valid, continue and logon using a domainadmin account, else Exit? Then I can place every IT-technician at the IT-department in a group without domainadmin rights and have the script to check if the account is in that group. Otherwise Exit.

Thanks in advance.

Twinnis

How about just checking for admin rights. The Domain Admins group is in the local Administrators group, so this will work for local or domain admins:

If Not IsAdmin() Then
     Exit
EndIf

You should also have locked down acces to the executable in the first place. Even if EVERYONE group gets the shortcut, you still control who can read the target file.


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

How about just checking for admin rights. The Domain Admins group is in the local Administrators group, so this will work for local or domain admins:

If Not IsAdmin() Then
     Exit
EndIf

You should also have locked down acces to the executable in the first place. Even if EVERYONE group gets the shortcut, you still control who can read the target file.

Hi.

Thanks for your answer.

But if I would like to use a domain global group that does not have local admin rights? The first thing I want to do is to check if this person have the right to run the script, and IF, continue and logon using a other account with domainadmin rights. So there is two things I want to check before you are allowed to logon as domainadmin.

1. Is this the right .exe.

2. Are you member of a group that are allowed to logon as a domainadmin.

Is it possible to use any group?

Best regards

Twinnis

Share this post


Link to post
Share on other sites

Have you looked at InetGet() to determine either or? (using the a .txt file or something)

After you create the users permissions as an example, make a text file using their 'Username'.txt, then within it set what permissions they are allowed.

Have your program download upon startup or upon specific action the txt file, and read the permissions you set for that individual.

Example:

;Need Beta for StringRegExpReplace

$Username = InputBox('Email Address', 'Enter your email address below', '', '', 100, 80)

$UserFileName = StringRegExpReplace($Username, "[@.]", "_") & '.ini'

InetGet('http://www.yoururl.com/yourfoldertospecify/' & $UserFileName, @TempDir & '\whatevernameyouwanttonameit.ini', 1, 1)

If IniRead(@TempDir & '\whatevernameyouwanttonameit.ini', 'SectionToLookFor', 'Permissions', '') = 'AdminRights' Then 
;Do whatever
Else
    MsgBox(0, 'Error', 'You are not permitted to do these actions' & @CRLF & 'Please consult us at:')
EndIf

This is just an idea... hope it helps.


[center]Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.[/center]

Share this post


Link to post
Share on other sites

Hi.

Thanks for your answer.

But if I would like to use a domain global group that does not have local admin rights? The first thing I want to do is to check if this person have the right to run the script, and IF, continue and logon using a other account with domainadmin rights. So there is two things I want to check before you are allowed to logon as domainadmin.

1. Is this the right .exe.

2. Are you member of a group that are allowed to logon as a domainadmin.

Is it possible to use any group?

Best regards

Twinnis

You seem to be looking for two things:

1. Verification that this is the "right" .exe

2. A unix-like sudo function to allow a non-admin to perform an admin task.

On the first one:

What is the criteria for the "right" .exe? You could take an MD5 hash of the exe and check it before executing it. A tool like MD5 can be called, or the equivelent CYGWIN tool. The internal MD5 hash stored in the script would be compared with the MD5 hash of the .exe before running it. Is that the kind of thing you meant?

On the second point:

Does the user have rights to run the exe or not? If not, are you looking to save a domain admin password within a script? That strikes me as a really bad idea, even if you use AutoIT obsfucation for the compiled .exe. I am confused by "member of a group allowed to logon as a domainadmin", yet not a domain admin. Can you describe the scenario with specific sample usernames and groupnames?


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

You seem to be looking for two things:

1. Verification that this is the "right" .exe

2. A unix-like sudo function to allow a non-admin to perform an admin task.

On the first one:

What is the criteria for the "right" .exe? You could take an MD5 hash of the exe and check it before executing it. A tool like MD5 can be called, or the equivelent CYGWIN tool. The internal MD5 hash stored in the script would be compared with the MD5 hash of the .exe before running it. Is that the kind of thing you meant?

On the second point:

Does the user have rights to run the exe or not? If not, are you looking to save a domain admin password within a script? That strikes me as a really bad idea, even if you use AutoIT obsfucation for the compiled .exe. I am confused by "member of a group allowed to logon as a domainadmin", yet not a domain admin. Can you describe the scenario with specific sample usernames and groupnames?

I can see that my description is confusing, not to mention my english ;).

Well, I will try to explain more detailed.

What I want to do is raise security and at the same time improve IT-technicians way to work.

Actually this is a couple of separate ideas I am trying to merge into one.

Lets go trough the basic securitypart first. At the IT-department we are 20 technicians working with almost 1400 windows XP PC:s in four NT 4 domains. As ussual we all belong to the domainadmin group with their regular account, but thats not a good idea as everone knows. If I logon with domain admin rights to check my e-mail, surf the internet or forgetting to lock PC when you leave the office for coffe is not ideal. So I want every technician to have two accounts, one regular(ex. Daveregular) with no adminrights to use for e-mail and internet, and a second with adminrights(ex. DavedomainAdmin). Two groups, ex. TechniciansRegular and TechniciansDomainAdmin. Then I put Daveregular in TechnicianRegular and DaveDomainAdmin in TechnicianDomain. But as everyone knows technicians are lazy :lol:. So make sure that Dave dont use his domainadmin account for regular use I have to give them something better. Even though runas in windows is pretty simple way to raise your rights its irritating to to logon for every program you want to use. Then I read about howe to start a new shell(explorer.exe) with adminrights then everything you start is with adminrights. And thats nicer. And the best part is that you dont have to logof the regular user so when you kill the explorer process it restart the regular users shell and every program is still running with regular users credentialls.

I try to make an example.

Bertha at the economy department have a problem with her local printer when she tries to print from Payroll software. Dave come to help her. Lets say that Dave have to change the printerdriver. Instead of logoff Bertha and logon as DaveDomainadmin he execute my script. It deletes Berthas explorer but leaves Payroll still running under her credentials. The script starts another explorer using RunAsSet and windows secondary logon and Dave logon with DaveDomainAdmin.He can change the driver and then delete his own explorer. The script now starts a new shell with Berthas credentialls. He can test if printing works with Payroll in Berthas shell with her credentialls without having her to logon again since she has not logged off. The gain is that Dave dont have to ask for Berthas password if she have to leave or wait for her to come back because she went to have a smoke.

The script works really nice so far, but I want to raise security for my script and thats why asked for help in the first place.

Phew, a lot of text o:)

At the moment I distribute a shortcut within the logonscript that point to the share with the compiled script.

When I execute the script from a customers PC I want to be REALLY sure that it is my script and not someone elses lookalike with a keylogger. BigDod gave me a tip about using a password within the script. If the password is incorrect the script exits. Nice and easy, perhaps thats the way to take.

But I am wondering if there is another way or perhaps combined with another idea. If I use two logon in the script and one password file. The first logon is to check if the person trying to logon is a member of the group TechnicianRegular and the second a TechnicianDomainadmin. If the person trying to start the script is member of the group TechnicianRegular it send the password back to the script and if it match the script starts the second logon that start a shell with domainadminrights. If this is possible I get an event in the DC:s eventlogg that says "Dave" is logged on at PC XXXX. Right after that an event that says domainadmin logon on that PC XXXX. Then I can have only one domainadmin but still get a trace of who logged on using the domainadmin account.

Am I deranged :lmao: or is this possible or even necessary. Perhaps BigDods tip of using a password directly in the script is enough?

Thanks to everyone :king:

Twinnis

Edited by twinnis

Share this post


Link to post
Share on other sites

Well, I've notice others on this board disagree with me, but I don't think it is sane to code a password into a script, period. And the more elevated the privileges of the account, the more insane that is. So a hard-coded domain admin password is simply suicidal. But I also don't think it's sane to be still running an NT4 domain! Eek! o:)

In your example, I would expect killing the user's shell would kill the app they were running in that shell anyway, so it won't be there to go back to. That being the case, I would rather my admins gather symptoms from the user's session, then log the user off and logon as an admin if required to fix it.

As for verifying the integrity of a script, if you only access it as an admin, it can be locked down in a share only reachable by admins. MD5 hashes can make sure it hasn't been changed, but the file you keep the hash in has to be more secure than the one you are hashing... ;)

You are correct that the admins should not do ordinary user tasks with their admin accounts, but if you can't trust them to do that... they shouldn't be admins... :lmao:


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

Here is a little script I use to run cmd.exe as admin. The script does not hold any password, therefore it does not matter if it is decompiled

$psw = InputBox ("Command Prompt as Admin", "Enter the Administrator password","","*")
RunAsSet("Administrator", "Domain", $psw)
run("cmd.exe", @systemdir)

Hope it helps


CheersNobby

Share this post


Link to post
Share on other sites

#12 ·  Posted (edited)

Hi everyone.

Thanks for your effort in trying to help me :D

It seems that I have problems to explain what I want to do and have done :lol:

But I will try to explain a few things anyway.

Well, I've notice others on this board disagree with me, but I don't think it is sane to code a password into a script, period. And the more elevated the privileges of the account, the more insane that is. So a hard-coded domain admin password is simply suicidal. But I also don't think it's sane to be still running an NT4 domain! Eek! o:) .

I never wanted to hardcode an adminpassword into the script. The password was an idea to check that the script was the RIGHT script and nothing else. If I gave the wrong password when executing the script it would just end and not give you the opportunity to logon as admin. Not trough the script using Windows secondary logon service anyway. And I agree, NT 4 IS insane, or not, it depends on how you look at it :).

In your example, I would expect killing the user's shell would kill the app they were running in that shell anyway, so it won't be there to go back to. That being the case, I would rather my admins gather symptoms from the user's session, then log the user off and logon as an admin if required to fix it.

Killing the users shell(explorer.exe) does not kill their programs not on W2K and XP anyway. To test do as follows. Start a notepad and write something. Use taskmanager to kill the explorer. Start a new task and write <runas /user:administrator explorer.exe>. You will be prompted for your password. Now you have a new shell with admin credentialls. And the notepad will still be running as user with the text you wrote. Kill the explorer again. Start a new task but write only explorer and you will be back to users shell. Importent not to shut the taskmanager down during the process. Try it :king: Its a nice feature, or not, it depends on how you look at it ;).

As for verifying the integrity of a script, if you only access it as an admin, it can be locked down in a share only reachable by admins. MD5 hashes can make sure it hasn't been changed, but the file you keep the hash in has to be more secure than the one you are hashing... ;) .

You are correct that the admins should not do ordinary user tasks with their admin accounts, but if you can't trust them to do that... they shouldn't be admins... :lmao:

Edited by twinnis

Share this post


Link to post
Share on other sites

Then I read about howe to start a new shell(explorer.exe) with adminrights then everything you start is with adminrights. And thats nicer. And the best part is that you dont have to logof the regular user so when you kill the explorer process it restart the regular users shell and every program is still running with regular users credentialls.

I would seriously advise against closing the shell and running a new instance of it as admin for all of your techs. In our environment it is insecure and is prone to error. what happens when you close the user's explorer then open your admin explorer and run a script that has processclose('winword.exe') for example?

I, personally, use the admin shell replace method only when the user explicitly asks not be to logged off (usually because they are on a production PC or running some long SAS application) and a admin task of the utmost importance is needed to be done on that PC.

Mostly I write remote automation scripts using PSEXEC for patching, and I write runas scripts (which are encrypted) to send to the users. Not only is does the EXe not allow decompilation, I use an encrypted password and I use Encrypt it to encrypt the whole script.

If you want to automate a runas session, just do as nobby has posted.


---"Educate the Mind, Make Savage the Body" -Mao Tse Tung

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0