Windows PowerShell cmdlets to secure PSCredential Objects

I have previously discussed securing credentials using Windows Powershell atPowershell: Securing credentials using the PSCredential class. In this article, I will discuss a number of cmdlets I have created to secure credentials using a Advanced Encryption Standard (AES) encryption key to retrieve the content from a encrypted standard string.

As I am using an encryption key and storing the information in a content file, I will be using ACLs on the NTFS filesytem to control access. Alternative methods could be to store the encryption key in a database or use a certificate to control access to the item. Also, in practice I will store the encryption key on a remote file server.

Firstly, we need to create the encryption key using the ‘New-EncryptionKey’ cmdlet to which we use the RNGCryptoServiceProvider class to generate a random byte array for the encryption length. By default, the cmdlet using a 32-byte array to support the AES 256-bit encryption length. The cmdlet also supports using 128-bit and 192-bit encryption lengths which a 16-byte and 24-byte array. The random byte array for the specified encryption length is generated and sends the output to a file which will be the encryption key content.

Once the content has sent to the output file, the content of random byte array is then removed from the current session.

# Creates an AES 256-bit encryption key at the location D:\Output\Keys\mykey.key
New-EncryptionKey -Output D:\Output\Keys\mykey.key 

# Creates an AES 192-bit encryption key at the location D:\Output\Keys\mykey.key
New-EncryptionKey -Bytes 24 -Output D:\Output\Keys\mykey.key

We have now created an encryption key so that we may now convert the secure string for a credential object password using the specified encryption key and sends the output to a password file using the ‘New-EncryptedString’ cmdlet. The cmdlet will retrieve the content of the specified file containing the encryption key and from the stored credential objects convert the secure string of the password to an encrypted standard string and send the output to a file and clear the content of the stored encryption key from the current session.

New-EncryptedString -KeyFile D:\Output\Keys\mykey.key -PasswordFile D:\Output\Passwords\mypassword.txt 

Finally we want to retrieve the credential object to use as a variable to pass to a subsequent cmdlet which will require authentication. The content of the password file is retrieved and converted to a secure string using the content of the encryption key and stored as a password variable and passed to the PSCredential class to represent a set of security credentials and return the object. For subsequent cmdlets I can use the ‘$Password.GetNetworkCredential().Password’ property value for authentication from the PSCredential object.

$Password = Get-PSCredentialObject -Username administrator -KeyFile D:\Output\Keys\mykey.key -PasswordFile D:\Output\Passwords\mypassword.txt 

The cmdlets are available from the below:

New-EncryptionKey –
New-EncryptedString –
Get-PSCredentialObject –

Identifying applications vulnerable to the Sparkle MiTM attacks

