Attacking and Testing Sophos XG Web Application Firewall

In a previous article, we went through the steps required to set up a security dojo that is accessible for external testing. In this article, I will go through the required setups for testing Sophos XG Web Application Firewall (aka WAF or Web Server Protection).

This will be a very basic configuration designed to show you how to test and learn more about your application and WAF protection options. Picking up from the Web Security Dojo deployment guide we need to configure the WAF, firewall and the external Kali Linux testing machine. Once configured we can run a couple of tests and then inspect the behavior and logging.

Sophos XG 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 that need to be configured to publish the web application.

Step 1: Configuring the Sophos XG Host Object

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

1. Navigate to System | Hosts and Services | IP Hosts and click Add
2. Add a name: Dojo Security Appliance
3. Select: IPv4
4. Type:  IP
5. IP address: The internal IP address of the Dojo appliance (confirmed earlier)
6. Click Save

Step 2: Configuring the Sophos XG Web Server

Defining a Web Server allows you to specify a particular service on a host object.

1. Navigate to Protect | Web Server | WebServer and click Add
2. Add a Name: DVWA
3. Host: Dojo Security Appliance (created in the previous step)
4. Type: Plain Text (HTTP)
5. Port: 80
6. Disable backend connection pooling: Turn on
7. Click Save

Step 3: Configuring a Web Server Protection Policy

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

1. Navigate to Protect | Web Server| Protection Policies Tab and click Add
2. Specify a name: DVWA
3. Mode: Reject
4. Common Threat filter: ON and leave the default settings
5. Click Save

Step 4: Configuring the Sophos XG Firewall Rule

The firewall rule is where all of the components come together. Only once the rule is turned on is the web application available.

1. Navigate to Protect | Firewall | Add Firewall Rule | Business Application Rule
2. Specify a rule Name: DVWA
3. Hosted Address: #Port2
4. Listening Port: 80
5. Domain: Create new entry dvwa.local
6. Protected Server: select DVWA created earlier
7. In the Advanced section set Protection Policy to DVWA created earlier
8. Check the box for Pass Host Header and click Save

Is your firewall telling simply telling you the URL a threat came from but not what web page someone was one when they URL was loaded? Fastvue Reporter intelligently stitches Internet access logs together to give you a more accurate view of what sites people are accessing when 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 what the IP address is the one on which you have published the DVWA on the Sophos XG 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 None. Repeat the SQL injection test, and you should see that the injection is allowed.

Checking the Sophos XG Web Server Protection Logs

In the Sophos XG management console click Log Viewer in the top right. Select Web server protection on the right-hand drop down box and you should see an entries similar to the image below

We can see an error entry for WAF anomily when the Protection Policy is enabled. We can see a normal log entry for when the Protection Policy is set to none. This provides some information but not very much. Even highlighting the filter icon and getting more information only shows a subset of what is really going on.

Checking the Sophos XG Advanced Shell reverseproxy.log File

To really see what is happening and what is being logged, we need to connect to the Sophos XG console. SSH to the device, enter the advanced shell and read the logs directly from /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 loads of 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.

\[Mon May 21 16:08:24.991640 2018\] **\[security2:error**\] \[pid 13369:tid 4074740544\]- 
- 
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 "/content/waf/2.7.3/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 "WwLS2H8AAAEAADQ5PcQAAAAG"\], referer: http://dvwa.local/dvwa/vulnerabilities/sqli/ 

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.

[Mon May 21 16:08:24.992801 2018] [security2:error] [pid 13369:tid 4074740544]-

ModSecurity: Access denied with code 403 (phase 2). Pattern match "(.*)" at TX:950901-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:id. [file "/content/waf/2.7.3/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 "WwLS2H8AAAEAADQ5PcQAAAAG"], referer: http://dvwa.local/dvwa/vulnerabilities/sqli/

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

[Mon May 21 16:08:24.989342 2018] timestamp="1526911704" srcip="192.168.0.108" localip="192.168.0.150" user="-" host="192.168.0.108" method="GET" statuscode="403" reason="WAF Anomaly" extra="Inbound Anomaly Score Exceeded (Total Score: 28, SQLi=14, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2" exceptions="-" duration="3846" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/" cookie="security=low; security=low; PHPSESSID=oa4ve58sarjni1io1iig1c9bi1" set-cookie="-" recvbytes="507" sentbytes="437" protocol="HTTP/1.1" ctype="text/html" uagent="Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" querystring="?id=%25%27+or+%270%27%3D%270&Submit=Submit" websocket_scheme="-" websocket_protocol="-" websocket_key="-" websocket_version="-" ruleid="7"

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

[Mon May 21 15:57:48.758134 2018] timestamp="1526911068" srcip="192.168.0.108" localip="192.168.0.150" user="-" host="192.168.0.108" method="GET" statuscode="200" reason="-" extra="-" exceptions="-" duration="9654" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/?id=%25%27+or+%270%27%3D%270&Submit=Submit" cookie="security=low; security=low; PHPSESSID=oa4ve58sarjni1io1iig1c9bi1" set-cookie="-" recvbytes="508" sentbytes="1865" protocol="HTTP/1.1" ctype="text/html" uagent="Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" querystring="" websocket_scheme="-" websocket_protocol="-" websocket_key="-" websocket_version="-" ruleid="7"

You can see how the UI logs provide you with some basic information that would indicate an issue but not really enough information to be able to tune your WAF to eliminate false positive or negatives.

Conclusion

You now have a basic setup on which you can test various vulnerabilities. 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!