Security Vulnerability in Azure AD Connect

If you have recently upgraded your DirSync synchronization tool to Azure AD Connect to get your contacts up to Office 365, you will need to do it again.

An exploit in the new Microsoft cloud synchronization tool has just been discovered which allows elevation of permissions.  This exploit allows an attacker to reset the password to an on-premises Active Directory account and gain privileged access such as Domain Admin over a companies domain.

The exploit is in the "Password write back is a component of Azure AD Connect" which needs to be enabled for this exploit to work.

A write-up of this security vulnerability can be found here:

https://technet.microsoft.com/library/security/4033453.aspx?f=255&MSPPError=-2147217396

Luckily most my customers are still using DirSync and are not affected by this vulnerability.

For a comparison between DirSync and Azure AD Connect please see:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-hybrid-identity-design-considerations-tools-comparison

Disable RC4 on Windows Servers

The 13 year old RC4 cipher exploit is enabled by default on Server 2012 R2.  If you have a IIS server using a digital certificate facing the Internet, it's recommended to disable RC4 cipher.

There are numerous security concerns documented on the Internet about this vulnerability including:

https://threatpost.com/attack-exploits-weakness-rc4-cipher-decrypt-user-sessions-031413/77628/

http://www.securityweek.com/new-attack-rc4-based-ssltls-leverages-13-year-old-vulnerability

To disable this vulnerability, add the following to the registry on your Server 2012 R2 operating system:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000

To disable this vulnerability, add the following to the registry on your Server 2012 R2 operating system:

This was put in place on a customers RDS  Gateway and Web Access server after conducting a penetration test and finding this vulnerability enabled by default.

The Danger of the Local Administrator Account

The local administrator account resides on every Windows Server and is usually in an enabled state.  This account is a major security vulnerability and is commonly prone to hacking attempts.

Security flaws with this account include:

• This account cannot be locked out and does not adhere to local or domain account lockout password policies.  This allows brute force attacks to be conducted against the account.
• The local administrator account is a well known SID, it always begins with S-1-5- and end with -500.  There are also tools allowing you to login with a SID rather then an account name so an attacker could launch a brute force without knowing the account!

Quote from Microsoft https://technet.microsoft.com/en-us/library/jj852165.aspx"

"The built-in Administrator account cannot be locked out no matter how many failed logons it accrues, which makes it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum."

If security if your top concern, my recommendation is to disable this account and always create a new Administrator account regardless if it is the default domain Administrator account or default local Administrator account.

Need IT Support in Perth, give me a call now on 08 9468 7575

Windows XP - End of Life Risk

Microsoft has announced that Windows XP will become end of life April 8, 2014 which means no more critical or security updates.  Despite this many organisations still do not have a clear plan in place on how to get client computers off Windows XP before this date.

As a an IT Professional I believe come April 8, 2014, companies still running Windows XP will be hit with a large spread of zero day exploit viruses - something which will go down in history.  For those of you who remember all the hype in the media regarding Y2K bug with the clocks ticking over to a new century and the computers no longer working - whilst there was an impact with the clocks turning over the impact was relatively low.  However with the Windows XP end of life date, I believe this is a huge risk which can cause billions of dollars of productivity loss.  Despite this huge risk, there has been little media coverage around it.

I have just made some very big statements such as "Chaos" and "Billions of dollars of productivity loss" - now I need to explain the facts behind my beliefs.

Today as of this writing there are over 21 million viruses according to virus definition signatures provided by lead anti-virus companies such as Symantec corporation.  Most of these viruses need to be executed on a workstation for infection to take effect - a virus will do nothing if the code is not executed!  There are numerous methods cyber criminals trigger unwanted code execution for viruses some including:

• Fake Ads and URL Links which lead to viral code executing
• Autorun files and USB keys which automatically run on the users workstation
• Peer to Peer applications which spread viruses to individuals
• Mass emailing worms which spread viral code through the use of email attachments
• Microsoft office files which contain macro virtual code

All these methods of infection trick or silently execute viral code on user workstations to install the virus.  As all means are legitimate ways of launching code on computer systems and as a result companies can put in place methods which circumvent viruses being installed including:

