Attacking and Testing Sophos SG Web Application Firewall

In a previous article, we set up a security dojo that is accessible for external testing and configured Sophos XG's Web Application Firewall to protect a vulnerable web server.

In this article, I will go through the same steps, but this time using Sophos UTM SG's Web Application Firewall. This will be a very basic configuration designed to show you how to test and learn more about your application and WAF protection options in Sophos UTM (SG).

Picking up from the dojo deployment guide, we need to configure the Sophos SG Web Application Firewall and the external Kali Linux testing machine. Once configured we can run a some tests and inspect the behavior and logging.

Sophos SG Web Application Firewall Configuration Steps

The Damn Vulnerable Web Application (DVWA) is a great place to start since it allows for multiple exploits with differing levels or native protection. It also runs on HTTP port 80 which makes things just a little easier initially. Before we start configuring additional devices, confirm that you are able to connect to the Dojo and that the DVWA site is accessible from another machine on the LAN. Make a note of the IP address.

There are four components on the Sophos UTM that need to be configured to publish the web application.

1. Configure the Host Network object
2. Configure the Real Web Server
3. Configure a Webserver Protection Policy
4. Configure the Virtual Webserver

Step 1: Configuring the Host Network object in Sophos UTM

The host object is the device or IP address that may contain the various services (or sites) you want to test.

1. Navigate to Definitions & Users | Network Definitions | New Network Definition
2. Add a name: securitydojo
3. Type: Host
4. IPv4 address: Use the Dojo IP
5. Click Save

Step 2: Configuring the Real Webserver in Sophos UTM

Defining a Real Webserver allows you to specify a particular service on a host object.

1. Navigate to Webserver Protection | Web Application Firewall | Real Webservers | New Real Webserver
2. Add a Name: DVWA
3. Host: securitydojo (created in the previous step)
4. Type: Plain Text (HTTP)
5. Port: 80
6. Disable backend connection pooling: Checked
7. Click Save

Step 3: Configuring a Webserver Protection Policy in Sophos UTM

This policy is essentially the WAF profile or settings that will be applied. It is specific to web application traffic.

1. Navigate to Webserver Protection | Firewall Profiles | New Firewall Profile
2. Specify a name: DVWA
3. Mode: Reject
4. Common Threat filter: Checked and leave the default settings
5. Click Save

Step 4: Configuring the Virtual Webserver in Sophos UTM

The Virtual Webserver rule is where all of the componenets come together. Once the rule is turned on, the web application is available. There is no explicit firewall rule required.

1. Navigate to Webserver Protection | Web Application Firewall | New Virtual Webserver
2. Specify a rule Name: DVWA
3. Hosted Address: External (WAN) (Address)
4. Type: Plaintext (HTTP)
5. Port: 80
6. Domain: Create new entry dvwa.local
7. Protected Server: select DVWA created earlier
8. Firewall profile: DVWA created earlier
9. Check the box for Pass Host Header
10. Click Save

Most firewalls tell you the URL a threat came from but not the web page someone was one when the URL was loaded. Fastvue Sophos Reporter intelligently stitches Internet access logs together to give you a more accurate view of what sites people are accessing where undesirable files are downloaded from. Try the free 30 day trial.

Attacking Machine Configuration

The attacking machine needs to be configured with the hosts file to enable name lookup and correct header formation. Confirm the IP address on which you have published the DVWA on the Sophos UTM SG appliance.

Edit the hosts file on the attacking machine to at least include DVWA. The file is located at /etc/host for Linux or c:\Windows\System32\Drivers\etc\hosts for Windows. Your entry should be similar to this:

192.168.3.150 dvwa.local

You should now be able to connect to the DVWA with the following link

http://dvwa.local/dvwa/login.php

SQL Injection Test

The following procedure allows you to execute the basic SQL injection test. Open a browser on the attacking machine and follow the steps:

