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

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 Defense
• CSC 13: Data Protection
• CSC 14: Controlled Access Based on the Need to Know
• CSC 15: Wireless Access Control
• CSC 16: Account Monitoring and Control
• CSC 17: Security Skills Assessment

CSC 18: Application Software Security

The Control

Manage the security lifecycle of all in-house developed and acquired software in order to prevent, detect and correct security weaknesses. 

The Attack

In the current security climate, organizations are dedicating more resources to perimeter security than ever before, which has led to a significant reduction in attack surface; however, web applications still pose a  significant risk to an organization’s security and reputation due to weak security processes during the software development lifecycle. Oftentimes, an attacker will leverage high impact flaws in a web application, such as command injection, default configurations or SQL injection to compromise perimeter defenses.

To begin the attack scenario for this control, let’s start as an attacker who has just identified an Internet-facing employee login portal. This is a common occurrence as most organizations provide portals for their employees to access company resources remotely.

Figure 1: Internet-facing employee login portal

Many times, in-house or third-party login applications have not undergone vigorous security testing and may contain security flaws before being deployed into production. In the example below, the developers left a comment in the HTML to remove all test pages that were being used in development. This reveals the location of a potential test page at /store_locator_test, which could assist an attack in enumeration of more content.  It is not uncommon to find usernames and passwords or other sensitive information as hidden comments within application test pages.

Figure 2: Location of potential test page

The page found at “/store_locator_test” provides very simple functionality: the application takes a zip code as an input and returns all stored identification numbers located in that zip code as output. The nature of the query suggests that the application is querying a SQL database to retrieve the information. 

Figure 3: Test functionality at /store_locator_test

Identifying test functionality deployed in an environment is a common occurrence, and these test applications can often contain security flaws such as SQL injection and cross-site scripting (XSS). When the developers created the test applications, the focus was put on functionality over the security of the application.

A common technique for testing for SQL injection is to insert characters which may break concatenated queries. In this case, when the application is given a single quote as input, the error message reveals that the application is not adequately handling user input when building and executing the SQL statement. This implies the application may be vulnerable to SQL injection. 

Figure 4: A single quote causes an application error

SQL injection occurs when user input is not properly sanitized before being inserted into a SQL query. This allows an attacker to insert SQL meta-characters and keywords in order to manipulate the statement itself, which allows an attacker to query database resources and potentially gain access to the database server.

It was possible to re-write the SQL syntax with additional statements to alter the behavior of the web application. Using a query string of “2222 OR 1=1;--” changes the SQL query to change to “SELECT * FROM stores WHERE zip_code = 22222 OR 1=1;--”. The modified statement will return a true result to the Boolean logic, end the statement, and then comment the remainder of the statement. Bypassing Boolean logic is a common technique for bypassing application authentication and enumerating copious amounts of data from the database. Furthermore, application login allowed the attacker to use the UNION technique, which as shown below, makes it trivial to both enumerate and exfiltrate data contained in the underlying database.

Figure 5: The injection string is passed to the database by the application server

Figure 6: The input '2222 OR 1=1;--' reveals the entire table

Figure 7:  “2222 UNION SELECT schema_name, 2 FROM information_schema.schemata;--" reveals available databases

Figure 8: "22222 UNION SELECT username, password FROM users.users WHERE 1=1;--" reveals usernames and hashes

Due to a lack of defined security procedures in the software development lifecycle this organization has put their customers at a severe risk of fraud and their internal network at risk of compromise.

The Solution

If organizations wish to design their own applications, certain controls need to be in place to ensure the security of these applications. A robust security program including the items outlined below can reduce the overall risk:

• Implement security processes into each phase of the software development lifecycle. The attack scenario above could have been prevented if security had been a concern at any of the development, testing and implementation phases. By incorporating security from the start, major flaws design, development and implementation can be identified and remediated early in the process thus reducing risk and cost to an organization in the future. 
• Ensure all development data such as comments, debug code, unused libraries, etc., are scrubbed from the application server before being deployed into production. These artifacts are often weak points in the application that give an attacker more information about the application and/or a soft target within an otherwise secure application.
• Reduce the risk that a failure in the application will result in an attacker gaining valuable knowledge about the application backend by standardizing error messages that provide users only needed information. Information leakage via verbose error messages often gives the attacker a wealth of information about the architecture of the application and/or provides debugging information for exploitation attempts.
• Harden all database configurations for databases that interact with the application by following the rule of least privilege in regards to data and database methods. In addition, ensure database software is kept up-to-date with the most recent security patches to mitigate the risk posed by any vulnerabilities.
• Configure web application firewalls to inspect traffic going into the application and prevent known attack signatures. The firewalls can provide insight into the attacks an application is receiving as well as the ability to generate new rules to catch newly discovered attack signatures.
• Run web application security scanners against applications before deploying them into production to catch all easily identifiable flaws in application functionality. In this case, an application scanner would have immediately caught this SQL injection vulnerability.
• Conduct penetration tests of Internet-facing applications to identify complex flaws that would otherwise not be found by web application security scanners. It is critical that tests are performed on a reoccurring basis because changes in the application and its environment may present new flaws in the application.

The next post will cover CSC 19: Incident Response and Management.