This project is read-only.

does this sound possible

Sep 2, 2008 at 11:48 PM
need to monitor a non domain joined https site.  I was thinking that I could use powershells get-credential save to file trick.  The get-credential would be the the credentials of a given limited permission user on the https web site.  The save file can only be decrypted by the user that created it.  So in that case I can run powershell as "system" create the text file.  Then hopefully my powershell script that runs as system will be able to read/decrypt the encrypted text file then access the remote https site.  Does that seem reasonable?
Sep 3, 2008 at 12:10 AM
Possibly, I haven't tried running PowerShell as the Local System account (or Network Service account).  Or you could use a specified encryption key to encrypt the file you are writing to disk and use that to read the password.  It really depends on where your security concerns are with that machine.
Sep 5, 2008 at 9:53 PM
Edited Sep 8, 2008 at 5:19 PM
ok this is cool and scary at the same time I have polymon running as system!  please note this was not my original request!
ran powershell  as system via the at command 
AT sometime /interactive "path\ps.exe"
$Credential = Get-Credential
$credential.Password | ConvertFrom-SecureString | Set-Content c:\drv\pw.txt
this stores an encrypted hash within the pw.txt file, yes there are some wierd security issues here! 

then within polymon I have a powershell monitor doing the following (sanitized for security sake)
$credential.Password | ConvertFrom-SecureString | Set-Content c:\drv\pw.txt
$password = Get-Content c:\drv\pw.txt | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential("remotedomain\username",$password)
if (
(gwmi win32_logicaldisk -computer -cred  $credential -filter "deviceid='c:' and freespace<'100000000000'").freespace
$Counters.Add("Counter 1", (gwmi win32_logicaldisk -computer -cred  $credential -filter "deviceid='c:' and freespace<'100000000000'").freespace)

the damn thing worked!

Sep 10, 2008 at 10:27 PM
I've created a domain account with no particular rights. I have the PolyMon Executive service running with this account. Then on any servers it needs to monitor I give it local access to do what it needs. Maybe just read only access to an empty share to check drive space or administrative access to monitor services and WMI. (I've tried to grant specific WMI rights and haven't had success, yet.)
Sep 11, 2008 at 4:41 PM
that works if your in the same domain and or trusted domain!  If you have the ability to create accounts on the remote device then things change also!
Sep 12, 2008 at 9:02 PM
I don't see what you gain (security-wise) using that long convoluted script, but running PS (or anything) as SYSTEM can open quite a big can of worms.

Using SYSTEM really makes me nervous for you.

The better way to architect what you need to do to have the most reduced attack surface (in my opinion), is to first create an isolated domain account for PolyMon only.  Then create a remote PolyMon "job" account (local or domain -- doesn't matter) at the remote server that is also limited in access only to the scope of the tests it will perform

Store the password in plain text in the script and rely on ACLs to protect it.  If the remote account is properly secured, the only thing the attacker can gain from knowing that password is the information that is being gathered for polymon -- not a big deal.

You can obfiscate the password using any number of encryption techniques if you feel it is necessary, but it doesn't buy you a whole lot except maybe some time while a potential hacker is looking for how to decode the password.  On second thought, maybe it would be good to obfiscate it because it would distract the attacker from a more vulnerable target thinking this account was actually more useful than it is.  But I digress...

The way you are currently doing it is not hashed, or else you wouldn't be able to pull the password back out of the file (hashing is one way).  It's probably just encoded using some binary encoding -- I doubt it's even encrypted, but I've never used the SecureString class that way before, so I'm not sure.  Either way it's a single line of PS to get the actual password back, so it's offering no protection of the password right now (same as plain text), so it's really just extra work with no gain.
Sep 12, 2008 at 10:13 PM
Please read up on  "Get-Credential $credential.Password | ConvertFrom-SecureString" commands so that you understand what its doing!  

in reallity this was a test, the real monitor is monitoring a linux based https site which I have no access to other then a monitoring account and the above techniques work fine for this!
Dec 2, 2008 at 11:04 PM
just to clarify the issue the password thats written out to the file in this line

$credential.Password | ConvertFrom-SecureString | Set-Content c:\drv\pw.txt
is encrypted

so if you login as domainuser\a and run ps then run the above command only domainuser\a can decrypt the file.  There is one method to get around this;  if your not the user,  but in this case you have to be a domain admin or have delegated perms to pw changes on the object domainuser\a.  So domainuser\a need to be a special class of user if your in a secure environment!