Top 20 CIS Critical Security Controls (CSC) Through the Eyes of a Hacker – CSC 12
September 22, 2016
In this blog series, members of Optiv’s attack and penetration team are 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
- CSC 7: Email and Web Browser Protections
- CSC 8: Malware Defenses
- CSC 9: Limitation and Control of Network Ports, Protocols and Services
- CSC 10: Data Recovery Capability
- CSC 11: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
CSC 12: Boundary Defenses
Detect/prevent/correct the flow of information transferring networks of different trust levels with a focus on security-damaging data.
Border protections are generally your first line of defense against an outside attacker. It is extremely common for an attacker to probe for as much information as possible from the perimeter network in order to build a profile on the attacker’s target. While the mindset relating to protecting the perimeter network has been around for quite a while, the methods in which it is enforced have changed. Putting up a firewall is no longer enough, organizations today face complex threats which require additional perimeter solutions such as IDS/IPS, SIEM, SSL Decryption, Outbound Proxy and network monitoring.
For my example attack in this blog post, I am going to demonstrate creating a covert channel of communications to exfiltrate data which could be detected by many technologies mentioned above if they are properly configured. In my five years of penetration testing I have only seen one organization with the ability to track and report on my covert communications channel.
This attack involves tunneling the TCP protocol used for most Internet activities (web browsing, email, etc.) over the ICMP protocol, which is used primarily for diagnostics. Most organizations make an effort to filter the known exfiltration opportunities to attackers by limiting the websites they can visit and disabling support for other protocols known to exfiltrate data. Many organizations, however, still leave the ICMP protocol enabled for testing purposes, and by leveraging that we can create a covert communications channel to tunnel out sensitive data. Below is a screenshot of how data would flow from a compromised corporate PC to an attacker’s data store.
Figure 1: Attack Data Flow
To start this attack, an attacker must configure a proxy to relay the ICMP traffic. This is accomplished using the tool ptunnel. With very little technical aptitude, an attacker could configure this proxy in the matter of minutes.
Figure 2: A web proxy is configured to listen for and forward ICMP traffic
Next, in order to exfiltrate data, the attacker must already have some level of access on a compromised corporate machine. Using that access an attacker can begin to send data to the ICMP proxy, which will convert the network traffic into normal Internet bound TCP traffic. We can establish the ICMP proxy tunnel by executing ptunnel and specifying the destination port. In this case we want to chain this with SCP so that we can transfer files over the tunnel in an encrypted format, so we will select destination port 22.
Figure 3: Establishing the ICMP tunnel to the web proxy
The last step involves using the created tunnel to exfiltrate the file containing sensitive data.
Figure 4: Transferring data over the covert communications channel
For this specific attack scenario, only a few technologies can detect and prevent this attack. From what I’ve seen, none of them do it by default. Generally the adage is to support compatibility over security. Devices that analyze network traffic could have rules applied which detect the malicious activity. Analyzing the exfiltration attempt performed, it is possible to identify the traffic as suspicious.
First, showing what normal traffic looks like I have pinged a machine at Google and analyzed its network traffic. Looking at the communications there were two packets exchanged, one ping request and one ping reply. The size of these packets are 100 bytes which is normal for the ICMP protocol. Everything in this request is legitimate and can be used to determine instances on illegitimate ICMP traffic.
Figure 5: Legitimate ICMP traffic
Subsequent requests pertain to data exfiltration. Analyzing this data we can see a few key patterns that than can be utilized to create network traffic rules in an IDS/IPS/SIEM/Application Aware Firewall. These patterns include:
- Large packet size (1000 bytes instead of 100 bytes)
- Huge amount of replies compared to the number of request
- The data payload potion of the ICMP traffic is encrypted
Figure 6: ICMP being used to tunnel data
Fortunately the security industry is full of solutions which, if properly implemented, could detect and potentially prevent this activity from taking place. Boundary defenses are not just about keeping attackers out, but just as much about keeping sensitive information in. Implementing a comprehensive toolset on your perimeter network can give you unseen insight into what is happening and can assist in detecting potentially malicious activity. Some of these tools and strategies are:
- Perimeter IDS/IPS – To filter unwanted malicious communications from getting in
- Outbound Web Proxy – To filter unwanted sites from being visited by employees
- SSL Decryption – To analyze encrypted data for exfiltration or malicious content
- SIEM – To correlate and consolidate data from multiple sources
- Application Aware Firewalls – To analyze outbound communications for abnormalities
The next post will cover CSC 13: Data Protection.