Lessons from Security Breaches

Here are my short summary of the article “Learning From A Year of Security Breaches” that are applicable to most of work environments.

• Centralize logs, including host, application, authentication, and infrastructure, into as few system as possible; make critical logs alertable; but be aware of user privacy in what you log
• You might not find the root cause of a beach because of weakness in the environment, systems or people; practicing incident response can indentify these weakness
• Attackers will target employee’s home, personal email, or device to breach the corporate security; Educate your employees to improve their security practices and involve the corporate security team even if they have personal security issues
• Avoid putting secrets and keys into source code
• Protect employees’ credential by integrating Single Sing On or Multi Factor Authentication
• Be aware of insider threats
• Measure and eliminate the security debt - cutting corners for fast growth

Configuring Windows Firewall Settings in Two GPOs May Corrupt the GPO

On my group policy implementation, in addition to learning about the security setting persistence in GPO, I also observe the “corrupted” GPO breaks the GPO replication between two Windows Server 2012 R2 domain controllers.

Here are the group policies applied to the domain controller OU.

 

• Default Domain Policy and Default Domain Controller Policy are untouched as the Windows default
• CDE Domain Policy is applied at the domain level with some firewall rules to allow the antivirus server to communicate with the antivirus client on the servers; and the Windows firewall state is left to “Not Configured” (the default). So the administrator on the server can turn off the firewall when it’s needed.
• PCI Win2012 R2 Hardening - Domain Controller is applied at the Domain Controllers OU level with the PCI compliance settings, including the Windows firewall state to “On”. So the Windows firewall cannot be turned off.

One of the new features in Windows Server 2012 R2 is to detect the GPO replication in Group Policy Management. After configuring and applying the new GPO, I check the status of the new GPO, it shows this GPO is not replicated from the first DC to the second DC with the error “SysVol Inaccessible”.

Troubleshooting

I unlink the new GPO from the domain controller OU, it still shows the same error. As I learn from the previous post, unlinking the GOP does not mean rolling back all the security setting applied to the server.

From the first DC, I can browse to the SysVol share on the second DC via Windows Explorer. Other GPOs are still in sync between the two DCs. So the communication between the two DCs should be fine.

Searching this error on the web, I don’t find any direct relate to this error. Some post does give me an idea that the GPO may corrupt.

I back up and delete the GPO, and verify the replication between the two DCs in sync - selecting the domain name and clicking the status tab in Group Policy Management.

After deleting the GPO, the GPO folder is still left on the drive. This prevents restoring the GPO. I have to manually delete the GPO folder from C:\Windows\SYSVOL\domain\Policies. I also get the access denied error when deleting the folder. Just wait and give enough time for the deletion replication to complete, then I can delete the GPO folder. This also removes this GPO folder from other DCs.

Then I restore the GPO from the backup. When reviewing the settings in the restored GPO, I notice the Windows firewall settings, under Computer Configuration, Policies, Windows Settings, Security Settings, Windows Firewall with Advanced Security, are reverted back to the default (not configured). All my customized Windows firewall settings are gone, but other group policy settings are not impacted.

This leads me to think the corrupted GPO issue (if it is truly corrupted and the replication fails) causing by the Windows firewall settings configured in two GPOs, even there is not conflict in their GPO setting.

To prove my thought, I reconfigure the firewall setting in the new GPO again. Bang! this new GPO is not in sync between the two DCs again!

Then I do the fix again - deleting the GPO and restoring the GPO. This time, I configure the firewall setting in the “CDE Domain Policy” only. All GPOs are in sync between the DCs.

Conclusion

• I am able to duplicate the GPO sync issue between the two DCs if the Windows firewall settings are configured in more than one GPO.
• Configuring all the firewall settings in one GPO does not have the GPO sync issue.
• The GPO sync issue may cause by the corrupted GPO. I don’t get the corruption or sync error (other than SysVol inaccessible) error, like other posts on the internet. So I cannot prove the GPO is corrupted.
• I don’t find any KB or post against configuring firewall settings in multiple GPOs. The closest one I found is this post. It just says merging the firewall setting under the older “Windows Firewall” section and “Windows Firewall with Advanced Security” section may have unpredictable results. In my setup, I only configure the settings in “Windows Firewall with Advanced Security”.
• I don’t know the root cause of the GPO sync issue. For now, I will configure all the Windows firewall settings in only one GPO.

