Project

General

Profile

Bug #3047

byte_extract does not work in some situations

Added by Jungho Yoon 3 months ago. Updated about 2 months ago.

Status:
New
Priority:
High
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Heelo. I tested byte_extract and found that it does not work in some situations. snort(2.9.12) detected all of the following situations:

Payload = |31 30 32 36 10 38 20 21 33 34 2e 11 22 33 44 55 66 2e 32 31|
The pcap file is also attached.

alert tcp any any -> any any (msg:"byte extract test 1"; byte_extract:2,0,two1,string,dec; content:"|33 34|"; offset:0; depth:two1; sid:1; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 2"; byte_extract:1,2,two2,string,dec; content:"|33 34|"; offset:8; depth:two2; sid:2; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 3"; byte_extract:1,2,two3,string,dec; byte_extract:1,5,eight,string,dec; content:"|33 34|"; offset:eight; depth:two3; sid:3; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 4"; byte_extract:1,3,sixd1,string,dec; content:"|31 30|"; content:"|33 34|"; distance:sixd1; sid:4; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 5"; byte_extract:1,2,twow,string,dec; byte_extract:1,3,sixd2,string,dec; content:"|31 30|"; content:"|33 34|"; distance:sixd2; within:twow; sid: 5; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 6"; content:"|31 30|"; byte_extract:1,6,three1,relative,string,dec; content:"|36 10|"; offset:three1; depth:2; sid:6; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 7"; byte_extract:1,2,dectwo1,string,dec; content:"|32|"; offset:dectwo1; depth:1; sid:7; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 8"; byte_extract:1,2,dectwo2,string,dec; content:"|32|"; offset:dectwo2; sid:8; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 9"; byte_extract:1,4,hexten; byte_extract:1,0,decone,string,dec; content:"|66|"; offset:hexten; depth:decone; sid:9; rev:1;)
alert tcp any any -> any any (msg:"byte extract test 10"; byte_extract:1,4,two4; content:"|31|"; depth:1; content:"|2e|"; distance:two4; within:1; sid:10; rev:1;)

suricata alert: sid:1, sid:4, sid:5, sid:8
snort alert: all rules

If offset and depth are used together except "offset: 0", they are not alerted.
In case of sid: 10, it will be alerted when removing within or depth.

Is it correct not to work in suricata? Or is it a bug?

Please check the above. Thank you.


Files

byte_extract_test.pcap (1.12 KB) byte_extract_test.pcap Jungho Yoon, 06/14/2019 03:49 PM

History

#1

Updated by Andreas Herz 3 months ago

  • Assignee set to Community Ticket
  • Target version set to Support

There are some differences between suricata and snort regarding this keyword, see https://suricata.readthedocs.io/en/latest/rules/differences-from-snort.html#byte-extract-keyword.

But thanks for submitting rules AND the pcap so we could dig into that.

#2

Updated by Victor Julien 3 months ago

  • Assignee changed from Community Ticket to Andreas Herz

Andreas, could you create a set of suricata-verify tests for this?

#3

Updated by Andreas Herz 3 months ago

sure, can we use those rules and this pcap or do we need dedicated permission?

I also confirmed that as soon as I replace the vars with the value it works as expected, so no issue with the keywords like distance, depth IMHO.

#4

Updated by Andreas Herz 3 months ago

What's also confusing to me, that most of those rules trigger twice even with runmode single. Can anyone confirm and has an idea why?

sudo /usr/bin/suricata -c /etc/suricata/suricata.yaml -S /tmp/byteextract.rules -r /tmp/byte_extract_test.pcap --runmode=single
sudo tail -f /var/log/suricata/eve.json| jq 'select(.event_type=="alert")'

{
  "timestamp": "2019-06-14T17:45:12.603582+0200",
  "flow_id": 1614610294124411,
  "pcap_cnt": 4,
  "event_type": "alert",
  "src_ip": "10.0.0.76",
  "src_port": 5362,
  "dest_ip": "10.0.0.199",
  "dest_port": 80,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 1,
    "rev": 1,
    "signature": "byte extract test 1",
    "category": "",
    "severity": 3
  },
  "flow": {
    "pkts_toserver": 3,
    "pkts_toclient": 1,
    "bytes_toserver": 200,
    "bytes_toclient": 66,
    "start": "2019-06-14T17:45:12.601979+0200" 
  }
}
{
  "timestamp": "2019-06-14T17:45:12.610278+0200",
  "flow_id": 1614610294124411,
  "event_type": "alert",
  "src_ip": "10.0.0.76",
  "src_port": 5362,
  "dest_ip": "10.0.0.199",
  "dest_port": 80,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 1,
    "rev": 1,
    "signature": "byte extract test 1",
    "category": "",
    "severity": 3
  },
  "http": {
    "http_port": 0,
    "url": "!34.\u0011\"3DUf.21",
    "http_content_type": "text/html",
    "http_method": "1026\u00108",
    "status": 400,
    "length": 182
  },
  "app_proto": "http",
  "app_proto_ts": "failed",
  "flow": {
    "pkts_toserver": 5,
    "pkts_toclient": 5,
    "bytes_toserver": 320,
    "bytes_toclient": 643,
    "start": "2019-06-14T17:45:12.601979+0200" 
  }
}

The second timestamp would match the last ACK packet but that doesn't have the content.
I can also reproduce it without byte_extract with this rule:
alert tcp any any -> any any (msg:"byte extract test 1"; content:"|33 34|"; offset:0; depth:10; sid:1; rev:1;)

#5

Updated by Victor Julien 3 months ago

This is probably because the rule matches on both packet payload and stream payload. --engine-analysis could be used to confirm.

Wrt the pcap/rules. Yeah you can use them in the tests. Just add a readme with a link to the ticket.

#6

Updated by Andreas Herz 2 months ago

  • Tracker changed from Support to Bug
  • Status changed from New to Assigned
  • Target version changed from Support to Soon
#7

Updated by Victor Julien about 2 months ago

  • Status changed from Assigned to New
  • Assignee changed from Andreas Herz to OISF Dev
  • Priority changed from Normal to High
  • Target version changed from Soon to 5.0rc1

Also available in: Atom PDF