As recently disclosed ( you may be already be aware of a vulnerability in Sparkle that exposes a large number of applications to man-in-the-middle (MiTM) attacks over insecure HTTP channels.

In order to identify Applications that are susceptible to MiTM attacks that install malicious code in the Sparkle software framework invoke the below from a terminal window. From the output we are looking for applications to which the version string is prior to 1.13.1 to which these will be vulnerable if set to load over HTTP.

find /Applications -path '*' -exec echo {} \; -exec grep -A1 CFBundleShortVersionString '{}' \; | grep -v CFBundleShortVersionString

The applications ‘Info.plist’ file will have a ‘SUFeedURL’ key which can identify any assets that are being loaded over unsecured HTTP. Alternatively, you can attempt to update the application and perform a packet capture using a utility such as Wireshark to determine if the HTTP protocol is being used.

A list of applications that are dependent on Sparkle can be found here, but not all of these may be communicating over insecure HTTP.

Generating certificate requests with additional subject identities using OpenSSL

The below provides steps to how the process used to create a certificate request to issue to certificate authority server in an internal environment. However, the steps to create the certificate request can be performed if submitting a certificate request to a third party certificate authority.

Firstly, I will create a configuration file (openssl.cnf) to be used generating the certificate request. The certificate request will be created specifying a default key size of 2048 bits, and sha256 digest algorithm. In this example, I will be submitting a certificate request for the server ‘server1.domain.local’ with the additional subject identities ‘server1,’’, ‘server1.domain.local’ and ‘www.dean.local’.

[ req ]
default_bits = 2048
​default_md = sha256
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:server1, IP:, DNS:server1.dean.local, DNS: www.dean.local

[ req_distinguished_name ]
countryName = GB
stateOrProvinceName = Midlothian
localityName = Edinburgh
0.organizationName = Dean Grant
organizationalUnitName = Servers
commonName = server1.dean.local ​

We will now create the certificate request to send to the certificate authority, to which the original public key generated in the certificate request will be converted to be in RSA format and remove the original file. Once the certificate request has been generated place the in a location which may be accessible for the submission to the certificate authority server.

cd /tmp
openssl req -new -nodes -out server1.dean.local.csr -keyout orig-server1.dean.local.key -config openssl.cnf
openssl rsa -in orig-server1.dean.local.key -out server1.dean.local.key
rm -f orig-server1.dean.local

In this example I am submitting my certificate request to a certificate authority running Active Directory Certificate Services on Windows Server 2012. The certificate request is submitted specifying the ‘WebServer’ certificate template and the certificate request file created previously. If prompted select the certificate authority which will now create certificate file (server1.dean.local.crt) and the certficate chain file (server1.dean.local.pfx).

cd %temp%
certreq -attrib "CertificateTemplate:WebServer" -submit server1.dean.local.csr server1.dean.local.crt server1.dean.local.pfx

The certificate files may now be placed on the server to which you configure encryption, depending on the certificate file requirements you should have the following files available.

server1.dean.local.crt # certificate file
server1.dean.local.pfx # certificate chain file in personal exchange file (.pfx) format.
server1.dean.local.key # private key file

Installing Guest Additions for a Kali Linux guest in VirtualBox

In order to install the guest additions within a Kali Linux guest using Oracle VM VirtualBox to optimise the guest operating system for better performance and usability, there is a requirement to install the kernel header files.

In order to perform the above we can invoke the following from the terminal:

apt-get update 
apt-get install -y linux-headers-$(uname -r) 

Now we can attach the Guest Additions ISO to the guest virtual machine and begin the install:

cp /media/cd-rom/ /tmp/
chmod 755 /tmp/
cd /tmp

Once complete, reboot the virtual machine to complete the installation. On startup, the virtual machine will now have full mouse and screen integration as well as the ability to share folders with the host system in addition to other device drivers and system applications that have now been installed.

Updating repository lists and keyrings for Kali Linux on Amazon Web Services

I was recently launching an instance of Kali Linux (1.0.6 | 64-bit Amazon Machine Image (AMI) | Updated: 10/10/14) in Amazon Web Services and as the image only provides the Kali package repository (as per the description”bare-bones”) I was looking to install the complete system (apt-get install kali-linux-full) from the available packages.

However, on invoking the installation of the package from the repository I was presented with several response codes stating the repository list(s) could not be found and GPG invalid signatures.

In order to resolve the issue I replaced my list of current repositories (creating a backup first!) and included the below repository items into a new /etc/apt/sources.list file, installed all the necessary keyrings and updated the repository list.

cp /etc/apt/sources.list /etc/apt/sources.list.backup
echo "deb sana main non-free contrib" >> /etc/apt/sources.list
echo "deb sana/updates main contrib non-free" >> /etc/apt/sources.list
apt-get install kali-archive-keyring
apt-get update
apt-get install kali-linux-full

Now I was able to install the complete system for Kali Linux, so sit back and have a coffee this process may take a while!

Powershell: Securing credentials using the PSCredential class

This a pretty old one but a script block at times I revert back to in particular when there is a requirement to specify user credentials in order to complete a task.

When requiring to store credentials in a script block, these should not be entered in plain text from a security perspective and can can easily be secured by storing the password in an encrypted file and retrieving the credentials using the PSCredential class (System.Management.Automation.PSCredential).

As the file can only be decrypted by the user account to which the password was converted to a secure string, you will need to invoke the powershell session as this user. For example, to retrieve the encrypted credentials as a service account you will need to invoke powershell as the alternative user.

By specifying the ‘Get-Credential’ cmdlet we can enter the user credentials we require to be encrypted, pass these to the ‘ConvertFrom-SecureString’ cmdlet and finally save to a text file the encrypted string.

$Credentials = Get-Credential
$Credentials.Password | ConvertFrom-SecureString | Set-Content D:\Secure\password.txt

Now, it is time to compile the script block to retrieve the encrypted content and convert the encrypted string to a secure string using the ‘ConvertTo-SecureString’ cmdlet.

$Password = Get-Content "D:\Secure\password.txt" | ConvertTo-SecureString

Now we will specify the username for the credentials

$Username = "user1@domain.local"

Now we can invoke the PSCredential class to retrieve the previously encrypted string and going forward use the ‘$Username’ and ‘$Password’ variables in the powershell session for authentication.

$Credentials = New-Object System.Management.Automation.PSCredential $Username,$Password
$Password = $Credentials.GetNetworkCredential().Password

Disabling the Telnet protocol on Brocade SAN switches

By default Brocade SAN switches have the Telnet protocol enabled, you may wish to disable this as part of security hardening of your devices to mitigate to the session being transmitted in clear text and enforce SSH connectivity as the management protocol.

In order to disable the Telnet protocol you will be required to modify the IP filter policy to disable inbound connectivity to the TCP service port, which can be performed using the Fabric OS CLI.

As the default IP filter policy cannot be modified,  in order to modify the rules an IP filter policy is required to be created by cloning the default policy.

ipfilter –-clone deny_telnet_ipv4 -from default_ipv4 
ipfilter –-clone deny_telnet_ipv6 -from default_ipv6

Once we have cloned the default policies we will be required to remove the existing rule to permit connectivity on TCP service port 23. By invoking the command ‘ipfilter –show’, we can determine the current rule number which permits the connectivity.

ipfilter --delrule deny_telnet_ipv4 -rule 2
ipfilter --delrule deny_telnet_ipv6 -rule 2

Now we will add the rule to deny inbound connectivity to the fabric switch on TCP service port 23.

ipfilter –-addrule deny_telnet_ipv4 -rule 2 -sip any -dp 23 -proto tcp -act deny
ipfilter –-addrule deny_telnet_ipv6 -rule 2 -sip any -dp 23 -proto tcp -act deny

Now that we have created the rule we will first save the IP filter policy and then apply to the fabric switch

ipfilter –-save deny_telnet_ipv4 
ipfilter –-save deny_telnet_ipv6
ipfilter –-activate deny_telnet_ipv4 
ipfilter –-activate deny_telnet_ipv6