Automated certificate key recovery

Hi everyone,

while working in a PKI project we had the requirement to recover all archived private keys from a certification authority. The customer used SMIME mail encryption with two different certificates for signing and encryption.
From a security point of view it is good to user two different certificates for signing and encryption. On the other hand there are applications and devices that can only use a single certificate for signing and encryption. E.g. SAP C4C or any Android/iOS mobile device and mail client.
Therefore the customer decided to get rid of two different certificates and enroll a combined certificate to all end users.
Due to the fact that the customer didn't know who in his environment was actually using SMIME encryption and to make the reconfiguration of the users mail client easier, he decided to remove the two certificates from the client and replace (supersed) it with the new combined one.

In addition to that the customer wasn't even sure how many of his users actually make use of SMIME encryption. He expected less than 5 percent. In case a use has received an ecrypted email with his former certificate the customer needs to be able to provide the certificate to the user to be able to read the encrypted mail.

This was not very nice but had to be done in order to achive a supportable and stabel state.

Therefore we had to develope a simple script to recover all existing private keys from the CA and save them in a PFX file using standard key recovery processes and existing KRA certificates. Without the KRA certificate it is not possible to recovery and decrypt the private keys.
Of course the IT Security was involved in the whole process and additional security measures have been taken to protect the PFX files and passwords.

I would like to share the simple script we devolped to automatically recover all private keys from the CA database. This could also be helpfull if you would like to decomission your CA.

As a result you will receive all certificates including the private key enrolled based on the given template. You also receive a CSV file including the requester, serial number, PFX file name and password of each recovered key.

I used a Password generator script from the technet gallery. Thanks to Simon Wahlin.
https://gallery.technet.microsoft.com/scriptcenter/Generate-a-random-and-5c879ed5
I also used the PSPKI Powershell Module from Codeplex. https://pspki.codeplex.com/

