Bug #7842
Updated by Jeff Lucovsky 22 days ago
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: <pre> > 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| </pre> 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.