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

By Mike Hodges ·

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-18

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.

figure1
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.

figure2
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. 

figure3
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. 

figure4
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.

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

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

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

figure8
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.

Mike Hodges

Consultant, Attack and Penetration

Mike Hodges is a consultant in Optiv’s advisory services practice on the attack and penetration team. Mike’s role is to provide network and application penetration testing to determine vulnerabilities and weaknesses in client networks and environments. He specializes in assessing the security of perimeter networks and identifying flaws in web applications.