[Snort-users] Question on stream4 preprocessor

sgt_b sgt_b at ...11733...
Wed Apr 28 07:04:08 EDT 2004


Hey everyone,

Let's say an exploit is sent from one host to another, one byte at a 
time. It's the stream4_reassemble preprocessor's job to reassemble each 
byte of that session into its intended form, and pass that down to the 
detection engine. From there the exploit attempt should be detected by 
snort.
I've tested this, and it works of course.
Here's my question though. As each packet is sent over the wire snort 
picks it up one packet at a time. Each packet along the stream is sent 
to the detection engine as well. If one of these packets triggers an 
alert, what is supposed to happen?

 From what I've read, it looks to me like there should be an alert 
generated for that packet, as well as the entire stream once the session 
is reassembled by stream4.

In practice though, I've noticed some different behavior. In testing 
Nessus's Injection TCP NIDS evasion feature, I've notcied some 
inconsistencies in Snort's reactions.
I'm testing this using the Apache Chunked encodiing vulnerability 
plugin. Utilizing the Injection method, Nessus will send the exploit to 
the webserver one character at a time (ie G in one packet, E in the 
next, T in another, etc) along with garbage packets in between.

Snort will alert on any of the valid packets that only contain a '.' or 
|20| as a libwhisker space splicing attempt. It will not however send 
any alerts regarding the Chunked Encoding vulnerability.
At first I questioned stream4, but if I disable the libwhisker rule, 
stream4 reassembles the packet just fine, and an alert is issued for the 
chunked encoding vulnerability.

Shouldn't two alerts be issued though? One for the libwhisker attempt, 
and once the stream is reassembled, one for the chunked encoding 
vulnerability?





More information about the Snort-users mailing list