Microsoft EMET 5 Released

Microsoft’s EMET (Enhanced Mitigation Experience Toolkit) is a free download from Microsoft that enhances Windows security by preventing common malware and exploitation software methods. It does need to be well-tested before deployment, but there are several legacy Windows methods leveraged by malware to get into a system and take control.

Installing EMET provides very strong protection against common malware exploitation methods and can greatly improve the security of WIndows systems.

Description of the mitigations is detailed in my post entitled Microsoft EMET 5 Protection Methods.

 

 The Enhanced Mitigation Experience Toolkit (EMET) is designed to help customers with their defense in depth strategies against cyberattacks, by helping detect and block exploitation techniques that are commonly used to exploit memory corruption vulnerabilities. EMET anticipates the most common actions and techniques adversaries might use in compromising a computer, and helps protect by diverting, terminating, blocking, and invalidating those actions and techniques. EMET helps protect your computer systems even before new and undiscovered threats are formally addressed by security updates and antimalware software. EMET benefits enterprises and all computer users by helping to protect against security threats and breaches that can disrupt businesses and daily lives.

 

Helps protect in a wide range of scenarios

 

EMET is compatible with most commonly used third-party applications at home and in the enterprise, from productivity software to music players. EMET works for a range of client and server operating systems used at home and in the enterprise**. When users browse secure HTTPS sites on the Internet or log on to popular social media sites, EMET can help further protect by validating Secure Sockets Layer (SSL) certificates against a set of user-defined rules.

 

EMET Security Mitigations Included
Attack Surface Reduction (ASR) Mitigation
Export Address Table Filtering (EAF+) Security Mitigation
Data Execution Prevention (DEP) Security Mitigation
Structured Execution Handling Overwrite Protection (SEHOP) Security Mitigation
NullPage Security Mitigation
Heapspray Allocation Security Mitigation
Export Address Table Filtering (EAF) Security Mitigation
Mandatory Address Space Layout Randomization (ASLR) Security Mitigation
Bottom Up ASLR Security Mitigation
Load Library Check – Return Oriented Programming (ROP) Security Mitigation
Memory Protection Check – Return Oriented Programming (ROP) Security Mitigation
Caller Checks – Return Oriented Programming (ROP) Security Mitigation*
Simulate Execution Flow – Return Oriented Programming (ROP) Security Mitigation*
Stack Pivot – Return Oriented Programming (ROP) Security Mitigation

* Available and applicable only to 32-bit processes

** EMET 5.0 supports Windows Vista Service Pack 2, Windows 7 Service Pack 1, Windows 8, Windows 8.1, Windows Server 2003 Service Pack 2, Windows Server 2008 Service Pack 2, Windows Server 2008 R2 Service Pack 1, Windows Server 2012, Windows Server 2012 R2.

 

 

 

Removing an Orphan (inactive) Active Directory Domain

Removing an Orphan (inactive) Active Directory Domain

One of my customers has a forest with several domains, one of which hasn’t been used in a while (call it domain “RedShirt”). The 2 Domain Controllers in the domain, “RedShirt” both tombstoned. Yes, I know, how does that happen? ALWAYS monitor your environment. Since the domain hasn’t been used in a while, it was decided to clean up the domain (remove it).  However, with both DCs tombstoned, one can’t just DCPromo down a domain DC and select “last DC in the domain”.

Microsoft provided information on how to “metadata cleanup” the dead “RedShirt” domain, though the process was not performed 100% properly (always connect to the Domain Naming Master for this process). This process is documented in KB 230306  (How to remove orphaned domains from Active Directory); however, this doesn’t work on a 2008 R2 DC.

Confirm the domain is still listed in the forest by listing the Naming Contexts using Powershell:

Import-Module activedirectory ; (Get-ADRootDSE).namingContexts 

