Solved

How secure are Logon Script parameters passed to a script in Active Directory?

Posted on 2010-08-30
5
1,202 Views
Last Modified: 2012-06-27
Hi all, I'm hoping someone with some intricate knowledge of Activity Directory could provide some advice.  My knowledge of it doesn't really extend to the security side of things.  I write VBScripts quite regularly to perform tasks at Logon.  Sometimes I have certain passwords in the script, for database connections, or limited install privileges, etc.  I have used the Microsoft Script Encoder to obfuscate these in the past, but I know that the obfuscated code can be reversed relatively easily by anyone determined enough.  I have also used tools to convert the VBS to an EXE, which seems to be the best current solution for me.  When I trace the EXE with process explorer, I cannot see any hint of the raw VBS, so I'm happy with that (although I don't know for certain this EXE cannot be decompiled by anything).

My question is, if in my script I were to use
strPassword = WScript.Arguments.Item(0)

to obtain the password from the Parameters section of a Logon Script assigned by Group Policy, it is secure enough that it can't be "sniffed out" very easily?  I understand that it would be passed in plain text, but the password is not directly exposed to any user.

Any advice would be appreciated.

Thanks,

Rob.
0
Comment
Question by:RobSampson
  • 3
5 Comments
 
LVL 8

Accepted Solution

by:
sstone55423 earned 250 total points
ID: 33563924
It seems to me that the password is not embedded in the VBscript or EXE file, but is placed in strPassword during run time (at login).  As such it is exposed only within memory within the server/DC that it is running on when the process is running.
For someone to see the "cleartext" password, they would have to be examining memory of a system process while it is running.  Since memory for a process is protected, the other process examining memory would need to have administrative rights to other memory.
I view this as a minimal security risk.
Consider that if you had the password stored in encryped form, then it would be exposed equally during the process of decryption and passing the parameter to the database connection string.  The only way that this can be avoided is for the database itself to  authenticate using kerberos, or some other method where the encrypted password is never decrypted in memory.
0
 
LVL 65

Author Comment

by:RobSampson
ID: 33564148
Right....that makes sense....thanks for the clarification....

The password definately wouldn't (or certainly shouldn't) be embedded into the script, because it is accepting it as a parameter.  Given that one might somehow have access to write to the script, they could simply use
WScript.Echo strPassword
to obtain it, but that's easily overcome by locking down NTFS restrictions (which is default in the NetLogon share anyway).

Just one more question along the lines of what you have mentioned...

Seeing as the process for the script itself (when executed) would be running in the context of the user logging on, would they be able to read that memory space? Or is this still locked down to SYSTEM rights?

Thanks for your input,

Rob.
0
 
LVL 7

Assisted Solution

by:firemanf29
firemanf29 earned 250 total points
ID: 33564181
First,  make sure the VBSTOEXE converter you're using does not write the script to the temp or another directory on execution.  Most of them do.  Assuming a hacker grabs the file from the temp directory and decodes it.  Then determines that the script is being passed a password during execution.  Then finds the GP that's executing the script.  Assuming all that they should be able to read the password from the GP object.  Chances are very slim that it would happen but their is a small chance.  If it's running as the user then they would be able to read that memory space.
0
 
LVL 65

Author Comment

by:RobSampson
ID: 33564338
Yeah, I did start with one tool that simply appeared to wrap the VBS in some compiled code, and on execution, would dump the VBS to a temp folder, and run it....obviously no good.  The tool I am now using though, does not show any trace of the script engine or a vbs file through ProcMon and Process Explorer, so I'm happy with that.

@firemanf29, >> Assuming all that they should be able to read the password from the GP object.

How is that possible?  The \\domain.com\sysvol\domain.com\Policies folder is locked down, as is the HKLM policies tree....

Overall though, the comments you guys have posted give me a fair assurance that this is a safe way to go.  The alternatives certianly don't seem to stack up to that:
  - The CPAU encoding seems to be the next best option I can find, by encoding a batch job, which I could run
  - PSExec offers no security via encryption
  - I could use MS Encryption, but the decryption requires a "secret" word, which when placed in a VBS file as plain text is hardly "secret"

It also seems a far more simple, and far more centralised way to pass such a parameter....and I'm not too worried about the ability of anyone to run a memory "sniffer".

I'll leave this open for a day or two just in case we can pull more heads together.

Thanks guys, appreciate it.

Regards,

Rob.
0
 
LVL 65

Author Closing Comment

by:RobSampson
ID: 33582927
 Thanks guys for your clarification.
0

Join & Write a Comment

Do you have users whose passwords are expiring and they are constantly calling you?  Well I sure did and needed a way to put an end to this.  We have a lot of remote users which would not be notified that their passwords were expiring since they wer…
Is your Office 365 signature not working the way you want it to? Are signature updates taking up too much of your time? Let's run through the most common problems that an IT administrator can encounter when dealing with Office 365 email signatures.
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

23 Experts available now in Live!

Get 1:1 Help Now