Project

General

Profile

Actions

Feature #6925

open

multi-buffer support for HTTP cookies

Added by Brandon Murphy about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

Overview

Multibuffer allows for great detection methods when multiple entries of a single "type" is observed.

I think it'd be worth considering supporting multi-buffer matching for HTTP cookies.

Current Behavior

Consider the attached pcap which contains two "Set-Cookie" headers within the HTTP response.

This traffic matches the following rule currently in the ET Open ruleset which currently contains an unbuffered content match for an HTTP cookie.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET EXPLOIT_KIT Evil Redirector Leading to EK Oct 26 2015"; flow:established,to_client; content:"|0d 0a|Set-Cookie|3a 20|qtaho="; classtype:exploit-kit; sid:2022001; rev:3;)

My intention was to convert this rule to http.cookie. realized that depending on the ordering of and presence of other Set-Cookie headers, the qtaho= might appear at the start of the buffer or it could appear as ` ,qtaho=`.

While this behavior of concatenating cookies (and other anytime multiple values for the same header name) is documented well enough, it results in writing signatures that are less than exact or require the use of PCRE to ensure the signature matches on both possibilities as seen below.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET EXPLOIT_KIT Evil Redirector Leading to EK Oct 26 2015"; flow:established,to_client; http.cookie; content:"qtaho="; pcre:"/(?:^|,\x20)qtaho=/"; classtype:exploit-kit; sid:2022001; rev:3;)

Proposed Solution

By supporting multi-buffer matching we can eliminate the need for pcre, thus resulting in a more performant rule.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET EXPLOIT_KIT Evil Redirector Leading to EK Oct 26 2015"; flow:established,to_client; http.cookie; content:"qtaho="; startswith; classtype:exploit-kit; sid:2022001; rev:3;)

Considerations

In the proposed solution, http.cookie was used, however any behavior change in this keyword would be a "breaking" change needing careful testing. It might be worth considering using a new keyword (similar to http.request_header/http.response_header) that would make use of the multi-buffer support.

While considering this feature of HTTP cookies, I wonder if it'd be worth considering this behavior for any HTTP header. The impacts of multi-buffer on #5775 would be very interesting as well, perhaps it's worth supporting them natively . (I'll make a note over on that feature request as well)


Files

cookies.pcap (651 Bytes) cookies.pcap Brandon Murphy, 04/06/2024 09:25 PM
Actions #1

Updated by Brandon Murphy about 1 month ago

  • Subject changed from Allow multi-buffer support for HTTP cookies to multi-buffer support for HTTP cookies
Actions

Also available in: Atom PDF