Script Wars: The Farce Awakens (part V)

Doctor Scripto

Summary: Rey is skilled in PowerShell, and new to Contoso Holly Jolly Hat Company. Already she has been a great boon to her new co-workers and had her sneakers become the subject of a hungry trash robot.

She was just about to walk out to the hall with Ben Kerberosie, when suddenly an dominant figure has blocked them, with the following words booming through the hall:

“WHO DO I SPEAK TO ABOUT CLEAR TEXT PASSWORDS in POWERSHELL!?!”

———————-

That entity was none other than Katherine Phantampa! Head of IT Security, and also known as The Gatekeeper. The Protector of Data. The Guardian of all that was physical and logical.

It was said, if there were any questions regarding security, she would respond with “There is only Zuul.”

Many rumors about her were discussed amongst employees at Contoso:

  • The day a third of the call center desktops were shipped out to head office because of screens left unlocked during lunch hour!
  • The rumors of nightly inspections for Sticky notes on keyboards and monitors!
  • The echoing story of the day an IT administrator left the data center door jammed open with a chair, and walked away to the water fountain for a sip. They say the conversation that day shocked IT so much, they all now wear portable water coolers….

To say Katherine was a force to be reckoned with was an understatement. She wasn’t a mean person, and quite often was the first one to buy donuts on Fridays, or offer a cheery “Hello!” It was just that she was incredibly serious about ensuring the environment was secure to protect customer data.

People feared and respected her. So when you heard that voice booming, something was up. And did we mention this was “Day 1” for Rey?

Ben fortunately took the lead, understanding that if Katherine was angry, it was a large concern.

“Where is this happening? We’ve got a newly hired PowerShell expert with us. I’m certain she can help mitigate the issues. Clear text passwords are not an option. I completely agree, let’s sort this out.”

Seeing Ben immediately want to work put Katherine at ease. “Okay, well, it’s not all the scripts, but in particular it’s the ones that are managing Office 365 and Azure that are a concern to me. I’ve seen some lines like this being used to build the credentials to automate the solutions.”

$SecurePassword=ConvertTo-SecureString ‘Office365AdminP@ssw0rdSekre!’ -asplaintext -force

$Credential=New-Object System.Management.Automation.PsCredential (‘o365admin@contosohats.onmicrosoft.com’,$SecurePassword)

“Well that is troubling,” noted Ben. “Rey, what do you make of this?”

Rey looked at the code. The process was sound, but Katherine was correct. If for any reason this script was compromised, global admin credentials to their Office 365 infrastructure would be in the wild. She knew this was a large risk for the company.

She thought for a moment. “There a few options. One I might suggest that isn’t too difficult to implement and still gives staff the ability to leverage a solution like this is to store the password in a f….”

You could almost see the lasers burning from Katherine. “A clear text password in a file?!?!”

Rey understood. Her wording was incorrect. “Sorry, I meant we can prompt for the password and store it in a SecureString format. The file is only good for the machine it was created on, so if compromised it can’t be read anywhere else.”

Rey wrote some PowerShell code to produce such a file:

$Credential=Get-Credential

$Password=$Credential.GetNetworkCredential().password

$SecureString=ConvertTo-SecureString $Password -asplaintext -force

$EncryptedStringASCII=ConvertFrom-SecureString $SecureString

Out-File -FilePath credpasssecure.txt -inputobject $EncryptedStringASCII

“This won’t eliminate the threat, but it will limit the password access to only the machine it’s created on. So if I got this file, I can’t put the password back together on my laptop. To move this into production with their existing script, they would do this.”

Rey provided some sample code in Windows PowerShell.

$EncryptedStringASCII=Get-Content credpasssecure.txt

$SecurePassword=ConvertFrom-SecureString $EncryptedStringASCII

$Credential=New-Object System.Management.Automation.PsCredential (‘o365admin@contosohat.onmicrosoft.com’,$SecurePassword)

Katherine seemed a bit more at ease. “Okay, so it’s not blatantly obvious in the code now. I still don’t like that there is a file on the machine with this information. The risk is lower, but I’d prefer something a bit more robust.”

Rey thought for a moment. “Since we’re talking Office 365 and Azure AD credentials, we could look into using Azure Automation. It is designed ideally for this scenario.”

Ben looked over. “Azure Automation? What’s that?”

“To really simplify it, it’s a giant task scheduler in Azure that can work against all components of Azure, including Office 365. But more correctly it’s an Orchestrator with Role-Based Access Control, to limit who can and cannot use or access certain features. Being that it’s in the Azure datacenters, internet outages also don’t affect how those scheduled processes communicate to Office 365.”

Katherine brightened up. “So our credentials for scheduled PowerShell scripts would occur directly within the Azure datacenter? Very nice! But how does this mitigate the clear password nightmare?”

Rey smiled. “Within Azure Automation, you can store information as secure assets, accessed by special cmdlets in the scripts. The password and user ID is manually entered, and then only the cmdlet can access the data. The other advantage to this solution is that when passwords need to be updated, the asset is updated and the scripts are targeting the asset.”

“No need to rewrite and update scripts because of passwords!” burst out Ben.

Rey connected to her trial copy of Azure to show how the credentials are stored in Azure Automation.

“Once an automation account is created and an initial Runbook set up, you can select credentials to add a credential securely. As you can see, the password is obscured even at entry….”

Screenshot of automation account

“When you are editing a Runbook, which is what holds the PowerShell script, you just choose the credential and select Add to canvas.”

Screenshot of runbook options

“As you can see, we just need to add a variable to hold the credential. The script will function as before, without exposing the credentials to anybody who should not have them.”

Screenshot of credential code

Katherine was very impressed. “I can see why we hired her! Okay, so for the short term we’ll look at a combination of interactive logins and some limited use of SecureString text files. I’ll also set up a business case on getting Azure Automation into trial to test out its use in our environment. Thank you, Rey!”

And so the battle was over. Good common sense and script design, as well as some secure approaches to credential use, saved the day.

We thank you all for checking out this year’s “Hey, Scripting Guy!” holiday special. We hope it was both entertaining and informative for you.

From all of us to all of you, happy holidays!

Sean Kearney, Premier Field Engineer

Enterprise Services Delivery, Secure Infrastructure

0 comments

Discussion is closed.

Feedback usabilla icon