Project

General

Profile

Actions

Bug #6415

closed

http.header, http.header.raw and http.request_header buffers not populated when malformed header value exists

Added by Genina Po about 1 year ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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.

  1. Test 1, Unbuffered Content only
    - sid:11 to sid:16
    - For each sensor, all rules alerted.
  1. Test 2, http.header content only
    - sid:21 to sid:26
    - For each sensor, no rules alerted.
  1. Test 3, raw http header only
    - sid:31 to sid:36
    - For each sensor, no rules alerted.
  1. 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

test.rules (4.59 KB) test.rules Genina Po, 10/19/2023 09:21 PM
logs.zip (142 KB) logs.zip Genina Po, 10/19/2023 09:22 PM
qlik_bypass.pcap (750 Bytes) qlik_bypass.pcap Genina Po, 10/19/2023 09:22 PM

Subtasks 2 (0 open2 closed)

Bug #6529: http.header, http.header.raw and http.request_header buffers not populated when malformed header value exists (6.0.x backport)ClosedPhilippe AntoineActions
Bug #6535: http.header, http.header.raw and http.request_header buffers not populated when malformed header value exists (7.0.x backport)ClosedPhilippe AntoineActions

Related issues 2 (0 open2 closed)

Related to Suricata - Task #6209: libhtp 0.5.46ClosedVictor JulienActions
Related to Suricata - Security #6441: detect: heap use after free with http.request_header keywordClosedPhilippe AntoineActions
Actions #1

Updated by Victor Julien about 1 year ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Philippe Antoine

Philippe can you have a look at what is happening?

Actions #2

Updated by Brandon Murphy about 1 year ago

might be another occurrence of this here

https://forum.suricata.io/t/suricata-rules-http-header-not-working/4120/3

I think, though I don't trust my analysis and defer to Philippe, but it kinda looks like libhtp is considering anything that isn't exactly "chunked" (case insensitive) to be invalid and not parsing the rest of the headers?

https://github.com/OISF/libhtp/blob/0.5.x/htp/htp_transaction.c#L408
https://github.com/OISF/libhtp/blob/0.5.x/htp/bstr.c#L217-L221
https://github.com/OISF/libhtp/blob/0.5.x/htp/bstr.c#L374-L400

Actions #3

Updated by Brandon Murphy 12 months ago

Hello! I am having issues in creating rules for CVE-2023-46747 (Big-IP F5 RCE with mass ITW exploiation)

This appears to be due to the Transfer-Encoding value of chunked, chunked being considered invalid and the http.request_body buffer not populated.

You can see this being used by Metasploit here

https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/http/f5_bigip_tmui_rce_cve_2023_46747.rb#L256

Solid details of the vuln here

https://blog.projectdiscovery.io/cve-2023-46747-5-big-ip-unauthenticated-rce-via-ajp-smuggling/

1. Origin of the Discrepancy: Apache HTTPd receives an HTTP request with a Transfer-Encoding: chunked, chunked header, which it then sends to Tomcat via AJP. Tomcat, expecting Transfer-Encoding to be just chunked, doesn't find a match. It then looks for a Content-length header, which isn't there, so it defaults to assuming a Content-length of 0.
Actions #4

Updated by Philippe Antoine 12 months ago

  • Target version changed from TBD to 7.0.3
Actions #6

Updated by Philippe Antoine 12 months ago

  • Status changed from Assigned to In Review
Actions #7

Updated by Philippe Antoine 12 months ago

Actions #8

Updated by Brandon Murphy 12 months ago

Philippe Antoine wrote in #note-6:

@Brandon Murphy what do you think about. https://github.com/OISF/libhtp/pull/407 ?

I can't be trusted to understand the possible impacts of this change. Though the removal of the "else" seems to have the possibility of a larger impact.

FWIW, the RFC seems to indicate way more than just "chunked" is valid

https://www.rfc-editor.org/rfc/rfc9112#section-6.1-5


 If any transfer coding other than
   chunked is applied to a response payload body, the sender MUST either
   apply chunked as the final transfer coding or terminate the message
   by closing the connection.

   For example,

     Transfer-Encoding: gzip, chunked

   indicates that the payload body has been compressed using the gzip
   coding and then chunked using the chunked coding while forming the
   message body.

From the looks of it, and again, i have no idea what i'm really looking at, but it seems like this case of multiple transfer-encoding values might not get addressed.

It seems to me, this assumption mentioned in the code needs to be evaluated given updates to the original HTTP/1.1 RFC.
// Make sure it contains "chunked" only.

Actions #9

Updated by Victor Julien 12 months ago

  • Subject changed from Suricata not populating http.header, http.header.raw and http.request_header buffers when malformed header value exists to http.header, http.header.raw and http.request_header buffers not populated when malformed header value exists
  • Target version changed from 7.0.3 to 8.0.0-beta1
  • Label Needs backport to 6.0, Needs backport to 7.0 added
Actions #10

Updated by OISF Ticketbot 12 months ago

  • Subtask #6529 added
Actions #11

Updated by OISF Ticketbot 12 months ago

  • Label deleted (Needs backport to 6.0)
Actions #12

Updated by OISF Ticketbot 12 months ago

  • Subtask #6535 added
Actions #13

Updated by OISF Ticketbot 12 months ago

  • Label deleted (Needs backport to 7.0)
Actions #14

Updated by Philippe Antoine 9 months ago

  • Status changed from In Review to Resolved
Actions #15

Updated by Philippe Antoine 9 months ago

  • Related to Security #6441: detect: heap use after free with http.request_header keyword added
Actions #16

Updated by Philippe Antoine 9 months ago

Actions #17

Updated by Philippe Antoine 9 months ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF