Skip to main content

Posts

Showing posts from March, 2013

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 appl

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 co

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: ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.00/misc/ReaderADMTemplate.zip 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 loc

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"