Security Tester Implementation

One of the key components of the static part is the Security Test Repository, a database that contains tests that can be used by a tool to confirm the existence of known vulnerabilities in the system under benchmark. To implement this component, we decided to adapt a widely used security testing tools that checks the existence of known vulnerabilities on web servers. Nikto is developed in PERL and is simple to execute. The user needs to specify the IP address and port of the web server target using Perl commands.

Figure 5-4 shows the components of the modified version of Nikto, which are described as follows:

 Test Database. This represents the implementation of the Security Test Repository of our benchmark methodology and contains the tests to be run against the web server. In the security test entity of this database, we included an extra field containing the CVSS2 scores (impact and exploitability factors) that is used to estimate the security risk of a positive test.

 Nikto Controller. It is responsible for executing the tool, loading configuration files and calling additional plugins.

 Nikto Plugins (Test Executor). It is composed by a set of plugins that executes many security tests against the web server under benchmark.

 SBENCH Plugin. This is the component we developed to assess the vulnerability risk of each positive security test.

 Benchmark Reports. It is the component responsible for keeping the tool execution log and providing results in an open format (CSV, HTML, XML). We also added in this report the security risk after a test execution (when successful).

The remainder of this section provides more details about the components that we have implemented to enable the execution of security tests.

5.3.5.1 Security Test Database

The Security Test Database is the implementation of the Security Test Repository of our benchmark methodology, currently hosting 6495 security tests for different brands and versions of web servers.

the db_tests database. The fields of this db_test file are described as follows:

 TEST ID. This is the numerical identification of each test run by Nikto.

 OSVDB ID. This is the vulnerability entry reported on the OSVDB on- line database. If no OSVDB ID is reported, this refers to a security test that targets a vulnerability that is probably not reported in public vulnerability databases.

 Server type. This refers to the security test type. This field can have has one of the following values: 0 (File Upload), 1 (Interesting File / Seen in logs), 2 (Misconfiguration / Default File), 3 (Information Disclosure), 4 (Injection (XSS/Script/HTML)), 5 (Remote File Retrieval (Inside Web Root), 6 (Denial of Service), 7 (Remote File Retrieval (Server Wide)), 8 (Command Execution / Remote Shell), 9 (SQL Injection), a (Authentication Bypass), b (Software Identification), c (Remote source inclusion).

 URI. This field presents the URL that will point to the target of the tests.

 HTTP Method. This is the HTTP method that is used during the security test.

 Match 1. String or code used to match for a positive test.

 Summary. Summary message to report if a vulnerability was discovered. Nikto Plugins SBENCH OUTPUT FOLDER Nikto Controller (.pl) Nikto Benchmark Reports

Security Test Database SBENCH Plugin

System Under Benchmark Web server info

 HTTP Data. HTTP Data to be sent during POSTs tests.

 Headers. Additional headers to send during tests.

 CVSS Base Vector. Show the exploitability and impact values to be considered by the SBENCH Plugin for each positive test. Each Base Vector was manually assigned following the CVSS criteria described in Chapter 2.

5.3.5.2 Test Executor

The Test Executor is the component that actually runs security tests against the benchmark target (web servers), and it is implemented by the Nikto Plugin Component. This is a Nikto plugin that is called by the Benchmark Controller of the static part. This Nikto plugin gets one test at a time from Nikto test database and executes it against the web server under benchmark. The test is done by executing a HTTP request with the URL page defined as a test database. Then, it calls the Data Collector and Analyzer to check if the test was successful or not. If a known vulnerability was found (i.e., the test was successful), it calls the component that measures the vulnerability risk based on CVSS values we assigned. Examples of plugins available in Nikto are the CGI plugin (Enumerates possible CGI directories), the Cookies plugin (Looks for internal IP addresses in cookies returned from an HTTP request), and Tests plugin (uses standard Nikto tests).

5.3.5.3 Data Collector and Analyzer

An important aspect to verify if a known vulnerability actually exists is the evaluation of each security test executed. Nikto already has a plugin to collect the response of the web server and to compare the result with the expected value registered in the test database. More specifically, there is a variable that stores the response of the web server that is latter used to check if the test was successful (a

known vulnerability was found) or not. The analysis of the web server response is organized in two parts: test verification and the estimation of the vulnerability risk.

To verify if a test was successful, the web server response is compared with the expected output (match1) of each test. If the result matches, this means that the test was successful and that a known vulnerability is present in the targeted web server.

To estimate the vulnerability risk, we developed a Security Benchmark Plugin (SBENCH Plugin) and added it into the Nikto tool. For each positive test, it estimates the vulnerability risk (in decimal format) based on the impact and exploitability factors.

5.3.5.4 Report Generator

The purpose of the Report Generator is to provide the output needed to confirm the existence of a known vulnerability and the input needed to estimate the security risk of the static part. The Report Generator is implemented in Nikto by the SBENCH and Core plugins. The SBENCH plugin generates a summarized version of Nikto results in CSV format. The core plugin provides the standard Nikto output. Both of them are described as follows:

 CSV output. This report was added in Nikto to provide a consolidated view of the final results. This function is called at the end of tests execution, gets the data sent through input parameters and writes the data into a text file. The fields covered in this report are as follows: date, web server brand, total tests, total errors, total vulnerabilities, number of failed test, percentage of failed tests, and security risk.

 Standard output. This consists of a log file registering each step of a test execution and also providing debugging information that could be used for getting more details about the system target and test execution.