Project

General

Profile

Actions

Bug #7842

open

inconsistent detection pointer position in base64_data after base64_decode

Added by James Emery-Callcott 7 days ago. Updated 34 minutes 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

Also available in: Atom PDF