Top 20 CIS Critical Security Controls (CSC) Through the Eyes of a Hacker – CSC 3

Top 20 CIS Critical Security Controls (CSC) Through the Eyes of a Hacker – CSC 3

In this blog series I am covering the top 20 Center for Internet Security (CIS) Critical Security Controls (CSC), showing an attack example and explaining how the control could have prevented the attack from being successful. Please read previous posts covering:

 

 

CSC3 Series Featured image

 

CSC 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers

 

The Control

 

Establish, implement, and actively manage (track, report on, correct) the security configuration of laptops, servers, and workstations using a rigorous configuration management and change control process in order to prevent attackers from exploiting vulnerable services and settings.

 

The Attack

 

In most penetration tests, the most commonly found vulnerability is a result of weak configurations. Many organizations often leave the default configurations, believing that they should be secure by default. Unfortunately, that is not always the case. It is extremely common to see default configurations that are configured to provide speed and compatibility over security. This makes it much harder for organizations to quickly implement new technologies securely without subject matter experts on staff.

 

For this control, I will demonstrate something that is extremely common, enumeration of data through null sessions. Null sessions are the result of unauthenticated users being able to connect to resources on a machine and query the machine for information. This information (as shown in this attack) may at first seem like a low risk, however, sometimes an attacker can leverage the data to gain access to entire network domains.

 

In the screenshot below, we can see that by running Metasploit, we are able to query a domain controller for a list of all the users. This is accomplished without any username and password and will appear as normal system behavior. This functionality was initially programmed into older versions of Windows to provide a level of compatibility with other devices.

 

CSC3_1

 

A list of all users and groups in Active Directory

 

Depending on how the system is configured and how much information is obtainable, an attacker may be able to also identify the lockout period enforced on the domain. If the attacker is not able to identify the lockout period, they could easily trigger an account lockout to enumerate this policy. The attacker would continuously make requests for an account and determine when the account locks out. By monitoring when the account unlocks, the attacker can determine how many attempts they are able to make within a period of time in order to not lock out accounts.

 

CSC 3.2

 

Testing how many attempts it takes to lock out an account

 

Once the password policy has been obtained, an open-source tool such as TimeLapse can be used to automate password guessing without locking out the account. This is by only making a set number of password guessing attempts within the reset period. 

 

CSC3.3

 

TimeLapse making password guesses without locking out accounts

 

If the attacker is lucky or persistent enough, they will be able to obtain access to valid Active Directory credentials which can be used for further attacks. In the screenshot below, it was possible to execute code and establish a remote presence on a system with local administrator privileges. This goes to show that even just leaking usernames through a default configuration can present a large risk with a determined attacker.

 

The Solution

 

As mentioned above, the key to having secure configurations is having subject matter experts who can review the configuration of new and existing systems and applications. Once a secure, gold standard, default configuration has been created, it should be loaded into a machine image so that the configuration can be applied to all machines. It would not be uncommon to have to create several standard images in this fashion to cover the different types of systems that an organization would run. For instance, web servers will be configured differently than end-user workstations.

 

Once the standard image is running on all systems, it is important to monitor the system for any changes from that standard. This can be accomplished by using a variety of tools. File integrity monitoring will monitor the registry and critical files, while other automated tools such as a vulnerability scanner can probe systems in real time in an attempt to identify any undesirable configurations and deviations from the standardized set of rules.

 

If an organization is unable to put such a large effort in reimaging all machines and creating gold standards, they can attempt to try and enforce security configurations through configuration management tools such as group policy. Group policy can be configured to set options on systems which can disable things such as the null sessions we saw above, however, it will only apply to machines joined to the network. In complex and large networks it is possible for machines to not have the proper group policy object assigned. Thorough testing and monitoring needs to be performed when relying solely on a configuration management tool.

 

The next post will cover CSC 4: Continuous Vulnerability Assessment and Remediation.

Joshua Platz
Principal Security Consultant | Optiv
Joshua Platz is a principal security consultant in Optiv’s advisory services threat practice on the attack and penetration team. Joshua’s role is to execute advanced service offerings such as the advanced threat simulation purple team activity and provide thought leadership and mentorship to the practice. Joshua also executes internal and external network penetration testing, enterprise password audits, and was one of the designers and first executers of the attack surface management offering.