• Removing the local admin rights which ensure viruses do not have permissions to infect beyond the users profile.
• Disabling autorun from computers to stop USB viruses from spreading
• Putting in place advanced spam filtering technologies to ensure viral attachments are not executed.
• Pushing out enhanced security policies to workstations on the network.

Out of the 21 million viruses, only a handful have been known as malicious zero day exploits.  Zero day exploits are viruses which exploit an operating system vulnerability to automatically copy themselves from computer to computer over a network providing security and anti-virus companies with zero days to prepare.  Zero day exploits generally perform Buffer Overflow attacks creating vulnerabilities in core system services by overwriting adjacent memory blocks outside of an applications working set.  When the system goes to call code in memory, the code has altered and as a result it executes miscellaneous code which creates a system vulnerability to infect a machine.

The only way to stop a zero day exploits is to patch the security vulnerability in the operating system to ensure the zero day exploit can no longer buffer overflow the vulnerability in the operating system/application.

Over the years there has been a number of zero day exploits which have hit including Conficker, MS Blaster and Stuxnet - a computer worm discovered in June 2010 that is believed to have been created by the United States and Israel to attack Iran's nuclear facilities.  All these viruses were able to spread by performing buffer overflows to simply hop from computer to computer bypassing corporate security measures.

Finding a zero day exploit in an operating system is a difficult task which can take months or years of testing and reverse engineering of compiled code.  Cyber criminals spend large amounts of time researching and performing trial buffer overflows until the right exploit can be identified which can trigger remote code execution.  As soon as the buffer overflow is identified, it can only be used once.  As soon as it is used IT security companies become aware and software companies such as Microsoft patch their software making the buffer overflow useless.

As a result these zero day exploits are worth a lot of money to the right buyer and there is no doubt there are many out there which have been identified but not yet been used.  This can be shown in the following article "Microsoft Said To Give Zero Day Exploits To US Government Before It Patches Them":

http://www.techdirt.com/articles/20130614/02110223467/microsoft-said-to-give-zero-day-exploits-to-us-government-before-it-patches-them.shtml

With the end of Windows XP date becoming so close, it is unlikely we will see many zero day exploits be released unless it is for a targeted purpose such as Stuxnet.  After the Windows XP end of life date I believe we will see a large number of exploits appear for Windows XP and no backing support from Microsoft.  Who knows, if I am correct and the world is hit by a large number of zero day exploit attacks against Windows XP after the end of life date, Microsoft may be forced to go back on this announcement and fix these patches.  If this happens, as for Windows XP, we may be seeing this around for years to come yet...

In summary I believe it is a huge risk to organisations to maintain Windows XP workstations after the April 8, 2014 deadline.  The best thing to protect your business is to get off Windows XP now!

It will be very interesting to see what happens...

Internal Names and Public Certificates

I have just found out today that internal domain names are no longer supported on public certificates.  Please view the following article by DigiCert.

http://www.digicert.com/internal-names.htm

For Exchange this is going to increase the requirement for split DNS within organisations to ensure customers can use the same address for both the Internal and External URLs.  However there are examples which I can see as being a problem moving forward.

When setting up a Remote Desktop Gateway server (for RDP over HTTPS) you need two public certificates, or one certificate with multiple subject alternative names. One public certificate will terminate the SSL endpoint of the RD Gateway server such as "rdpgateway.example.com" and is enabled within Internet Information Services.  The second certificate requires the internal name of the Remote Desktop Session Hosts or Terminal Servers to ensure the RDP traffic is digitally signed such as "terminalserver01.domain.local". This server certificate needs to be installed on the terminal server(s) themselves with the name matching the internal FQDN of the server(s).  Most companies do not install digital certificates to sign RDP traffic, instead they leave the default self-signed certificate on the servers (which does not show up in the local MMC certificates store).  This is why you always see the following warning when initiating remote desktop to a server:

