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

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:

• CSC 1: Inventory of Authorized and Unauthorized Devices
• CSC 2: Inventory of Authorized and Unauthorized Software
• CSC 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
• CSC 4: Continuous Vulnerability Assessment and Remediation
• CSC 5: Controlled Use of Administrative Privileges

CSC 6: Maintenance, Monitoring, and Analysis of Audit Logs

The Control

Collect, manage, and analyze audit logs of events that could help detect, understand, or recover from an attack.

The Attack

Most breaches aren’t detected for several months after the initial attack. Often, the only reason the breach is detected at all is due to a release or sale of sensitive information on the dark web. Thankfully, there is a better way! I will demonstrate an SQL injection attack and provide two obvious indicators which could have alerted security staff monitoring system logs that something malicious was happening and that data was being exfiltrated from the system.

From the screenshot below, we can see an example web application which allows for users to search for other users based on their user ID. This would be common functionality in most applications supporting multiple users. With my example below, we can see that if I search for the user ID of 1, the first and last name of the user is returned to me. This is how the application was intended to function.

Web application search functionality

When this search happens, a log is generated on the server to indicate that a user who has visited the site performed a search request for the user ID. The relevant information included in this log entry is:

• Source IP Address (172.16.150.1)
• Date / Time (07/Jun/2016:12:32:06 -0400)
• Requested Page (/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit)
• Response Size (1369 bytes)

Log entry from request

This is what we call normal behavior and can be documented as a baseline of what a normal request would look like. Now, let’s take a look at what an attack might look like on this web application. 

In the image below, we can see that instead of entering a standard user ID such as “1”, I have injected some SQL syntax. This SQL injection allows me to alter the way SQL queries are executed on the SQL database. In this example, I was able to change the logic of the SQL query from selecting the user with the user ID of ‘1’, to an SQL query that selects all users. This is a common form of SQL injection and provides an attacker with an injection point to launch further attacks.

With regards to detecting the malicious behavior, we again can look at the log and determine if anything is different from our baseline request. The relevant information included in this log entry is:

• Source IP Address (172.16.150.1)
• Date / Time (07/Jun/2016:12:38:46 -0400)
• Requested Page (/dvwa/vulnerabilities/sqli/?id=1’ OR ‘1’=’1&Submit=Submit)
• Response Size (4798 bytes)

From investigating the log entry, the attack is clearly visible in two log entry data elements. The first is the actual requested page. In the legitimate request, we requested a user ID. In the terms of how this application functions, we would expect to see a number here. In our malicious request, we have requested a user ID as well as injected additional syntax. This requested ID was 14 characters long and a normal request was one character. Additionally, it is obvious that it contains SQL query language which was not part of the baseline. We can also see that the response size is almost four times as large as the legitimate request (1369 bytes vs. 4798 bytes) indicating that more data is being extracted from the database during the malicious request.  

The Solution

Log management is easy to implement, but hard to master. The level of effort to obtain logs from various sources is actually quite low, however ensuring that the log’s data is accurate, contains the information to help you make informed decisions, or alerts on suspicious activity can be more difficult. I’ve worked with organizations that have had an attack, but then were unable to identify the source of the attack because they were not logging the proper fields.

Deploying security information and event management (SIEM) technology is the first step to a successful log management program. While it is possible to just use raw logs to detect malicious behavior, SIEM’s perform a variety of actions which reduce the amount of effort and can increase the effectiveness of the logs. Some of the tasks that a SIEM will perform are:

• Normalization of log data fields
• Normalization of log time
• Event notifications
• Alarm notifications when an event has occurred
• Automatic log collection

Once a SIEM has been deployed, all systems which are capable of logging should be configured to send their logs to the SIEM. This includes:

• Firewalls logs
• IDS/IPS systems logs
• Proxies logs
• System logs

With all of the logs now being collated by the SIEM, it is possible to start defining some events and alarms to alert staff of malicious behavior. While automated alerts are extremely helpful, it is also important to have security personnel who can review the logs periodically and search for potential attacks. Staff should then follow up on the incident as well as write a new event and alert in the SIEM to detect the incident in the future. Implementing this process and customizing it to your own organization’s base line standards of what normal activity looks like can assist greatly in identifying an attack that may have been successful. The organization may then have an opportunity to react to the attack while in progress rather than after the data has been exposed. 

The next post will cover CSC 7: Email and Web Browser Protections.