Sig 5237: HTTP Connect tunnel

[mhellman]

The regex for this sig is as follows (and can't be changed):

[Cc][Oo][Nn][Nn][Ee][Cc][Tt][ \t].*[:].*[ \t][Hh][Tt][Tt][Pp]

Why can't we make sure the port is specified in the regex to reduce false positives? Something like:

[Cc][Oo][Nn][Nn][Ee][Cc][Tt][ \t].*[:](0-9)+[ \t][Hh][Tt][Tt][Pp]

[jlimbo]

I will look into improving this signature. If you have any test samples or further information of packet data that contain cause false positives please let me know.

Thanks,

Jonathan

[mhellman]

Sure. Correct me if I'm wrong, but as is the signature will trigger if the strings

"connect " and ":" and "http" appear in a TCP stream on the WEBPORTS. In the case I investigated, it triggered on a backed connection to MS Outlook Web Access...what may have been an email from/to a developer. My thoughts are that if the "Connect tunnel" must always include a port (I honestly don't know the answer to that but it seems like a port would be required) then why can't we tighten up the regex as indicated?

[jlimbo]

We are looking into improving it to include the port but rather [0-9][0-9]?[0-9]?[0-9]?[0-9]? than [0-9]+ to make it more efficient. We however want to verify that this will not FP further so want to test it on some OWA traffic. Would it be possible to get some more information on this like a show event output of the packet?

[mhellman]

well, the problem is that we applied 5.0.6 to the sensor and the iplogs are no longer available. I'll see what I can come up with.

[mhellman]

I have to admit upfront that this is a contrived example, but I can't wait until this happens again...I'm too busy.

I created a word file (it is attached) with a somewhat realistic paragraph. I uploaded it to a web server. the signature fired. here is the alarm:

evIdsAlert: eventId=1136650237374068439 vendor=Cisco severity=low

originator:

hostId: 88-nsmc-c1

appName: sensorApp

appInstanceId: 349

time: March 29, 2006 3:12:44 PM UTC offset=-360 timeZone=GMT-06:00

signature: description=HTTP CONNECT Tunnel id=5237 version=S19

subsigId: 0

sigDetails: CONNECT.*HTTP/

interfaceGroup:

vlan: 0

participants:

attacker:

addr: 162.131.174.83 locality=INTERNAL

port: 2299

target:

addr: 162.131.88.12 locality=INTERNAL

port: 80

context:

fromAttacker:

000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 ...............D

000070 69 64 20 79 6F 75 20 74 72 79 20 74 6F 20 63 6F id you try to co

000080 6E 6E 65 63 74 20 74 6F 20 74 68 65 20 73 65 72 nnect to the ser

000090 76 65 72 3F 20 20 49 20 63 61 6E 20 6F 6E 6C 79 ver? I can only

0000A0 20 74 68 69 6E 6B 20 6F 66 20 32 20 74 68 69 6E think of 2 thin

0000B0 67 73 20 74 68 61 74 20 77 6F 75 6C 64 20 68 61 gs that would ha

0000C0 76 65 20 70 72 65 76 65 6E 74 65 64 20 79 6F 75 ve prevented you

0000D0 20 66 72 6F 6D 20 73 75 63 63 65 73 73 66 75 6C from successful

0000E0 6C 79 20 63 6F 6E 6E 65 63 74 69 6E 67 3A 0D 61 ly connecting:.a

0000F0 20 66 69 72 65 77 61 6C 6C 0D 61 6E 20 68 74 74 firewall.an htt

riskRatingValue: 37

interface: ge0_0

protocol: tcp

[mhellman]

I can email you an iplog directory if you want one.

[rupadras]

The alarm you pasted above was helpful. I can generate the test traffic based on that. We will modify the signature soon. Thank you for your response.

Radhika