Here's the script we used:
#### Variables ####
$TemplateName = "PKIW-User"
$CAName = "PWSUBCA.pkiw.lab\PWSUBCA"
$NetBiosName = "PKIW"
$ExportFolder = "C:\Export\"
#### Required Modules ####
Import-Module pspki
#### Functions ####
#### RandomPassword function from https://gallery.technet.microsoft.com/scriptcenter/Generate-a-random-and-5c879ed5 #####
function New-SWRandomPassword {
    [CmdletBinding(ConfirmImpact='Low')]
    [OutputType([String[]])]
    Param
    (
        # Specifies minimum password length
        [Parameter(Mandatory=$false, 
                   ValueFromPipeline=$false,
                   ValueFromPipelineByPropertyName=$true, 
                   ValueFromRemainingArguments=$false, 
                   Position=0)]
        [ValidateScript({$_ -gt 0})]
        [Alias("Min")] 
        [int]$MinPasswordLength = 10,
        
        # Specifies maximum password length
        [Parameter(Mandatory=$false, 
                   ValueFromPipeline=$false,
                   ValueFromPipelineByPropertyName=$true, 
                   ValueFromRemainingArguments=$false, 
                   Position=1)]
        [ValidateScript({$_ -ge $MinPasswordLength})]
        [Alias("Max")]
        [int]$MaxPasswordLength = 10,
        
        # Specifies an array of strings containing charactergroups from which the password will be generated.
        # At least one char from each group (string) will be used.
        [Parameter(Mandatory=$false, 
                   ValueFromPipeline=$false,
                   ValueFromPipelineByPropertyName=$true, 
                   ValueFromRemainingArguments=$false, 
                   Position=2)]
        [String[]]$InputStrings = @("abcdefghijklmnopqrstuvwxyz", "ABCDEFGHIJKLMNOPQRSTUVWXYZ", "0123456789", '!@#$%&*_-+=\(){}[]:"<>.?/'''),
        
        # Specifies number of passwords to generate.
        [Parameter(Mandatory=$false, 
                   ValueFromPipeline=$false,
                   ValueFromPipelineByPropertyName=$true, 
                   ValueFromRemainingArguments=$false, 
                   Position=3)]
        [ValidateScript({$_ -gt 0})]
        [int]$Count = 1
    )
    Begin {
        Function Get-Seed{
            # Generate a seed for future randomization
            $RandomBytes = New-Object -TypeName "System.Byte[]" 4
            $Random = New-Object -TypeName "System.Security.Cryptography.RNGCryptoServiceProvider"
            $Random.GetBytes($RandomBytes)
            [BitConverter]::ToInt32($RandomBytes, 0)
        }
    }
    Process {
        For($iteration = 1;$iteration -le $Count; $iteration++){
            # Create char arrays containing possible chars
            [char[][]]$CharGroups = $InputStrings

            # Set counter of used groups
            [int[]]$UsedGroups = for($i=0;$i -lt $CharGroups.Count;$i++){0}



            # Create new char-array to hold generated password
            if($MinPasswordLength -eq $MaxPasswordLength) {
                # If password length is set, use set lenth
                $password = New-Object -TypeName "System.Char[]" $MinPasswordLength
            }
            else {
                # Otherwise randomize password length
                $password = New-Object -TypeName "System.Char[]" (Get-Random -SetSeed $(Get-Seed) -Minimum $MinPasswordLength -Maximum $($MaxPasswordLength+1))
            }

            for($i=0;$i -lt $password.Length;$i++){
                if($i -ge ($password.Length - ($UsedGroups | Where-Object {$_ -eq 0}).Count)) {
                    # Check if number of unused groups are equal of less than remaining chars
                    # Select first unused CharGroup
                    $CharGroupIndex = 0
                    while(($UsedGroups[$CharGroupIndex] -ne 0) -and ($CharGroupIndex -lt $CharGroups.Length)) {
                        $CharGroupIndex++
                    }
                }
                else {
                    #Select Random Group
                    $CharGroupIndex = Get-Random -SetSeed $(Get-Seed) -Minimum 0 -Maximum $CharGroups.Length
                }

                # Set current position in password to random char from selected group using a random seed
                $password[$i] = Get-Random -SetSeed $(Get-Seed) -InputObject $CharGroups[$CharGroupIndex]
                # Update count of used groups.
                $UsedGroups[$CharGroupIndex] = $UsedGroups[$CharGroupIndex] + 1
            }
            $password -join ""
        }
    }
}

###### Main ######
"Requester;ValidFrom;ValidTo;SerialNumber;Filename;Password"  | Out-File C:\Install\PFXPassword.csv
$certs = Get-CertificationAuthority pwsubca.pkiw.lab | Get-IssuedRequest -Filter "CertificateTemplate -eq $TemplateName"

Foreach ($Cert in $certs) {
$serial = $cert.SerialNumber
$serialNew = ([regex]::matches($cert.SerialNumber, '.{1,2}') | %{$_.value}) -join ' '
$Requester = $cert.'Request.RequesterName'.Replace("$NetBiosName\","")
$ValidTo = $cert.NotAfter
$ValidFrom = $cert.NotBefore
Certutil -config "$CAName" -getkey $serialNew "$ExportFolder$Requester-$serial.key"
    If (Test-Path "$ExportFolder$Requester-$serial.key") {
        $Password = New-SWRandomPassword
        certutil -p "$Password" -recoverkey -user "$ExportFolder$Requester-$serial.key" "$ExportFolder$Requester-$serial.pfx"
        If (Test-Path "$Requester-$serial.pfx") {
            "$Requester;$ValidFrom;$ValidTo;$serial;$Requester-$serial.pfx;$Password"  | Out-File C:\Install\PFXPassword.csv -Append
        }
        Else {
            "$Requester;$ValidFrom;$ValidTo;$serial;Private key could not be decrypted. PFX file not created.;"  | Out-File C:\Install\PFXPassword.csv -Append
        }
    }
    Else {
        "$Requester;$ValidFrom;$ValidTo;$serial;Certificate private key could not be pulled from the CA database;"  | Out-File C:\Install\PFXPassword.csv -Append
    }
}

I hope this is helpfull for some of you. (At least a hacker maybe will find this helpfull :-))
Best regards
Chris

