Skip to main content

Posts

Showing posts from 2013

Managing The Local Administrator Password - Part 3 - The Implementation

In this post I outline a step by step guide on implementing the solution. This post builds on the previous one. This is mostly a condensed version of the author’s documentation with addition of some items that either I found unclear or were not covered by the author.  In any case you should read the full documentation found here: http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789/file/96116/1/Documentation.zip WARNING: The solution requires schema extension and this should never be taken lightly so do test properly and proceed at your own risk.  The steps described in this section can be carried out on a Domain Controller or a management workstation.  1. Install the CSE including the “Management Tools” This installs:  AdmPwd.ps PowerShell module  GPO templates (AdmPwd.admx and .adml)  Note: I tested this on a domain with a local GPO store. If you are using a Central Store you should check if the templates have been copied.  The fol

Managing The Local Administrator Password - Part 2 - The Solution

Jiri Formacek, a Microsoft Services consultant (based on his LinkedIn profile), has published an excellent local admin password management solution.  The solution uses Group Policy Client Side Extension (CSE) to set random and unique per computer local administrator password that is changed at a user controlled interval (30 days by default). The password is then stored in a confidential Active Directory (AD) attribute. Permission to retrieve the password is controlled using a security group. The solution is described in the documentation so I won’t be repeating what’s there. I’ll go over the main points and some stuff that’s not covered in the official documentation.  I recommend reading the documentation. The solution can be downloaded here: http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789 The documentation can be found here: http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789/file/96116/1/Documentation.zip I

Managing The Local Administrator Password - Part 1 - The Issue

Local administrator password has always been a cause of a headache for security professionals. There hasn’t been a good and free way to manage the password on a large scale and most organizations ended up using the same password on all desktops or even servers. This introduces a number of vulnerabilities, such as: All IT Staff know the password The password is never changed The password inevitably becomes known to the users and various 3rd parties Machines are exposed to pass-the-hash attacks  If an attacker, a malware or an evil insider gains access to a single machine currently logged on under the local admin account they will be able to access all machines by executing a script or using built-in management tools. Moreover, compromise of a single machine will allow an attacker to grab a password hash and use it to access other computers. The local administrator password can be managed using Group Policy Preferences as detailed in the following article:  https://soc

OCSP response unauthorized or unsuccessful

Windows OCSP client requires that the OCSP responder URL is populated in the AIA extension. If it is not included, Windows will not form the OCSP request properly and the validation will fail with Certutil status of "Unsuccessful". The same certificate was successfully validated by a Cisco ASA OCSP client.  According to the RFC2560 Apendix A.1.1: {url} may be derived from the value of AuthorityInfoAccess or other local configuration of the OCSP client. This does not seem to be the case in Microsoft's implementation.  OCSP responder address is specified in the Authority Information Access (AIA) extension.  In Windows CA, this is configured in the properties of the CA on the"Extensions" tab.  Once configured all newly issued certificates will include the OCSP responder address. Without the OCSP extension validation using certutil fails. According to RFC2560, an OCSP request must specify hashing algorithm, issuer name hash, issuer

x.509 Certificates - Critical vs non-critical extensions

Extensions are used to associate additional information with the user or the key.  Each certificate extension has three attributes - extnID, critical, extnValue extnID - Extension ID - an OID that specifies the format and definitions of the extension critical - Critical flag - Boolean value extnValue - Extension value  Criticality flag specifies whether the information in an extension is important. If an application doesn't recognize the extension marked as critical, the certificate cannot be accepted. If an extension is not marked as critical (critical value False) it can be ignored by an application. In Windows, critical extensions are marked with a yellow exclamation mark,  View certificate extensions using OpenSSL: # openssl x509 -inform pem -in cert.pem -text -noout (output abbreviated)         X509v3 extensions:             X509v3 Key Usage: critical                 Digital Signature, Key Encipherment             X509v3 Subject Key Identifier

Windows CRL caching

By default, both downloaded CRLs and OCSP responses are cached by a Windows client. If a time-valid version of the CRL or OCSP response exists in the cache, the client will use the cached version rather than downloading an updated CRL or submitting a new OCSP request.  Caching related configuration is defined in the following registry hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\ CertDllCreateCertificateChainEngine\Config A binary value of:  ChainCacheResyncFiletime  defines when cache will be cleared.  Force the cache to be cleared: c:\> certutil –setreg chain\ChainCacheResyncFiletime @now Force the cache to clear in 1 hour: c:\> certutil –setreg chain\ChainCacheResyncFiletime @now+0:1 View current cache life time config: c:\>  certutil –getreg chain\ChainCacheResyncFiletime

SCEP certificate enrollment - packet analysis

1. CA cert request: Enrolling device requests and installs CA cert. SCEP Opertion: GetCACert HTTP Header: GET /CertSrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=SCEPLab HTTP/1.0 Host: 10.0.0.6 2. SCEP server returns the CA cert: In the case of GET operation with a type of GetCACert, the MIME content type returned will  depend on whether or not an RA is in use. If there is no RA, only the CA certificate is  sent back in the response, and the response has the content type tagged as application/x-x509-ca-cert. If there is an RA, as it is the case in this lab, the RA certificates are sent back together with the CA certificates.  The content type is application/x-x509-ca-ra-cert. HTTP Header: HTTP/1.1 200 OK Content-Length: 4170 Content-Type: application/x-x509-ca-ra-cert Server: Microsoft-IIS/8.0 Date: Mon, 29 Apr 2013 09:15:51 GMT Connection: close 3. Device requests an identity certificate: SCEP Operation: PKIOperation HTTP H

