Bug #203
closedSuricata not alerting on pcap
Description
Suricata is not alerting on the attached pcap. Snort does alert on this, but what is weird is that if you take out the "content" sections of the rule and leave "pcre", Suricata does alert.
SID:2009322
emerging-web_client.rules
Files
Updated by Josh Smith over 14 years ago
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT ACTIVEX SupportSoft DNA Editor Module ActiveX Control Insecure Method Remote Code Execution"; flow:to_client,established; content:"clsid"; nocase; content:"01110800-3E00-11D2-8470-0060089874ED"; nocase; distance:0; pcre:"/(Packagefiles|SaveDna|SetIdentity|AddFile)/i"; classtype:web-application-attack; reference:bugtraq,34004; reference:url,milw0rm.com/exploits/8160; reference:url,doc.emergingthreats.net/2009322; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_CLIENT/WEB_SupportSoft; sid:2009322; rev:4;)
Updated by Anoop Saldanha over 14 years ago
looks like we don't detect http alproto based on port and we also set the packet flags to PKT_STREAM_ADD, because of which we don't do mpm matching on the payload, and since alproto is still undetected because of the mid-stream http, we don't do client reassembly as well, because of which we don't do mpm on the stream as well.
Commenting out stream-tcp-reassmble.c:1966
//p->flags |= PKT_STREAM_ADD;
gives the alert, but I doubt we would want it that way
Maybe we can set set the PKT_STREAM_ADD flag for the packet once the alproto has been detected. So that way the flag is unset and we conduct the normal payload MPM till we detect the alproto and once we detect the alproto we set the flag and let the stream MPM take over.
Updated by Gurvinder Singh over 14 years ago
Can you test by enabling the mod-stream session pickup. So that stream engine will start reassembling if it detect the mid stream session
Updated by Victor Julien over 14 years ago
- Target version changed from 1.0.0 to 1.0.1
Updated by Will Metcalf over 14 years ago
Am I understanding this correctly? Are you saying the because it is using port 80, and because it doesn't look like http we don't try to match on it? If this is the case, this logic seems flawed to me. Tons of malware/spyware uses port 80 for it's C&C channel and it may not contain any valid http traffic whatsoever. This may look like the middle of a http conversation but in reality it is a full twh followed by a server response that we should match on. Please correct me if I mis-understand.
Updated by Victor Julien over 14 years ago
- Assignee changed from OISF Dev to Victor Julien
It's a reassembly issue, has nothing to do with ports. Will push out a fix soon.
Updated by Victor Julien over 14 years ago
- Status changed from New to Closed
Fix pushed out.
Issue was caused by the proto detection interaction with the reassembly code. The reassembly code will wait with pushing chunks of reassembled stream into the system until it has been able to determine the protocol, or until it's clear that we will never know the protocol. Here the payload remained under that last threshold. Due to this, the stream was never reassembled. My solution was to simply force the reassembly in case the state of the tcp session went beyond ESTABLISHED, in other words, when the session is closing.
Updated by Anoop Saldanha over 14 years ago
Will Metcalf wrote:
Am I understanding this correctly? Are you saying the because it is using port 80, and because it doesn't look like http we don't try to match on it? If this is the case, this logic seems flawed to me. Tons of malware/spyware uses port 80 for it's C&C channel and it may not contain any valid http traffic whatsoever. This may look like the middle of a http conversation but in reality it is a full twh followed by a server response that we should match on. Please correct me if I mis-understand.
nah. Just that wireshark shows it as http continuation or non-http traffic, but we don't make these assumptions for the kind of alproto based on the port no and enable reassembly.