Why private keys of certificates need to be protected in a mimikatz world

As you might have heared from the news Dell is maybe selling some Windows based machines with a dangerous security flaw that could allow hackers (or after reading this articel, you) to access your computer. The following lines will explain why it is curcial to protect a certificates private key and for those of you who are more interessted in technical details I’ll explain how to export the private key from the machine even though it is marked as not exportable.

A user named „Rotocowboy“ reported on Reddit (https://www.reddit.com/r/technology/comments/3twmfv/dell_ships_laptops_with_rogue_root_ca_exactly/) that recent models of Dells laptops come with a preloaded self-signed digital certificate that could allow criminals to impersonate Dell and incertept traffice from and to your computer.

A certificate named „eDellRoot“ and a certificate „DSDTestProvider“ can be found in the machines „Trusted Root Certification Authority Certification“ store. In the following article I will only focus on the eDellRoot certificate but the same steps can be performed on the DSDTestProvider certificate.

„By default, the Trusted Root Certification Authorities certificate store is configured with a set of public CAs that has met the requirements of the Microsoft Root Certificate Program. Administrators can configure the default set of trusted CAs and install their own private CA for verifying software.
Note: A private CA is unlikely to be trusted outside the network environment.“
https://msdn.microsoft.com/en-us/library/windows/hardware/ff553506(v=vs.85).aspx

In this case the „eDellRoot“ certificate can be considered a private CA but due to the fact that the certificate comes pre-installed on some Dell machines, and without a little help gets automatically reinstalled after deletion, it is more or less trusted by anyone with a Dell machine.

Normaly certificates in the „Trusted Root Certification Authorities“ store are X.509 certificates without a private key. There is no reason to install a private key into this store because only the public key is required to validate a certificate offered/used by e.g. a HTTPS website.

The public key of the certification authority is used to build the so called certificate chain.
„A certificate chain consists of all the certificates needed to certify the subject identified by the end certificate.“
https://msdn.microsoft.com/de-de/library/windows/desktop/aa376515(v=vs.85).aspx

Now that the eDellRoot certificate includes both the private and the public key an attacker can use the private key of the certificate to sign its own certificate which is then automatically trusted by all affected Dell computers.

Let me give you an example:
- I’m the attacker and downloaded the eDellRoot certificate including the private key from the internet.
- Now that I have the certificate I can install by own certification authority using the existing key pair. https://technet.microsoft.com/en-us/library/hh848389(v=wps.630).aspx
- Create certificate for any purpose and any subject name that I like and signe them using my CA. e.g. a certificate for www.gmail.com
- Setup a fake website and install my own www.gmail.com certificate.
- With a little manipulation of the local hosts file or the DNS I redirect every request to www.gmail.com to my website and collect all usernames and passwords in your environment.
Sounds to easy to be true? It is that easy!

The private key of our CA certificate (it doesn’t really matter if it is the private of your CA or any other certificate) in this case is our most valuable property. Therefore we need to protect it as good as possible using a smartcard or a HSM. Security measures need to be taken and operations procedures must be in place to protect your private keys.

„My private key cannot be exported from the certificate store. I’ve configured this restriction when issuing/requesting the certificate. We are safe.“

I hear this excuse very often when talking to my customers about key protection. The truth is…THIS IS NO KEY PROTECTION!
Yes, you can configure a Windows certificate template to not allow the private key to be exported but this option can be changed manually when requesting the certificate. After that the private key can be exported even though you configerd the template the other way round.
And even if the certificate was sign and the export option was not changed during the request the private key is not safe on your machine.

As long as you are not using any kind of physical protection (Smartcard, HSM) the private key is allways stored in software on your Windows based machine. The is a way (a very simple one to be honest) to export the private key from the machine.

The following steps are just an example of how attackers would gain access to the private key. I do not recommend to use this as some kind of backup procedure or key recovery.

Now for the technicians out there I’ll show you how to export a certificate including its private key from the Windows certificate store even though the private key was marked as not exportable.

For this task to be completed we use a tool called „mimikatz“. (By the way one of my favourite tools when it comes to passwords and Kerberos tickets :-)).