Here’s the correct process to clean-up an orphan domain on a 2008 R2 Domain Controller:

  1. Log onto the Domain Naming Master for the forest
  2. Open a command prompt as Administrator
  3. run ntdsutil
  4. activate instance ntds
  5. partition management
  6. connections
  7. connect to server <DOMAIN NAMING MASTER>
  8. q
  9. List
  10. Note the number & DN of the Domain DNS zone for the orphan domain (in this instance it is #6). The Domain DNS zone needs to be removed first.
  11. Delete NC DC=DomainDNSZones,DC=RedShirt,DC=Metcorp,DC=Org
  12. List
  13. Note the number of the Domain partition for the orphan domain (in this instance it is #5)
  14. Delete NC DC=RedShirt,DC=Metcorp,DC=org
  15. qqq
  16. Force replication by running “repadmin /syncall”

Apple iOS Security Whitepaper

In February of this year, 2014, Apple released an updated whitepaper describing Apple iOS Security. Overall, the operating system and its components are very securely designed.

The Table of Contents:

Introduction
System Security
Secure Boot Chain
System Software Authorization
Secure Enclave
Touch ID
Encryption and Data Protection
Hardware Security Features
File Data Protection
Passcodes
Data Protection Classes
Keychain Data Protection
Keybags
FIPS 140-2
App Security
App Code Signing
Runtime Process Security
Data Protection in Apps
Accessories
Network Security
SSL, TLS
VPN
Wi-Fi
Bluetooth
Single Sign-on
AirDrop Security
Internet Services
iMessage
FaceTime
Siri
iCloud
iCloud Keychain
Device Controls
Passcode Protection
Configuration Enforcement
Mobile Device Management (MDM)
Apple Configurator
Device Restrictions
Supervised Only Restrictions
Remote Wipe

Download and read the PDF Document

 

PowerShell: One-liners to Get You Started

Some of the scenarios covered in the blog post:

  • The server rebooted recently – who did it and when exactly?
  • Is there an easy way to see if KB2862152 is installed?
  • I need to backup all of the GPOs in the domain every day
  • What are the IP settings on my system(s)?
  • What are the BIOS versions on my systems?
  • Are all of my DCs GCs?
  • Which accounts in my domain are enabled and set to never expire the password?
  • How can I parse an input file of some AD attribute for users (SAM Account name in this case) and map those entries to another attribute for those users (the DN in this case)?
  • What is the OS version and Service Pack level for all of my Windows systems in a certain OU?
  • Stop and/or Start all of your lab (Hyper-V) VMs

http://blogs.technet.com/b/askpfeplat/archive/2014/06/16/powershell-one-liners-to-get-you-started.aspx

 

New 2012 SIDs cause lookup issues for older clients

The crux of the issue is that Windows Server 2012 (and above) introduce two new SIDs. The problem is that Windows 7 and Windows Server 2008 R2 clients do not know about these SIDs because when they (Windows 7 and 2008 R2) were written these particular SIDs didn’t exist.

References:

RODC Trick: Remove a User’s Password from a RODC without forcing the user to change her password

TechNet (RODC FAQ) states:

How can you clear a password that is cached on an RODC?

There is no mechanism to erase passwords after they are cached on an RODC. If you want to clear a password that is stored on an RODC, an administrator should reset the password in the hub site. This way, the password that is cached in the branch will no longer be valid for accessing any resources in the hub site or other branches. In the branch that contains the RODC on which the password may have been compromised, the password will still be valid for authentication purposes until the next replication cycle, at which time its value that is stored on the RODC will be changed to Null. The new password will be cached only after the user authenticates with it—or the new password is prepopulated on the RODC—and if the PRP has not been changed.

In the event that an RODC is compromised, you should reset the passwords for all accounts that have cached passwords and then rebuild the RODC.

I disagree.
There is a way to do this. It may not be the officially “supported method”, but there definitely is a way to remove a user’s password from a RODC.

Why would you want to do this? Say that an executive travels to a field site and an admin adds her account to the RODC Password Allow group. This means the executive’s password is cached on the RODC at that site upon successful logon. You realize that the RODC has stored the executive’s password (oops!) and you have the same security concerns about the site that led you to only deploy a RODC there. You want to wipe the password from the RODC, but don’t want the executive to have to change her password. What to do?

Check the RODC computer object and see that the executive (Jane Executive in this example) shows up in the list of security principals with their passwords stored on the RODC (msDS-RevealedList).

The LDAP Modify Operation “RODCPurgeAccount” causes the RODC to NULL the cached secrets of a specified security principal (User or Computer).

Here’s a (likely unsupported) way to do it.

Open LDP on a writable DC and connect to the RODC on port 389 (LDAP) or 636 (LDAPS). Bind to the server (ensure you have Domain Admin credentials). Select Modify (operation) from the drop down and set the following:

DN: [blank]
Edit Entry Attribute: RODCPurgeAccount
Values: CN=Jane Executive,OU=Executives,DC=metcorp,DC=org [Account DN]
Click Replace
Click Enter
Click Run.

You should see the Modify is Successful.

Check the RODC computer object and see that the executive (Jane Executive in this example) is NOT in the list of security principals with their passwords stored on the RODC.

Security concern: the executive’s password was stored on the RODC during some period of time which means it was committed to the AD database (in memory & on disk). The correct way to ensure the executive’s password is not available is to have her change it (when WAS the last time she changed her password?) since this will invalidate any cached passwords floating around the network.

Authentication Problems in an Environment with Windows Server 2003 and Windows Server 2012 R2 Domain Controllers

Why this happens:

The Kerberos client depends on a “salt” from the KDC in order to create the AES keys on the client side. These AES keys are used to hash the password that the user enters on the client, and protect it in transit over the wire so that it can’t be intercepted and decrypted. The “salt” refers to information that is fed into the algorithm used to generate the keys, so that the KDC is able to verify the password hash and issue tickets to the user.

When a Windows 2012 R2 DC is promoted in an environment where Windows 2003 DCs are present, there is a mismatch in the encryption types that are supported on the KDCs and used for salting. Windows Server 2003 DCs do not support AES and Windows Server 2012 R2 DCs don’t support DES for salting.

You might be wondering why these encryption types matter.  As computer hardware gets more powerful, older encryption methods become easier and easier to break.  Thus, we are constantly incorporating newer, more powerful encryption into Windows and Kerberos in order to help protect your user passwords (and your data and your network).

http://blogs.technet.com/b/askds/archive/2014/07/23/it-turns-out-that-weird-things-can-happen-when-you-mix-windows-server-2003-and-windows-server-2012-r2-domain-controllers.aspx

PowerShell: Get all Active Directory Sites based on Domain

Get all Active Directory Sites based on Domain.

 

$DomainSiteFilter = “DomainA”
Write-Output “Get AD Site List `r”
$ADSites = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Sites
[int]$ADSitesCount = $ADSites.Count
Write-Output “There are $ADSitesCount AD Sites in the forest `r”
$DomainADSites = $ADSites | where {$_.Domains -like “*$DomainSiteFilter*”} | sort-object name
[int]$DomainADSitesCount = $DomainADSites.Count
Write-Output “There are $DomainADSitesCount AD Sites matching the domain site filter: $DomainSiteFilter  `r”

$DomainADSites | select name | ft -auto

Microsoft DirectAccess

Microsoft DirectAcess has made great strides in Windows Server 2012.

Key Points:

  • First available with Windows Server 2008 R2.
  • Built-in client support for Windows 7 and newer.
  • Provides always-connected connection to corporate network (connects before the user logs on).
  • Leverages IPV6 and 6to4 tunneling (additional configuration required when using Windows Server 2008 R2 as the DirectAccess server).
  • Windows Server 2012 simplifies the deployment process.
  • Client authentication can leverage Kerberos or certificates. PKI is not required when the DirectAccess server is running Windows Server 2012.
  • DirectAccess clients can be managed regardless of where they are as long as they have network connectivity (outside of the corporate network, internet connectivity is required).
  • DirectAccess connections are IPSec encrypted.
  • The DirectAccess server and clients must be domain-joined.
  • The Windows Firewall needs to be enabled on the server and clients.
  • DirectAccess is not VPN.
  • “When you use Windows 7 clients with DirectAccess in Server 2012 or Server 2008 R2, you need to install a separate DirectAccess Connectivity Assistant (DCA), which gives a system tray icon that shows the DirectAccess connection state.”

Great article describing DirectAccess as well as 2008R2 and 2012 differences and improvements:
http://windowsitpro.com/windows-server-2012/directaccess-windows-server-2012

PowerShell: Determine PowerShell Version

$PSVersionTable.PSVersion

If the variable doesn’t exist, then the system is running version 1.0.