1. Log in with admin and password
2. On the left-hand side select DVWA Security
3. Change the Security Level setting to Low and Submit
4. Select SQL Injection
5. For User ID specify 1 and Submit
6. You should now see a single record returned
7. Now specify %' or '0'='0 and Submit

You should now be presented with a 403 Forbidden Screen.

To confirm that the WAF is the cause for the protection you need to change the firewall rule, by setting the the Protection Policy to ::No Profile::. Repeat the SQL injection test, and you should see that the injection is allowed.

Checking the Sophos SG Live Log

In the Sophos SG management console, mouse over the logviewer (clipboard icon) and select Web Application Firewall. The log viewer will show you WAF events such as profile changes being applied, and security warnings for when suspect traffic is detected and served content.

Checking the Sophos SG shell /var/log/reverseproxy.log file

The live log viewer is okay to get a general overview of what is happening but to really work with the log you will need to SSH to the device, and read the logs directly from var/log/reverseproxy.log

Below is one of several entries that are generated when an attack is identified. In this case, since it is such a generic attempt, there are 6 matches of a potential exploit. These are detection entries and contain great information.

The id field shows the specific rule that was triggered. This is important should you need to exclude the rule for being a false positive. You can also see the actual arguments that triggered the detection being shown in the Matched Data section.

