Project

General

Profile

Actions

Bug #7842

open

base64: inconsistent detection pointer position in base64_data after base64_decode

Added by James Emery-Callcott about 2 months ago. Updated 18 days ago.

Status:
Feedback
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