Project

General

Profile

Actions

Feature #7846

open

rules/transform: add gunzip transform

Added by James Emery-Callcott 6 months ago. Updated 1 day ago.

Status:
In Review
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

Description

We've seen many use cases in which we would love the ability to utilise some sort of gzip keyword/transformation to allow us to match content within that decompressed buffer. This should function similarly to how base64 keywords work.

A recent example saw a HTTP POST request with a base64 string parameter value. Once decoded, that base64 string contained a gzip compressed data blob which ended up being a malicious executable. Unfortunately, due to this limitation, we were only able to use base64 keywords and then write a signature on the gzip header.

This new feature would allow us to write signatures 1 layer deeper and to identify and differentiate between malicious and benign depending on what is found in that final layer.

ex.

gzip_decompress:relative; gzip_data; content:"blah";


Subtasks 1 (1 open0 closed)

Feature #8235: rules/transform: add gunzip transform (8.0.x backport)AssignedPhilippe AntoineActions

Related issues 1 (1 open0 closed)

Related to Suricata - Feature #6922: Have a way to manually request decompression/inflate if headers are not presentNewOISF DevActions
Actions #1

Updated by Stuart DC 5 months ago

preferably, adding gzip decompression (gunzip) to the transformations would allow us to not only call transform any given buffer but also enable detection writers to transform carved buffers via pcrexform.

Actions #2

Updated by Victor Julien about 1 month ago

  • Subject changed from add the ability to manually call gzip decompress on any buffer and use it with other keywords and transformations to rules/transform: add gunzip transform
Actions #3

Updated by Victor Julien about 1 month ago

I think this should be a regular transform and not use the old base64 pattern with base64_decode; base64_data;

Since decompression comes with some problems, we should be careful about imposing limits.

There should be global hard limits for max decompressed size, possibly also for the input to output ratio.

Then the rule should be able to specify the same settings. The rule limits may not exceed the global limits.

e.g.

# specify limits in the rule
file.data; gzip_decompress: max-size 1MiB, max-ratio 10; content:"MZ";
# use global limits
file.data; gzip_decompress; content:"MZ";

Other options that might make sense are around how many bytes to consider for decompression on the input size.

Actions #4

Updated by Victor Julien 9 days ago

  • Related to Feature #6922: Have a way to manually request decompression/inflate if headers are not present added
Actions #5

Updated by Victor Julien 7 days ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Philippe Antoine
  • Target version changed from TBD to 9.0.0-beta1
  • Label Needs backport to 8.0 added
Actions #6

Updated by OISF Ticketbot 7 days ago

  • Subtask #8235 added
Actions #7

Updated by OISF Ticketbot 7 days ago

  • Label deleted (Needs backport to 8.0)
Actions #8

Updated by Philippe Antoine 7 days ago

Would you have a pcap for testing ?

Actions #9

Updated by Philippe Antoine 1 day ago

  • Status changed from Assigned to In Review
Actions

Also available in: Atom PDF