2018:05:24-14:59:55 et-hom-lab-utm httpd\[11554\]: \[security2:error\] \[pid 11554:tid 4113574768\] \[client 192.168.0.108\] ModSecurity: Warning. Pattern match "(?i:(\[\\\\\\\\s'\\\\"\`\\\\xc2\\\\xb4\\\\xe2\\\\x80\\\\x99\\\\xe2\\\\x80\\\\x98\\\\\\\\(\\\\\\\\)\]\*?)(\[\\\\\\\\d\\\\\\\\w\]++)(\[\\\\\\\\s'\\\\"\`\\\\xc2\\\\xb4\\\\xe2\\\\x80\\\\x99\\\\xe2\\\\x80\\\\x98\\\\\\\\(\\\\\\\\)\]\*?)(?:(?:=|<=>|r?like|sounds\\\\\\\\s+like|regexp)(\[\\\\\\\\s'\\\\"\`\\\\xc2\\\\xb4\\\\xe2\\\\x80\\\\x99\\\\xe2\\\\x80\\\\x98\\\\\\\\(\\\\\\\\)\]\*?)\\\\\\\\2|(?:!=|<=|>=|<>|<|>|\\\\\\\\^|is\\\\\\\\s+not|not\\\\\\\\ ..." at ARGS:id. \[file "/usr/apache/conf/waf/modsecurity\_crs\_sql\_injection\_attacks.conf"\] \[line "77"\] \[id "950901"\] \[rev "2"\] \[msg "SQL Injection Attack: SQL Tautology Detected."\] \[data "Matched Data: '0'='0 found within ARGS:id: %' or '0'='0"\] \[severity "CRITICAL"\] \[ver "OWASP\_CRS/2.2.7"\] \[maturity "9"\] \[accuracy "8"\] \[tag "OWASP\_CRS/WEB\_ATTACK/SQL\_INJECTION"\] \[tag "WASCTC/WASC-19"\] \[tag "OWASP\_TOP\_10/A1"\] \[tag "OWASP\_AppSensor/CIE1"\] \[tag "PCI/6.5.2"\] \[hostname "dvwa.local"\] \[uri "/dvwa/vulnerabilities/sqli/"\] \[unique\_id "Wwa3S8CoAKAAAC0ioVoAAAAC"\]

The detection entries are followed by a conviction entry indicating that enough detection has been done to satisfy a conviction and that this request will be blocked. The WAF security module generates these detection and conviction entries even though it does not relate to any page or response being served.

2018:05:24-14:58:43 et-hom-lab-utm httpd\[11280\]: \[security2:error\] \[pid 11280:tid 4130360176\] \[client 192.168.0.108\] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(.\*)" at TX:950901-OWASP\_CRS/WEB\_ATTACK/SQL\_INJECTION-ARGS:id. \[file "/usr/apache/conf/waf/modsecurity\_crs\_inbound\_blocking.conf"\] \[line "26"\] \[id "981176"\] \[msg "Inbound Anomaly Score Exceeded (Total Score: 28, SQLi=14, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2"\] \[data "Last Matched Data: '0'='0"\] \[hostname "dvwa.local"\] \[uri "/dvwa/vulnerabilities/sqli/"\] \[unique\_id "Wwa3A8CoAKAAACwQ7hEAAAAA"\]

Following the detection, a log entry is also added for serving the 403 Permission denied page.

2018:05:24-14:58:43 et-hom-lab-utm httpd: id="0299" srcip="192.168.0.108" localip="192.168.0.160" size="235" user="-" host="192.168.0.108" method="GET" statuscode="403" reason="waf" extra="Inbound Anomaly Score Exceeded (Total Score: 28, SQLi=14, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2" exceptions="-" time="4506" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" port="80" query="?id=%25%27+or+%270%27%3D%270&Submit=Submit" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/" cookie="security=low; PHPSESSID=pdeqonqmr58lvohadklsm4a7u0" set-cookie="-" uid="Wwa3A8CoAKAAACwQ7hEAAAAA"

Compare that to the same request when no inspection is being performed

2018:05:24-14:53:50 et-hom-lab-utm httpd: id="0299" srcip="192.168.0.108" localip="192.168.0.160" size="1610" user="-" host="192.168.0.108" method="GET" statuscode="200" reason="-" extra="-" exceptions="-" time="6171" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" port="80" query="?id=%25%27+or+%270%27%3D%270&Submit=Submit" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/" cookie="security=low; PHPSESSID=pdeqonqmr58lvohadklsm4a7u0" set-cookie="-" uid="Wwa13sCoAKAAACXl6TwAAAAF"

Lastly, you can enable Permit mode on the firewall profile. This will detect attacks and log them as such but will still allow the attack to go through.

**2018:05:24-14:59:55** et-hom-lab-utm httpd\[11554\]: \[**security2:error**\] \[pid 11554:tid 4113574768\] \[client 192.168.0.108\] ModSecurity: Warning. Operator GE matched 5 at TX:inbound\_anomaly\_score. \[file "/usr/apache/conf/waf/modsecurity\_crs\_correlation.conf"\] \[line "37"\] \[id "981204"\] \[msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 28, SQLi=14, XSS=): 981243-Detects classic SQL injection probings 2/2"\] \[hostname "dvwa.local"\] \[uri "/dvwa/vulnerabilities/sqli/"\] \[unique\_id "Wwa3S8CoAKAAAC0ioVoAAAAC"\]

 **2018:05:24-14:59:55** et-hom-lab-utm httpd: id="0299" srcip="192.168.0.108" localip="192.168.0.160" size="1610" user="-" host="192.168.0.108" method="**GET" statuscode="200"** reason="-" extra="-" exceptions="-" time="13944" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" port="80" query="?id=%25%27+or+%270%27%3D%270&Submit=Submit" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/" cookie="security=low; PHPSESSID=pdeqonqmr58lvohadklsm4a7u0" set-cookie="-" uid="Wwa3S8CoAKAAAC0ioVoAAAAC"

Conclusion

You now have a basic setup on which you can test various vulnerabilities using Sophos SG's Web Application Firewall features. I encourage you to play around with adding additional targets and attempting to find the exploits that exist in the vulnerable sites. Then attempt to use the WAF functionality to mitigate the issue. Looking at the raw log is, unfortunately, the only way to get actual visibility into what is happening from the WAF perspective.

Take the pain out of reporting on Web Usage and Network Traffic.

Fastvue Reporter produces clean, simple, web usage reports using data from your firewall that you can confidently send to department managers and HR team. Automate reports and get the job of reporting on web usage off your desk and into the hands of people that need it. Download the 30-day free trial today!