In my lab I’ve configured a Windows Enterprise Root CA and a certificate template called „Lab-Computer“

The template does not allow the private key to be exportable.

I then enrolled a certificate on my Windows 10 client using this template and the default settings.

As you can see, the certificate can only be exported without its private key.

By the way…it could be any certificate and could also be the user certificate store instead of the machine store.

How do we get the certificate exported including the private key?

This is where mimikatz comes into the game. Mimikatz can be downloaded from http://blog.gentilkiwi.com/mimikatz and must be copied to the Windows machine where the certificate is installed. Please be aware that some anti virus scanners confiscate the mimikatz executables.
We now run mimikatz with administrative privileges. If I would be an attacker and don’t have administrative privileges on the target machine I could also use mimikatz to get these privileges using a pass the hash or pass the token attack. I might write an article about this topic later.

After mimikatz is started we can use the following two commands to export the previously

crypto::capi
crypto::certificates /systemstore=CERT_SYSTEM_STORE_LOCAL_MACHINE /export

This will export all existing certificates including the private key to the current directory.
The password for the generated pfx files is ‚mimkatz‘.

 To validate the export I’ll now import the pfx file to the user store just to show you that it includes the private key of the certificate.

Simply double click the pfx file and click „Next“.

We now can find the certificate including the private key (as you can see from the small key in the icon) in our personal certificate store.

Very easy and very dangerous.

God safe the keys!
Chris

Microsoft LAPS... yes LAPS not LABS

Microsoft recently published a new tool called LAPS (Local Administrator Password Solution).

https://technet.microsoft.com/en-us/library/security/3062591.aspx

When I talk to customers about local administrator account most of the time I get the same answer.

• We user the same passwort on every client machine that we roll out.
• Our standard local admin password is integrated into our VM deployment. Therefore every new server has got the same local admin password.
• Our standard local admin password on the clients is well know. Every user knows it in case of "emergency".

I bet there are alot of other insecure practices to handle local admin passwords.

In the "good old days" we used Group Policy Preferences to manage local accounts and local admin passwords. We were able to set the password of the local admin via GPP.

Last year Microsoft removed this functionality from GPP because the password was stored insecurely and allowed for priviledge elevation.

https://support.microsoft.com/en-us/kb/2962486

We need to find a more secure and manageable solution for local administrator passwords and that is where Microsoft LAPS comes into the game.

Microsoft LAPS is a solution to automatically change the password of the local administrator account (well known SID -500) on all machines joined to our Active Directory domain to a unique and random value which is regularly changed automatically.

Using LAPS you can make sure that all computers in the AD environment have different and complex local admin passwords. LAPS requires a AD schema extension and adds a new attribute (ms-Mcs-AdmPWD) to the computer class which stores the current admin password. Permissions to read this attribute must be explicitly granted to your users, your helpdesk or your admins. The entire process only relies on Active Directory functionality.

The following steps will show you how to install LAPS. For the demo I used a build of Windows Server vNext (2016) and Windows 10.

The lab (yes, this time with a "b") consists of thow machines.

• DCvNext (Windows Server vNext Domain Controller and LAPS Management Server)
• W10 (Windows 10 Client joined to the AD Domain corp.insidecloud.de working as the LAPS client)

