Project

General

Profile

Actions

Bug #7842

open

inconsistent detection pointer position in base64_data after base64_decode

Added by James Emery-Callcott 27 days ago. Updated 16 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

I've encountered a strange issue in which the detection pointer is not at the beginning of the 'base64_data' buffer unless explicitly moved with something like 'startswith;'

Here are the signatures used for testing:

alert http any any -> any any (msg:"ET HUNTING ysoserial.NET PSObject BinaryFormatter in HTTP POST M2"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"="; base64_decode:relative; base64_data; content:"|ff ff ff ff|"; within:16; content:".PSObject"; content:"|2f|RunspaceInvoke"; classtype:attempted-admin; sid:1; rev:1;) 

alert http any any -> any any (msg:"ET HUNTING ysoserial.NET PSObject BinaryFormatter in HTTP POST M4"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"|27|"; base64_decode:relative; base64_data; content:"|ff ff ff ff|"; within:16; content:".PSObject"; distance:0; content:"|2f|RunspaceInvoke"; classtype:attempted-admin; sid:3; rev:1;)

alert http any any -> any any (msg:"ET HUNTING ysoserial.NET PSObject BinaryFormatter in HTTP POST M4"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"|27|"; base64_decode:relative; base64_data; content:"|ff 01|"; within:2; content:".PSObject"; distance:0; content:"|2f|RunspaceInvoke"; classtype:attempted-admin; sid:3; rev:1;)

here is the beginning of a hexdump of the base64_data buffer straight from suricata-7.0.3:

00000000  00 01 00 00 00 ff ff ff  ff 01 00 00 00 00 00 00  |................|
00000010  00 0c 02 00 00 00 5f 53  79 73 74 65 6d 2e 4d 61  |......_System.Ma|
00000020  6e 61 67 65 6d 65 6e 74  2e 41 75 74 6f 6d 61 74  |nagement.Automat|
00000030  69 6f 6e 2c 20 56 65 72  73 69 6f 6e 3d 33 2e 30  |ion, Version=3.0|
00000040  2e 30 2e 30 2c 20 43 75  6c 74 75 72 65 3d 6e 65  |.0.0, Culture=ne|
00000050  75 74 72 61 6c 2c 20 50  75 62 6c 69 63 4b 65 79  |utral, PublicKey|
00000060  54 6f 6b 65 6e 3d 33 31  62 66 33 38 35 36 61 64  |Token=31bf3856ad|

PCAPs for these cases are also attached.


sid:1 alerts as expected, |ff ff ff ff| is found within the first 16 bytes of the buffer (assuming the detection pointer is at the beginning of the buffer, which in this case it is).

sid:2 does not alert despite the same buffer being dumped from Suricata (the only difference is the static byte that the base64_decode transformation is anchored to). In this scenario, the detection pointer is positioned at byte 8 in the hexdump, meaning the next 2 bytes are |ff 01|.

sid:3 verifies this by doing 'content:"|ff 01|"; within:2;', which generates an alert.

If I modify sid:3 to do 'content:"|00 01|"; startswith;', an alert is generated. So, the buffer does exist in full, it's just getting a weird detection pointer position.


Files

base64_0x27_detptr_bug.pcap (5.36 KB) base64_0x27_detptr_bug.pcap James Emery-Callcott, 08/08/2025 10:58 PM
base64_0x3d_detptr_bug.pcap (86.3 KB) base64_0x3d_detptr_bug.pcap James Emery-Callcott, 08/08/2025 10:58 PM
Actions #1

Updated by Victor Julien 26 days ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Jeff Lucovsky
  • Target version changed from TBD to 8.0.1

@Jeff Lucovsky can you check this? Would be good to get SV tests, and also see if we can recreate the rules using the base64 transform as well to make sure that works correctly. If the issue is confirmed we'll have to backport as well.

Actions #2

Updated by James Emery-Callcott 22 days ago

Seems one of the PCAPs I uploaded is incorrect (the 0x3d PCAP). No matter, the problematic PCAP (0x27) is correct.

Actions #3

Updated by Stuart DC 22 days ago

I was able to replicate this in 7.0.10 but the only difference was my detection pointer offset for the single quote (0x27) match was 6 bytes from the beginning of the base64_data buffer.

For the same payload, content:"|ff ff ff 01|"; within:4; was a valid match.

00000000 00 01 00 00 00 ff ff ff ff 01 00 00 00 00 00 00 |................|
00000010 00 0c 02 00 00 00 5f 53 79 73 74 65 6d 2e 4d 61 |......_System.Ma|
00000020 6e 61 67 65 6d 65 6e 74 2e 41 75 74 6f 6d 61 74 |nagement.Automat|
00000030 69 6f 6e 2c 20 56 65 72 73 69 6f 6e 3d 33 2e 30 |ion, Version=3.0|
00000040 2e 30 2e 30 2c 20 43 75 6c 74 75 72 65 3d 6e 65 |.0.0, Culture=ne|
00000050 75 74 72 61 6c 2c 20 50 75 62 6c 69 63 4b 65 79 |utral, PublicKey|
00000060 54 6f 6b 65 6e 3d 33 31 62 66 33 38 35 36 61 64 |Token=31bf3856ad|
Actions #4

Updated by Jeff Lucovsky 20 days ago

  • Status changed from Assigned to In Progress
Actions #5

Updated by Jeff Lucovsky 19 days ago

  • Description updated (diff)
Actions #6

Updated by Jeff Lucovsky 19 days ago

  • Description updated (diff)
Actions #7

Updated by Jeff Lucovsky 18 days ago

  • Description updated (diff)
Actions #8

Updated by Jeff Lucovsky 18 days ago

James Emery-Callcott wrote in #note-2:

Seems one of the PCAPs I uploaded is incorrect (the 0x3d PCAP). No matter, the problematic PCAP (0x27) is correct.

@James Emery-Callcott -- please delete the incorrect pcap. Thanks

Actions #9

Updated by Jeff Lucovsky 18 days ago

  • Description updated (diff)
Actions #10

Updated by Jeff Lucovsky 16 days ago

Using the rules as listed, I am not able to reproduce the issue and obtain any alerts.

@James Emery-Callcott Please (a) Remove the incorrect pcap and (b) update the rules, including the duplicate sid use for the 2nd and 3rd

Actions

Also available in: Atom PDF