Enrolling Cisco ASA for certificates via SCEP

1. Install CA cert ciscoasa(config)# crypto ca trustpoint CA ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-trustpoint)# enrollment url http://10.0.0.6/certsrv/mscep/mscep.dll ciscoasa(config)# crypto ca authenticate CA  Debug output : CRYPTO_PKI: HTTP response header: HTTP/1.1 200 OK Content-Length: 4170 Content-Type: application/x-x509-ca-ra-cert Server: Microsoft-IIS/8.0 Date: Mon, 29 Apr 2013 11:13:14 GMT Connection: close Content-Type indicates we have received CA and RA certificates. CRYPTO_PKI:crypto_process_ca_ra_cert(trustpoint=CA) INFO: Certificate has the following attributes: Fingerprint:     537adc87 22cc6e2b 07fdf2e0 18d8ba8b The PKCS #7 message contains 4 certificates. CRYPTO_PKI:crypto_pkcs7_extract_ca_cert found cert CRYPTO_PKI: transaction GetCACert completed CRYPTO_PKI: CA certificate received. CRYPTO_PKI: crypto_pki_authenticate_tp_cert() CRYPTO_PKI: trustpoint CA authentication status = 0 Trustpoint 'CA&

Linux certificate storage

As opposed to Windows, Linux doesn't have crypto APIs that would be usable by user-mode applications.  Linux does have Kernel level CryptoAPI (crypto.h) which is accessible to kernel mode processes.  As such applications store certificates in application specific locations. That way we end up with multiple  copies of the same certificate. One way to workaroud is to designate a directory for certificate storage  and create symbolic links in required directories.  The Linux Kernel Cryptographic API overview: https://thesweeheng.files.wordpress.com/2007/11/6451.pdf Generate CSR using a new key pair: openssl req -nodes -newkey rsa:1024 -keyout serverName.key -out serverName.csr Generate CSR using an existing key pair: openssl req -new -key serverName.key -out serverName.csr Once the request is signed, certs and keypair must be copied to relevant location. Most Linux applications  require Base64 encoded certificate with .PEM extension. This however may vary. Apache for ex

OCSP certificate validation - packet analysis

Online Certificate Status Protocol (OCSP) is an IETF standard defined in RFC 2560  ( http://www.ietf.org/rfc/rfc2560.txt ). OCSP is used for real-time certificate status checking. OCSP uses HTTP as its transport mechanism. Transaction consists of an HTTP query using an HTTP POST verb and an HTTP 200 response.  1. OCSP request (MIME type: ocsp-request): HTTP header: POST /ocsp HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: application/ocsp-request Accept: */* User-Agent: Microsoft-CryptoAPI/6.2 Content-Length: 86 Host: srv3.kp.local The request contains hash of the issuer's name and public key along with the serial number of the certificate to be validated: 2. OCSP response (MIME type: ocsp-response):  HTTP header: HTTP/1.1 200 OK Cache-Control: max-age=580 Content-Length: 1256 Content-Type: application/ocsp-response Expires: Mon, 22 Apr 2013 10:34:16 GMT Last-Modified : Mon, 22 Apr 2013

CRL request over HTTP - packet analysis

One of the ways a CRL can be retrieved is HTTP. Whole transaction consists of an HTTP GET and an OK 200 response packets. The response is a  PKIX-CRL MIME type encoded CRL. PKIX-CRL is an IETF standard defined in RFC 2585 -  http://www.ietf.org/rfc/rfc2585.txt 1. CRL requester generates an HTTP query using an HTTP GET verb HTTP header: GET /pki/IssuingCA-DC1.crl HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Accept: */* User-Agent: Microsoft-CryptoAPI/6.2 Host: dc1.kp.local 2. Server responds with CRL encoded in PKIX-CRL MIME type HTTP header: HTTP/1.1 200 OK Content-Type: application/pkix-crl Last-Modified: Mon, 22 Apr 2013 08:29:51 GMT Accept-Ranges: bytes ETag: "d06e258f333fce1:0" Server: Microsoft-IIS/8.0 X-Powered-By: ASP.NET Date: Sun, 21 Apr 2013 08:46:23 GMT Content-Length: 820 WireShark decodes the PKIX-CRL. We can see all CRL extensions directly in the packet.

Cisco ASA Certificate Revocation Checking

ASA supports status verification using CRLs and OCSP. CRL can be retrieved using HTTP, LDAP or SCEP. Revocation checking using CRL: Over HTTP: ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-crl)# protocol http By default ASA will use address listed in CDP extension of the certificate that is being validated.  To override default behaviour we need to add the following in the CRL configuration context. ciscoasa(config-ca-crl)# policy static ciscoasa(config-ca-crl)# url 1 http://cdpurl.kp.local/crl.crl Over LDAP: Certificate I'm using for this lab, doesn't have LDAP address in its CDP extension. Therefore I'm using "policy static"  to specify LDAP URL where CRL can be retrieved.  ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-trustpoint)# crl configure ciscoasa