TCP Hijack/TCP Segment Overwrite false positives?

RITgrad2008 · ‎10-15-2007

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

nykoelle01 · ‎10-19-2007

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?

mhellman · ‎10-19-2007

The original poster didn't ask about this sig, but just for clarity, these sigs are looking for HTTP requests that either are missing the URI or are not terminated correctly (missing line feed). I can't say that I've ever seen them fire in my environment, and we see a lot of HTTP traffic. Normal traffic should never cause this to fire, but a bad application might;-)

As far the TCP hijack sigs, we see them often and I haven't had time to really ig into them (I'm in no hurry because I know they're false positives). Same with the segment overwrite, although I have casually looked into these and believe them to be the result of application problems.

mattgioia · ‎10-22-2007

I also remember reading that if you have the IDS watching multiple network segments where the traffic gets duplicated and/or translated (such as a content management switch) it can cause this signature to fire off. I've filtered from internal networks to our content management server farm network and also on ports that carry encrypted traffic (https, ssh) since it's nearly impossible to hijack an encrypted session.

jnommensen · ‎10-26-2007

I see TCP Segment Overwrite (1300.0 - High) several times a day originating from the same web traffic - myspace and hitbox.com usually. I am also looking for a way to decrease the amount of false positives from these alerts.

nykoelle01 · ‎10-26-2007

I turned Produce Verbose Alert on for this on one of our sensors, and the overwhelming majority of times it was fired, it was from verisign:

0100 0e 56 65 72 69 53 69 67 6e 2c 20 49 6e 63 2e 31 .VeriSign, Inc.1

0110 1f 30 1d 06 03 55 04 0b 13 16 56 65 72 69 53 69 .0...U....VeriSi

0120 67 6e 20 54 72 75 73 74 20 4e 65 74 77 6f 72 6b gn Trust Network

0130 31 3b 30 39 06 03 55 04 0b 13 32 54 65 72 6d 73 1;09..U...2Terms

0140 20 6f 66 20 75 73 65 20 61 74 20 68 74 74 70 73 of use at https

0150 3a 2f 2f 77 77 77 2e 76 65 72 69 73 ://www.veris

Perhaps however VeriSign applies its security is triggering this signature? Anyone know of a way to filter it out so that if verisign is in the url header, not to fire the signature?

AdnanShahid · ‎04-28-2008

Hi,

Any of you could help me out whether I am getting False alerts on TCP Segmet Overwrite Signature. I have already Filtered this Signature based on the design of my network and as my 2 IPSs monitoring some of the common Network Segment (So having posibilities of duplicate packet).

But I dont know what to do with the following Alerts.

Source Add------------>Destination Add

Internal IP----------->0.0.0.0

External/Internet IP-->0.0.0.0

From some of my Internal IP to 0.0.0.0 and from some Internet IP to 0.0.0.0. I don understand whether I should filter it too or not.

Any suggestion or ideas or doc related to this would be much appreciable.

Regards

Adnan

dmease · ‎07-10-2008

The 0.0.0.0 alerts are summary alerts. If you have filtered out everything else, I would suggest filtering this also.

With regards to segment overwrite, when i looked into this in depth a while back, I had to set up another sniffer as the IPS device will only start recording on the 'bad' packet, meaning that the segment that was meant to be overwritten was not recorded. When looking through the captures from the sniffer, the only time I seen this alert fire was when a zero-length packet was sent (im assuming some kind of keepalive?). The packet after this caused the signature to fire, so it appears that the signature was firing when nothing was overwritten. Has anybody else seen this, and if not, has anybody actually got any captures that show that something was overwritten? We have the same issue with this signature and have been forced to filter it completely.

cheers,

AdnanShahid · ‎07-10-2008

Dear Dmease,

Can you tell what is the sniffing s/w did you use - so I can check on my network as well.

Also zero-length pkt can also cause the signature to be fired (along with overwritten pkt as well).

Thanks your information.

Adnan

support · ‎11-12-2008

Hi Adnan,

Sorry for delay - ive been on numerous projects. Just to confirm, I have never seen a zero length packet cause the signature to fire - it only fires on the packet after it (I found this by comparing captures from Wireshark on a host, and the captures from the sensor).

Can you tell me why the packet after the zero length packet is deemed to be overwriting the previous packet, as I cant see the possibility of overwriting something that isnt there?

cheers,