Bug #7842
openinconsistent detection pointer position in base64_data after base64_decode
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
Updated by Victor Julien 6 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.
Updated by James Emery-Callcott 2 days ago
Seems one of the PCAPs I uploaded is incorrect (the 0x3d PCAP). No matter, the problematic PCAP (0x27) is correct.
Updated by Stuart DC 2 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|
Updated by Jeff Lucovsky 29 minutes ago
- Status changed from Assigned to In Progress