The LAPS client machine can be any Windows OS (from 2003/Vista...no we don't want to use 2003 anymore!). The client MSI package is available in a 32 and 64 bit version. Both packages can be downloaded from Technet (see link at the top of this article).

Now let's start with the installation.

Software Installation

We're logged in to our Domain Controller and double click the "LAPS.x64.msi" file.

Click the "I accept the terms in the license Agreement" (I once met a guy who told me that he knows a guy who knows a guy who has heard of a guy who claims to have ever read the Software License Terms. :-))

 Select every available componenten on the custom setup page.

Click "Next" and click "Install" to install the components.

Finaly close the installed with the "Finish" button.

That's it. Fairly simple. Now let's move on to the client installation.

In order for a client machine (could be Windows Client oder Windows Server OS) to have its password changed automatically it is required to install the client component of LAPS on the machine.
The installation can either be done using the MSI package from above or by extracting a DLL from it and register the DLL manuall. I prefer to register the DLL on my Windows 10 client. Just keep in mind that if you do not install the MSI package and just register the DLL you'll not see the component in the control panel "Programs and Featuers" on the client. On the other hand integrating the DLL silently into your OS deployment.
You can extract the MSI package using the command.

"msiexec /a /qb TARGETDIR="

After extracting the file you'll find severall folders containing the GPO templates and the powershell module as well as a folder CSE which contains the required DLL.

We now copy the DLL to "C:\Windows\System32" and register it using "regsvr32.exe AdmPwd.dll". (Please excuse the German in the screenshot I used a German Windows 10 image)

Active Directory preparation

Now that we have installed the management and client componentn wie need to prepare Active Directory to store the password against a computer object. There will be two attributes added to the Active Directory computer class.

• ms-MCS-AdmPwd - the attribute that holds the password
• mc-MCS-AdmPwdExpirationTime - this attribute stores the time after which the computers password should be changed

We again log on to the Domain Controller where we previously installed the management software. Make sure to be logged on as a member of the "Schema Admins" group and open an elevated Windows PowerShell prompt.

Using the command "Get-Command -Module AdmPwd.ps" we can check the available Cmdlets from the Powershell module. (If you use a Windows Server 2008 R2 you might need to import the module first)

Now we can run "Update-AdmPwdADSchema" Cmdlet to update the schema.

 We need to grant the computers the ability to update their password attribute using the Cmdlet "Set-AdmPwdComputerSelfPermission".

Next we ne to grant rights to users to allow them to retrieve a computers password.

We could also use the "Identity" parameter to grant the permissions to a single computer object.

Group Policy configuration

Client and mangement component is installed and permissions are set. All that's left is to turn on the password synchronization. 

We open GPMC on our Domain Controller and create a new policy "LAPS Clients" that we can link to our "Clients OU" in AD.

These settings are really straightforward, you can configure them how you like. I used the following settings:

• Enable local admin password management: Enabled
• Password Settings: Enabled
• Complexity: Large letters, small letters, numbers, specials
• Length: 14 characters
• Age: 30 days
• Name of administrator account to manage: Not Configured (this will use the default SID -500 account)
• Do not allow password expiration time longer than required by policy: Enabled

How to use LAPS

Now that we have everything installed and configured we can start using LAPS for our daily work and read the passwords from the attribute.

There are different ways to get the password.

You can use "Active Directory Users and Computers" snap-in and the integrated attribute editor to view the password.

Instead of using this simple way you can use the LAPS UI that we installed on the management machine to read the password.

The automated way would be to use Powershell and the Get-ADComputer Cmdlet.

That's it. Next step: Integrate LAPS into your clients and client operations procedures. LAPS could be integrated into your ticket system and allow users to request the admin password and have it automatically resetted to a different value afterwards. Make sure that users didn't create an additional admin account. You could do so using GPP to keep the local admins group clean.

Ideas, ideas, ideas...

Have fun and have a nice week.

Chris

Microsoft Windows based PKI DOs and DON'Ts

DON’T install a Public Key Infrastructure without having a detailed plan. Plan the required PKI roles. Consider availability requirements.

DO use a CAPolicy.inf file for initial configuration during installation. You can use it to define attributes such as basic constraints extension, renewal key length and period, CRLs period, etc.

