Testing web-based attacks using DVWA

As per a CDNetworks report, around 45.127 billion web applications were detected and blocked throughout 2022, which is an increase of 96.35% compared to 2021 (https://www.cdnetworks.com/news/state-of-waap-2022/). Attacks on web applications have become so common that they are now the main cause of data breaches. Some of the most common types of web application attacks include cross-site scripting (XSS), DDoS, cross-site request forgery (CSRF), XML External Entity (XXE), and SQL Injection. Suricata with the ET ruleset can detect such attacks by dissecting packet payloads and scrutinizing HTTP/HTTPS protocol headers for anomalies or abnormal traffic patterns. In this section, we will utilize an intentionally infected web application, DVWA. DVWA is a PHP-based application and is popular among penetration testers and ethical hackers as it helps them get hands-on with security vulnerability and exploitation. We will cover these points in the following subsections:

• Lab setup
• Setting up the victim server with DVWA
• Test an SQL Injection attack
• Test a reflected XSS attack

Lab setup

In this lab setup, we need four parts: an attacker machine (Kali Linux or Ubuntu), a victim server (DVWA running on a Debian server), a TAP server (Wazuh and Suricata agents on Ubuntu), and a Wazuh server. The lab design is in the following figure:

Figure 1.21 – The lab setup for detecting web-based attacks using Suricata

Let’s break this down further:

• The attacker machine is Kali Linux, but you can use any other machine.
• The DVWA application has been installed on a Debian-based server.
• Ubuntu Server deployed in promiscuous mode (a network setting) and running a Suricata IDS and Wazuh agent. Promiscuous mode allows the network adapter to intercept and read all the network traffic that it receives.
• The Wazuh server is deployed as a VM.

Setting up the victim server with DVWA

We will be installing a DVWA application on a Debian-based Linux distribution. You can download it from the following link: https://www.debian.org/distrib/. Our DVWA application has some dependencies such as php, an apache2 web server, and a MySQL database:

1. Let’s first install all of them with the following command:

   sudo apt -y install apache2 mariadb-server php php-mysqli php-gd libapache2-mod-php

2. Next, prepare the database:
   1. We need to run the initial database setup:

      sudo mysql_secure_installation

   2. Type yes and then create a user and set its privileges:

      CREATE USER 'dvwa'@'localhost' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON dvwa.* TO 'dvwa'@'localhost' IDENTIFIED BY 'password';

3. Next, install the DVWA application. The DVWA source code is available on GitHub. You can enter the following command under /var/www/html:

   cd /var/www/html
   sudo git clone <https://github.com/digininja/DVWA.git>
   sudo chown -R www-data:www-data /var/www/html/*

4. Let’s configure the PHP file. For this, go to the /var/www/html/config directory. You will find the config.inc.php.dist file. Just make a copy of this file:

   cp /var/www/html/config/config.inc.php.dist /var/www/html/config/config.inc.php

5. Update the database information under the config.inc.php file. Change the db_user to dvwa and db_password to password.
6. Start the mysql service:

   systemctl start mysql or service mysql start

7. Update the php file and go to /etc/php/x.x/apache2/ to open the php.ini file.
8. Search for allow_url_include and set to On.
9. Launch DVWA.
10. Open DVWA with http://localhost/DVWA/setup.php and then reset the database.
11. Now, log in to DVWA with the default credentials:

    username: admin
    password: password

This completes our DVWA application installation. Next, we can start testing the DVWA application from Kali Linux against SQL Injection and XSS as explained in the next section.

Test an SQL Injection attack

SQL Injection, or SQLi, is a type of cyberattack in which malicious SQL code is injected into an application. This lets the attacker extract or modify the contents of the database. This attack modifies the database by tricking the program into running SQL commands that weren’t intended to be run. In order to test the DVWA application against SQL Injection vulnerability, we need to insert our malicious payload into the HTTP request itself:

http://<DVWA_IP_ADDRESS>/DVWA/vulnerabilities/sqli/?id=a' UNION SELECT "Hello","Hello Again";-- -&Submit=Submit

Let’s break this down:

• UNION SELECT "Hello","Hello Again": The UNION SELECT statement is used to combine the results of two or more SELECT queries into a single result set. In this case, the attacker wants to add their own information to the query result. "Hello" and "Hello Again" are the text information that the attacker wants to inject into the query result.
• -- -: This is a comment in SQL. Everything following this on the same line is considered a comment and ignored by the SQL processor.
• &Submit=Submit: This part suggests that the query could be part of a form submission where the Submit parameter is sent with the Submit value.

Now, let’s check on our Wazuh dashboard for the relevant security alerts.

Figure 1.22 – Visualizing SQL Injection alerts

As you expand the individual security alert, you will see detailed information about the alert, the Suricata ET rule, and the category as shown in the following figure:

Figure 1.23 – Suricata alert for SQL Injection on the Wazuh dashboard

Let’s break this down:

• Suricata: Alert - ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT: This represents the security alert name
• data.alert.category Web Application Attack: This shows the category of the rule as specified in the Suricata ET ruleset
• Data.alert.metadata.tag: SQL_Injection: This shows the metadata of the Suricata ET ruleset for web application attacks

As we scroll down the alert information even further, we will see more information, as shown in the following figure.

Figure 1.24 – Detailed information of a Suricata alert for SQL Injection

Let’s break this down:

• data.http.http.user_agent: This represents the browser information from where the attack has been attempted
• data.http.url: /DVWA/vulnerabilities/sqli/?id=a%27%20UNION%20SELECT%20%22text1%22,%22text2%22;--%20-&Submit=Submit: This represents a URL query string for the DVWA, specifically targeting a SQL Injection vulnerability.

Now, we have learned about how to detect SQL Injection attacks using a Suricata IDS and visualize them on a Wazuh dashboard. In the next section, we will test our DVWA application for XSS vulnerabilities. We will later detect and visualize them on a Wazuh dashboard.

Test a reflected XSS attack

XSS is a type of code injection attack that targets websites and sends malicious scripts to a user’s web browser to execute. In a reflected XSS attack, the attacker inserts malicious script into a website or app, which is subsequently reflected onto the user’s browser from the web server. This kind of attack is possible when a user inputs information into the application, and the application reflects it back to the user without enough sanitization or validation. To test if our intentionally vulnerable application, DVWA, for a reflected XSS attack, we can submit a piece of JavaScript code and verify whether it is reflecting the data back to our browser.

You can open the DVWA application and navigate to the XSS (Reflected) tab. Next, enter a sample JavaScript code as written here:

<script>alert("Hello");</script>

Let’s break this down:

• <script> tag: This indicates a piece of JavaScript code that should be executed by the browser
• Alert("Hello"): This is a function that tells the browser to display a pop-up box with the Hello text when the script is executed

You can enter the JavaScript code and click on the Submit button as shown in the following diagram.

Figure 1.25 – Initiating a reflected XSS attack on DVWA

The DVWA application doesn’t have a sanitization check for user inputs, making it vulnerable to reflected XSS attacks. As a result, we will see the Hello text reflected back to our browser as shown in the following diagram.

Figure 1.26 – Visualizing reflected XSS on DVWA

So, the attack was successful. Let’s visualize the alert on the Wazuh dashboard. Navigate to Security Alerts and select the agent.

Figure 1.27 – Suricata alert against an XSS attack

Let’s break this down:

• Security Alert – ET WEB_SERVER Script tag in URI Cross Site Scripting Attempt: This represents the security alert name and signature name.
• data.alert.category Web Application Attack: This represents the category of the alert based on the Suricata ET ruleset.
• data.alert.metadata.tag Cross_Site_Scripting, XSS: This represents the metadata of the security alerts. In our case, it’s Cross_Site_Scripting and XSS.

In this section, we have successfully launched the SQL Injection and reflected XSS on the intentionally vulnerable application called DVWA. Finally, we were able to detect the attacks using Suricata ET rules and visualize them on the Wazuh dashboard.

In the next section, we will emulate multiple attacks on an Ubuntu machine using the tmNIDS project and visualize it on the Wazuh manager.