GPO Security Setting Persistence

For security compliance purpose, I want to enforce some Windows settings on the Windows server via the group policy. Some GPOs already exist in the domain. Instead of modifying the existing GPOs, I create a new GPO and link it to the OU where the servers locate. I think I can easily roll back / undo the new settings if they cause any issue, by moving the server out of the OU or unlinking the GPO to the OU.

It turns out my original thought is not 100% correct. Some security settings still persist even if the setting is no longer defined in the policy.

For example, on a new Windows Server 2012 R2 server, the local security policy setting of “Network Security: LAN Manager authentication level” is “Not Defined”. In my new GPO, I configure this setting to “Send NTLMv2 response only; Refuse LM & NTLM”. After linking this new GPO to the OU, I cannot RDP to the servers with the domain login (the error message is “The logon attempted failed”, even my username and password are correct), but the local login is okay.

I unlink the new GPO from the OU for troubleshooting and expect the security settings rolling back to their original configuration. However, I get the same error. And the local security policy on the server still configures “Send NTLMv2 response only; Refuse LM & NTLM”. I reset this setting on the local security policy back to the default “Not Defined”. That solves the problem.

Some posts give me the idea on the fix: post 1, post 2.

Now I learn the “tattooing” behavior on the security settings in the GPO.

Persistence in security settings

Security settings may still persist even if a setting is no longer defined in the policy that originally applied it.

Persistence in security settings occurs when:

• The setting has not been previously defined for the computer.

• The setting is for a registry object.

• The setting is for a file system object.

All settings applied through local policy or a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database, then the setting does not revert to anything and remains defined as is. This behavior is sometimes called "tattooing."

Registry and file settings will maintain the values applied through policy until that setting is set to other values

Reference: Administer Security Policy Settings, “Persistence in security settings”

Using nmap to Test DNS Server Recursion

1. Download nmap binaries. For Windows OS, download the command-line zipfile is sufficient.
2. Unzip the zip file, and install Winpcap and Visual C++ Redistributable Package installer included in the zip file
3. Open command prompt
4. Run “nmap –sU –p53 –script=dns-recursion <DNS_Server_IP>”
5. If the server allows resursion, it shows “Recursion appears to be enabled”

To prevent the DNS server from being used for DNS amplification attacks, disable DNS recursion on the public facing DNS server. The DNS recursion should be enabled on the DNS server serving the internal client.

On a Windows DNS server, this can be done under the DNS server properties, Advanced tab, Server options, check the checkbox “Disable recursion (also disable forwarders)”

Check eDellRoot Certificate and Rogue Certificate

The eDellRoot certificate was a hot topic back in November 2015. This post just summarizes the tools to use check this and other rogue certificate on your computer.

Detection

Steps to check if your computer (mainly the Dell laptop) is vulnerable by the eDellRoot certificate

1. Use Internet Explorer or Chrome (Firefox has its own certificate store, so this test site doesn’t work).
2. Go to https://edell.tlsfun.de/

Removal

If the bad eDellRoot certificate is found on your computer, use the Dell’s official remover to remove it.

Audit the root CA stores

Furthermore, you can scan and audit the trusted root CA stores – both Microsoft (using by IE and Chrome) and Mozillla (using by Firefox), with the following tools:

• RCC from http://trax.x10.mx/apps.html
• the upcoming version of Sigcheck from Mark Russinovish at Microsoft
• Mark Russinovich announced this on Twitter
• As 12/22/2015, this version of Sigcheck is still in beta. Not yet available. I will post an update when the final version is available in public.

What is SHA1

SHA1 (Secure Hashing Algorithm 1) is a hashing algorithm to generate the digital signature (hash) of a document. The signature verifies who created the document (the signer) and that the document wasn’t altered. SHA1 is not an encryption algorithm. Examples of encryption algorithm are AES, DES, RC4, etc.

SHA1 is phasing out by the web browsers (Microsoft, Mozilla, Google) starting on January 1, 2016. The SSL certificate signed by SHA1 should be replaced with a new one signed by SHA2.

To check the SSL certificate on a web server, use

• http://sha1affected.com
• https://www.ssllabs.com/ssltest/