DO use a standardized naming convention which additionally includes naming of GPOs, templates and accounts related to PKI. Naming conventions should include the CAs Common Name.

DON’T change CA server name after ADCS role installation. Already enrolled certificates will stop working.

DON’T use Root CA to issue certificates directly to end entities.

DON’T install any PKI component on a domain controller. It is technically possible, but not recommended due to security and delegation considerations.

DO install the CA on failover clustering. Microsoft ADCS role can act as active-passive using failover feature of Microsoft Windows operating system.

DO create CPS (Certificate Practice Statement) and CP (Certificate Policy) documents to improve the trust to your PKI. Documents should be based on RFC 3647 recommendations.

DO create at least a 2-tiers architecture. For huge organizations, depending on Active Directory structure and amount of forests and domains, you can extend the architecture to a 3^rd-tier.

DON’T join the Root CA to your Active Directory Domain. Building an “offline” Root CA really means offline with no network connection.

DO protect your offline Root CAs hard drives or virtual disk files and place them in a secure vault until a CA certificate needs to be issued or a new CRL needs to be issued and published.

DO use a HSM to protect the keys of your CAs. I can recommend Gemalto formerly Safenet.

DO consider all operational and security related procedures when implementing a HSM.

DO use at least 4096b keylength for Root CA.

DO change default system accounts. The Local administrator account name should be changed. Domain Admins group should be deleted from the local administrators group on all systems belonging to the PKI.

DO use long and complex password and DO make sure it is kept in safe place.

DON’T leave default AIA (Authority Information Access) URLs with the CA hostname in issued certificates.

DON’T leave default CDP (CRL Distribution Point) URLs with the CA hostname in issued certificates.

If implementing in large organizations, DO use templates OID to differentiate company’s policy objects from default Microsoft policy objects tree. You can request PEN (Private Enterprise Number) from IANA organization (Internet Assigned Numbers Authority).

DO ony use customized templates, DON’T use default ones. Use organization name prefix for templates names.

DO use following commands to publish Roo CA CRLs and .crts to the Active Directory:

certutil -dspublish -f "name_of_root_ca_cert.CRT"  RootCA

certutil -dspublish -f "name_of_ca_crl.CRL"

DO make CDP (CRL Distribution Point) redundant. Include in CDP and publish CRLs to HTTP. Highly consider using split-brain DNS scenario to publish the CRLs.

Microsoft ADCS default repository is C:\Windows\System32\certsrv\CertEnroll. CRLs and CAs certificates are published to this folder. DON’T publish CertEnroll folder directly to the Internet. Instead create a mechanism which copies *.crt and *.crl to another machine and folder. Publish this other machine to the Internet with a reverse proxy.

DO use role separation. In simple scenario these should be: PKIBackupOperators, PKITemplateAdmins, PKIAuditors, PKICertAdmins, PKICAAdmins.

DO enable key archival for private keys if you are using certificates for email or file encryption. Otherwise you’ll not be able to recover old keys used to secure data in the past.

DON’T write down your user’s certificate password/PIN and stick it to monitor or hide under the keyboard.

DO use tokens or smartcards for users and special purpose accounts (Enrollment Agents, etc) if possible.

DO make sure that system time on CAs machines is set correctly.

DO renew the CA certificate with a supply of time so that certificates issued by the CA have shorter life time than the remaining life time of the CA certificate.

DO enable all auditing events for the CA.

certutil -setreg CA\AuditFilter 127

DO perform health checks on your PKI infrastructure using PKIView and check the eventlog on a regular basis.

DO create a CA backup, including private key, CA certificate, certificate database and certificate database log, CAPolicy.inf file, CA configuration from the registry and exported CA templates.

DO make sure that system backup is done regularly. Backups should be protected with password and kept in safe place.

DON’T consider internally issued certificates as a qualified certificate. Consider certificate usage to make sure the certificate is issued by the corresponding internal or external CA.