Now we could use an internal certificate authority to issue the certificates for our RD Session Hosts, however this would require that all computers who access the RD Farm to be on the Active Directory domain to ensure they trust the internal certificate authority.  What about if there are users who are connecting in from machines that are not a member of the Active Directory domain?  One of my clients develops an application and sells the application by presenting it to clients as a RemoteApp meaning computers all over the world are launching this application.  Without having a public certificate containing internal names, my customers would receive warnings relating to the RDP traffic being untrusted.

I spoke to a representative from DigiCert about this today, and I ran this example past him.  The advise he presented to me was to rename the Active Directory forest to "local.example.com" to ensure the domain ended with a dot com.  I do not see this as practical especially for large Active Directory domains which consist of thousands of users.

I wonder what other headaches these changes to the certificate standard will present for IT professionals around the world.

Please feel free to leave your comments on the matter.

Microsoft SCM - Export Only Critical Severity

Microsoft SCM is a great tool for quickly deploying security baselines to your organisation.  Microsoft SCM version 2 and higher provides security policies which fall into 4 severity categories:

• Critical
• Important
• Optional
• None

For the average enterprise organisation, they want to implement all policies stipulated under the Critical severity category as most settings in the critical category are in alignment with the former Enterprise Client (EC) baseline.

When you export a Microsoft baseline however to a GPO, it exports policies in all categories - something you want to be very caucious doing as it will significantely reduce functionality.  The "Important" category aligns with the older Specialized Security-Limited Functionality (SSLF), a model that "looks at disabling everything then allowing what is required". 

So how do you go about exporting just policies in the Critical category?

To export all policies in the Critical category, perform the following steps:

Create a custom baseline, for example select one of the Microsoft baselines and then click Duplicate in the Actions pane. Now select your custom baseline, then change to "simple view" by clicking the button to the left　 of Advanced View above the middle pane, click the drop-down menu labeled Group View and select Simple View. Now sort the settings by severity by clicking the top of column labeled Severity. Next, you can use shift-click to click multiple settings, then click Delete in the Actions pane to remove them from the baseline. Use this method to remove the settings with a severity other than critical. Now you can export the baseline with only the desired severity.

Decrypting Network Packet Capture

There may be times where you need to view a network conversation which is encrypted with SSL. What do you do?

You may decrypt the conversation using a tool called "Network Monitor Decryption Expert" which is available for free from codeplex.

http://nmdecrypt.codeplex.com/

How do I go about decrypting the traffic?

Step 1

Start Microsoft Network Monitor (NetMon) and capture the Traffic from Office 365. The latest version as of this writing is 3.4 which is available from http://www.microsoft.com/download/en/details.aspx?id=4865

Step 2

Export the Server Certificate with private key in to a PFX

Step 3

Install the Netmon expert for SSL

Step 4

Now you should be able to decrypt the encrypted traffic.

How to Meet Payment Card Industry Data Security Standard Compliance

Payment Card Industry Data Security Standard (PCI DSS) is a complex set of rules and requirements that applies to every person, business or organisation that handles credit card data. This includes any person, business or organisation that receives, stores, processes or transmits credit card details.

The PCI DSS is a product of the Payment Card Industry Security Standards Council, an organisation founded by participating payment brands Visa International, Master Card, American Express, Diners Club and JCB.

The purpose of the Payment Card Industry Security Standards Council is to establish a uniform world wide standard to aggressively addresses vulnerability and risk associated with the handling of credit card data across all industries.

In this post I will be giving a few tips around how to get your Microsoft Environment to meet PCI DSS compliance.

What is PCI DSS?

First of all you must understand the PCI DSS compliance requirements. Head over to the e-Path website to get an understanding of the rules and requirements around PCI DSS compliance. There is links to PCI Security Standards Council - Supporting documentation which lists everything involved around bring your organisation align with PCI DSS compliance.

http://e-path.com.au/pcidss.html

What do I need to become PCI DSS compliant?

Once you understand the requirements next you need to understand what technology is available to meet these requirements. Microsoft has published an article called "Payment Card Industry Data Security Standard Compliance Planning Guide" which documents all the various Microsoft Technologies available in meeting the PCI requirements. This document is aimed primarily at CIO's and IT Managers however a more detailed target audience is listed inside the document. Download this document from the following location:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=d8320df1-d0d0-469f-a6fc-b53987bd74c2&displaylang=en

