Certificate chain


Certificate chain also known as certification path is the list of certificates used to authenticate the subject. The path starts with the subject’s certificate. Each level up is identified by “Issuer” filed of the certificate. This is the case until we reach the root CA certificate. This certificate is signed by the root CA itself as it is at the top of the hierarchy. Certificate chain allows us to verify the whole trust chain. If any of the certificates in the path fails validation the end certificate cannot be trusted.



Graphic sourced from: http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=%2Fcom.ibm.mq.csqzas.doc%2Fsy10600_.htm

Certificate issued to an endpoint. Issued by the subordinate CA IssuingCA-DC1.kp.local





Subordinate CA certificate issued by ORCA1-CA



Root CA certificate issued and signed by the CA itself


It is important to note that whether certificate chain is checked depends on the implementation of the application. While most of applications and operating systems validate the path some do not. For example some versions of Android don't check the path. We should always test to ensure expected results.

Add a security group to an ACL and propagate the ACE without affecting inheritance

I've recently needed to add a security group to an ACLs of a number shared folders. The problem was that adding a group to the top level folder and propagating permissions down the folder tree would wipe existing permissions. After some time playing with ICACLS I have managed to put toghether a command that just did the trick.

A bit of terminology first:

ACE - Access Control Entry - is a single entry in an ACL, such as "GroupA - Read"
ACL - Access Control List - is a collection of ACEs 

Effectively the below command adds an ACE to an ACL. 

I recommend reading the following article before proceeding:


How Security Descriptors and Access Control Lists Work

http://technet.microsoft.com/en-us/library/cc781716(v=ws.10).aspx

Thiws KB article provides documentation for ICACLS:
http://technet.microsoft.com/en-us/library/cc753525(v=ws.10).aspx


Now the magic command: 

icacls "f:\user" /grant builtin\Administrators:(OI)(CI)(F) /T /c

The above command will grant Administrators group Full Control permission on folder F:\USER  as well as on all sub-folders without affecting inheritance or propagating any other ACEs - this is the key. We have to make sure that a user executing the command has full control permission on all folders.

We can replace "builtin\Administrators" with a domain group for example:

icacls "f:\user" /grant securesenses\Access:(OI)(CI)(F) /T /c

Test thoroughly before proceeding!

Hardening Adobe Reader 11 Using Group Policy


Due to its ubiquitous install base Adobe Reader (AR) has historically been leveraged by malware to facilitate infections.  Sandboxing technology implemented in AR11 largely addresses the problem. The sandbox has however been bypassed using flaw in AR’s JavaScript engine. AR has built in JavaScript engine that itself was the source of most security vulnerabilities in Adobe Reader. The JS is very rarely used in PDF documents and therefore it can be safely disabled.

With the release of version 11, Adobe has published a Group Policy template that can be leveraged to mitigate most of the avenues that attackers use to exploit our systems. 

The template files can be downloaded here:


They are provided in the standard GPO template format used since Windows 2008. There are two files: reader11.admx and reader11.adml. The files need to copied to different locations depending on whether you use local or central GPO stores. 

More information on GPO central store can be found here: http://support.microsoft.com/kb/929841

Supposing we use local store, .admx file should be copied to %SYSTEMROOT%\PolicyDefinitions 
and the .adml file to 
%SYSTEMROOT%\PolicyDefinitions\en-US.

At this point we should see the following in Group Policy Management Console (GPMC):



It is important to note that computer level settings are actual GP settings. This means that users cannot alter the configuration. Also the settings are reverted to their defaults when policy is removed. User level settings are treated as preferences and as such can be altered by users. Also they do not revert to defaults when GPO is removed. 

Security wise we should consider enabling the following settings:

Computer Level>AR>Preferences>Startup: Enable Protected Mode at Startup 



User level>AR>Preferences>Security>Enable Acrobat JavaScript (we obviously want to set this to DISABLED)



As always do test the settings before large scale rollout.


Mitigating Removable Storage Infection Vector Using Group Policy

Removable storage is a very common malware infection vector. While Group Policy allows for fully disabling removable storage, this is not always possible due to usability requirements. 

This post outlines what we can do in an Active Directory environment to mitigate this threat. 

In most cases malware exploits some sort of autoplay feature in order to execute itself and infect a system.

There are three interesting settings we can find in Group Policy that can help us mitigate this threat.

They can be found under "Computer Configuration">"Administrative Templates">"Windows Components">"AutoPlay Policies"



Above configuration disables all autoplay and autorun features, effectively preventing anything from being automatically run.

Another interesting setting is found under "Computer Configuration">"Administrative Templates">"Windows Components">"Removable Storage Access"



 This setting prevents executables or scripts from being executed directly from removable storage device.

Combined, above settings, improve our defences against malware.