TCP Hijack/TCP Segment Overwrite false positives?

Question

Hello all,
I was just curious if anyone else has had many false positives with 3 signatures in particular: TCP Hijack (3250.0 - High), TCP Hijack Simplex Mode (3251.0 - High), and TCP Segment Overwrite (1300.0 - High). The reason I think they are false positives is because they occur everyday, and I've also seem them caused by internal network traffic that crosses an IPS sensor (that is, making the potentially dangerous assumption that the internal devices can be trusted). We usually see between a dozen and 3 dozen a day depending on the signature, and we have 8 IPS total deployed internally and on the perimeters.
Has anyone else had similar experiences? If so, do you have any suggestions on how to decrease the number of false positives for these alerts?
Thanks,
Ryan

Answer 1

I get TCP Hijack and TCP Segment Overwrite all the time. I opened a TAC case about it because it was getting out of hand, and the engineer said that TCP Hijack would be very very hard to execute and if it is getting fired a lot odds are it is a false positive.
This was his response:
5769 - Malformed HTTP Request
This signature basically just looks for traffic destined to one of your web ports (defined by the WEBPORTS variable) and containing a valid HTTP request (i.e., GET, POST, HEAD, PUT, DELETE, TRACE, CONNECT) but followed by malformed (i.e., not proper http protocol syntax) URI information. This type of malformed HTTP request can be used for a variety of exploits. Microsoft has malformed HTTP request vulnerabilities, another attack known as "http request smuggling" can be launched using malformed HTTP requests at a Squid web proxy, which may cause the web proxy and an upstream HTTP agent to disagree on the boundary between HTTP requests on a persistent connection. These are a couple of examples.
If you open this signature in IDM and go to "Edit", you can see the regex it looks for within the http payload. Basically, it looks for a valid HTTP request followed by the hex code regex [\x20][\x21-\x7e]+[\x20]?[\x0d\x0a]. A properly formed HTTP request should not contain this hex code.
It's possible that normal traffic could cause this, but unlikely. If you have further concerns about this signature firing, please capture the trigger packet context either by changing the signature action to 'produce verbose alert' or 'log attacker packet' for analysis. If you need assistance in analyzing these alerts, please contact TAC and open a case on this issue.
3250 or 3251 - TCP Hijack and TCP Hijack Simplex Mode
This signature detects attempts to insert packets into a TCP stream by an attacker in an effort to take over this session. However, if you're using inline ips mode, TCP Hijack attacks are impossible. Also, this type of attack is very rare and not easy to do, and is often a false positive. Types of things that can be used by network sniffers to detect that a TCP hijack may be happening is looking for repeated ARP updates, frames sent between client and server with different MAC addresses, or tcp ack storms.
For these two hijack signatures, per MySDN information:
"This signature fires upon detecting out of order ack packets. The most common network event that may trigger this signature is an idle telnet session. The TCP Hijack attack is a low-probability, high level-of-effort event."
Thus, very likely to be false positives and unlikely to be a legitimate attack given the difficulties involved in doing this. However, it's worth checking out the source / destination of the attacks. Again though, if you are running inline mode, these attacks are impossible and you can ignore these signatures.
About the TCP Segment Overwrite, mine is always fired for port 20 traffic from some sort of web cache server. Is that the same for you?