Bug #6415
closedhttp.header, http.header.raw and http.request_header buffers not populated when malformed header value exists
Description
Hi Suricata Team,
I was reviewing traffic with a malformed Transfer-Encoding header:
HEAD /resources/fonts/SourceSansPro-Regular.ttf HTTP/1.1 Host: localhost Cookie: X-Qlik-Session=13333333-3333-3333-3333-333333333337 X-Qlik-User: UserDirectory=internal;UserId=sa_repository User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.5790.110 Safari/537.36 Content-Length: 430 Transfer-Encoding: , chunked,
See Attached, qlik_bypass.pcap
The goal was to create a rule containing the malformed Transfer-Encoding value and the X-Qlik-* header to reflect Qlik Bypass CVEs (https://www.praetorian.com/blog/qlik-sense-technical-exploit/).
Before testing, I expected that Suricata would populate http.header, http.header.raw and http.request_headers accordingly.
After testing, it appears that Suricata does not populate http.header and http.header.raw. And additionally for Suricata 7+, http.request_headers is limitedly populated. Only Transfer-Encoding header exists as matchable content.
If possible, could Suricata populate http.header, http.header.raw and http.request_headers buffers despite a malformed value being present?
Thanks in advance for reviewing this!
===Testing Notes===
Suricata Sensors Used: 7.0.1, 6, 5, 4.1.0
The following rule was used to confirm Suricata sees the invalid header value:
alert http any any -> any any (msg:"SURICATA HTTP invalid transfer encoding value in request"; flow:established,to_server; app-layer-event:http.invalid_transfer_encoding_value_in_request; flowint:http.anomaly.count,+,1; classtype:protocol-command-decode; sid:2221005; rev:1;)
Results: For each sensor, 2221005 alerted on qlik_bypass.pcap.
This confirmed that I could use app-layer-event:http.invalid_transfer_encoding_value_in_request; in my final rule. Please see logs/ to review EVE.JSON logs for each engine and an Suricata 7.0.1 output detailing htp_connp_req_data and etc.
The following tests were done to review how Suricata populated http.header, http.header.raw and http.request_headers.
Please see test.rules for the complete set of rules used.
- Test 1, Unbuffered Content only
- sid:11 to sid:16
- For each sensor, all rules alerted.
- Test 2, http.header content only
- sid:21 to sid:26
- For each sensor, no rules alerted.
- Test 3, raw http header only
- sid:31 to sid:36
- For each sensor, no rules alerted.
- Test 5, http.request_header only
- sid:41 to sid:46
- For Suricata 7.0.1, only sid:46 alerts and this rule used http.request_header; content:"Transfer-Encoding". For Suricata 6, 5, and 4.1.0 this test is not applicable because the sticky buffer doesn't exist.
Files