Note: The are many third party (non Microsoft products) that can help you meet PCI DSS compliance, look elsewhere for these.

Microsoft Security Guide

Next you should look at the Microsoft Security Guide for meeting PCI DSS compliance. This provides an overview for the Security Compliance Management Toolkit which is a bunch of administrative tools for locking down a Microsoft Windows network.

The Microsoft Solution Accelerators - Security and Compliance (SA-SC) team developed the security guides included in this suite to provide you with recommendations for hundreds of Group Policy security settings designed to assist customers in making the environments of their organizations more secure.

These SA SC team created two policy sets for different environments:
- Enterprise Client (EC)
- Specialized Security - Limited Functionality (SSLF)

Both meet PCI DSS requirements!

Enterprise Client (EC)

The Enterprise Client (EC) environment referred to in this guidance consists of a domain using AD DS in which computers running Windows Server 2008 with Active Directory manage client computers that can run either Windows Vista or Windows XP, and member servers running Windows Server 2008 or Windows Server 2003 R2.

The domain controllers, member servers, and client computers are managed in this environment through Group Policy, which is applied to sites, domains, and OUs. Group Policy provides a centralized infrastructure within AD DS that enables directory-based change and configuration management of user and computer settings, including security and user data. The Group Policy this guide prescribes does not support client computers running Windows® 2000.

Specialized Security - Limited Functionality (SSLF)

The Specialized Security – Limited Functionality (SSLF) baseline in this guide addresses the demand to help create highly secure environments for computers running Windows Server® 2008. Concern for security is so great in these environments that a significant loss of functionality and manageability is acceptable. The Enterprise Client (EC) security baseline helps provide enhanced security that allows sufficient functionality of the operating system and applications for the majority of organizations.

Caution: The SSLF security settings are not intended for the majority of enterprise organizations. To successfully implement the SSLF settings, organizations must thoroughly test the settings in their environment to ensure that the prescribed security configurations do not limit required functionality.

If you decide to test and deploy the SSLF configuration settings to servers in your environment, the IT resources in your organization may experience an increase in help desk calls related to the limited functionality that the settings impose. Although the configuration for this environment provides a higher level of security for data and the network, it also prevents some services from running that your organization may require. Examples of this include Remote Desktop, which allows users to connect interactively to desktops and applications on remote computers.

For a copy of the Windows Server 2008 Security Guide visit the following location:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=fb8b981f-227c-4af6-a44b-b115696a80ac&displaylang=en

Note: This documentation refers to using the "Security Compliance Management Toolkit". This toolkit has now been replaced by "Microsoft Security Compliance Manager 1.0".

GPOAccelerator

The Security Compliance Management Toolkit contains a tool called GPOAccelerator which automatically creates all the GPOs that you need to deploy the recommended security settings for your environment allowing you to meet PCI DSS requirements.

By using GPO Accelerator it saves you time preventing the need for manually editing policy settings and applying templates. It can create the recommended GPO lockdown policies for each type of windows server:



All of the GPOs that the GPOAccelerator creates are fully populated with the settings.

The GPOAccelerator will also create lockdown policies for your workstations.



Please see the following link to download the GPOAccelerator whitepaper:

http://sites.google.com/site/cbblogspotfiles/How-To-Use-the-GPOAccelerator.pdf

Note: GPOAccelerator was a tool included in the Security Compliance Management Toolkit. Security Compliance Management Toolkit is now retired and has been replaced with Microsoft Security Compliance Manager 1.0. Microsoft Security Compliance Manager 1.0 now includes a tool called Local Policy Tool (LPT) which takes over the functionality of GPOAccelerator. Please use LPT to create your security policies to meet PCI DSS requirements.

Auditing Requirements for PCI DSS

I read an excellent article on the auditing requirements for PCI DSS. To understand the Auditing Requirements please read:

http://www.a2media.org/logging-for-the-pci-dss-how-to-gather-server-and-firewall-audit-trails-for-pci-dss-requirement-10-2.html