Custom sig: Non-SSL over SSL port

[mhellman]

I am trying to build a custom signature for detecting non-SSL traffic on a specific SSL port (let's say tcp/443). This has to do with CONNECT tunnels through an HTTP proxy. Conceptually, it's not a complicated idea. Whether or not it can technically be done effectively with the Cisco IPS I don't know.

It seems that very early in every SSL connection, there is an SSL "client hello" message(SYN,SYN/ACK,ACK,CLIENT HELLO). There are two relevant record formats, SSLv2 and SSLv2/TLS. I would like to create a signature that fires when it DOES NOT see the client hello message very early in a given TCP session. I would want the signature to only need to check the very first n packets of any given TCP session (n = max size of connection establishment + max size of client hello packet). Has anyone created such a beast or willing to help? Here are a couple packets.

SSLv3 Client Hello

0000 00 00 5e 00 01 67 00 a0 8e 82 ec 5d 08 00 45 00 ..^..g.....]..E.

0010 00 8e 33 b8 40 00 3e 06 94 16 ce c3 c3 6c 40 22 ..3.@.>......l@"

0020 a2 49 58 27 01 bb b7 42 c6 92 fd 36 a3 d1 50 18 .IX'...B...6..P.

0030 44 70 08 e2 00 00 16 03 00 00 61 01 00 00 5d 03 Dp........a...].

0040 00 44 5f 9a 77 69 49 5a 85 52 a0 96 38 b3 b4 15 .D_.wiIZ.R..8...

0050 8f db f2 0f c9 0e ea 10 f5 69 39 8c 58 87 e5 33 .........i9.X..3

0060 70 20 ba 06 1e 3f d4 4e 3c d0 de a8 ea 4e a3 7f p ...?.N<....N..

0070 0f 07 fd 5f 88 07 17 ef 50 ce 6b cf 10 e3 84 99 ..._....P.k.....

0080 04 a2 00 16 00 04 00 05 00 0a 00 09 00 64 00 62 .............d.b

0090 00 03 00 06 00 13 00 12 00 63 01 00 .........c..

TLSv1 Client Hello

0000 00 0f 20 6c 99 8b 00 a0 8e 82 c4 c1 08 00 45 00 .. l..........E.

0010 00 96 a2 89 40 00 7f 06 32 b3 ce c3 c2 29 ce c3 ....@...2....)..

0020 c6 74 0d 13 01 bb 38 17 d5 89 98 0f fc 73 50 18 .t....8......sP.

0030 44 70 6c 75 00 00 16 03 01 00 69 01 00 00 65 03 Dplu......i...e.

0040 01 44 5f 9a 84 8a 94 ab f3 78 e7 b1 c9 ca 04 34 .D_......x.....4

0050 3b 95 1b 86 51 05 5f ac 9d a0 b0 69 fe 0c 27 e5 ;...Q._....i..'.

0060 9c 20 78 08 00 00 ce c3 c2 29 58 58 58 58 58 58 . x......)XXXXXX

0070 58 58 58 58 58 58 58 58 58 58 48 9a 5f 44 8c 4b XXXXXXXXXXH._D.K

0080 05 00 00 1e 00 04 00 05 00 2f 00 33 00 32 00 0a ........./.3.2..

0090 00 16 00 13 00 09 00 15 00 12 00 03 00 08 00 14 ................

00a0 00 11 01 00 ....

SSLv2 Client Hello

0000 00 00 5e 00 01 67 00 a0 8e 82 ec 5d 08 00 45 00 ..^..g.....]..E.

0010 00 82 fb a7 40 00 3e 06 cf 32 ce c3 c3 6c 9f 35 ....@.>..2...l.5

0020 40 36 58 6d 01 bb b7 78 06 1b cd e2 e2 3d 80 18 @6Xm...x.....=..

0030 44 70 47 6b 00 00 01 01 08 0a 31 fd f9 51 00 00 DpGk......1..Q..

0040 00 00 80 4c 01 03 00 00 33 00 00 00 10 00 00 04 ...L....3.......

0050 00 00 05 00 00 0a 01 00 80 07 00 c0 03 00 80 00 ................

0060 00 09 06 00 40 00 00 64 00 00 62 00 00 03 00 00 ....@..d..b.....

0070 06 02 00 80 04 00 80 00 00 13 00 00 12 00 00 63 ...............c

0080 7b af 57 75 f8 a9 72 54 23 29 32 50 bf ef 1e a9 {.Wu..rT#)2P....

[a.giorgi]

Hi mhellman:

I can see 3 difficulties with this kind of sign.

1) To determine the order of the packets.

2) To determine that happen at the very begining of the conection

3) fire when the traffic doesn't match with the signature.

The difficulty number 3, I think, is imposible to resolve because the sensor can compare the trafic with a well defined pattern and fire when it match, but not when it doen't.

The difficult number 2

You need a kind of state signature because this can be classified like a machine state (first three way handshake, then hello packet) but I can't see fields in the state engine that help in this case.

The difficult number 1 could be resolved by a Meta signature.

You will need to create an a custom atomic signature for the syn packet, another for the syn ack, another to ack, and the last one for hellow packet.

Then create a meta signature and add the fourth atomic singatures whith a strict order.

but guess what...

Meta signature doesn't permit custom signatures.

I think this kind of signature is imposible to write.

But I'd try.

Regards

Alberto Giorgi from spain.

[mhellman]

Thanks for your thoughts.

>>1) To determine the order of the packets.

I hadn't really thought of that, but I expect my IPS to do that anyway;-) I'm no TCP or SSL expert, but I don't see how during the "SSL handshake" process packets could get out of order. Every step seems to have a dependency on the previous. After the handshake is done, all bets are off.

>>2) To determine that happen at the very begining of the conection

I don't know what to call it. It just seems like something a modern IPS ought to be able to do. Maybe none of them can though? I'm looking into how this might be done with Snort at the moment.

>>3) fire when the traffic doesn't match with the signature.

that's not exactly what I'm trying to do. I'm trying to create a signature that looks for traffic that does not match a specific regular expression pattern. For example, to "alert" on all lines in /etc/password that don't start with r:

grep -P ^[^r] /etc/passwd

[a.giorgi]

Please don´t get me wrong.

I'm trying to say I think it's imposible to make a signature in the Cisco IPS to fire what you want because the difficulties I mention.

I think your idea is perfect.

Every IDS would have to detect this kind of behavior.

I mean if the sensor (o firewall) has the capability to permit only 3 way handshake tcp conections (a well know traffic) you prevent a lot of attack like fin sweeps or xmas attacks (at least in the very begining of the conection) and save a lot of signature to detect abnormal trafic.

I think it would not be complicated. You only need to make a Meta signature with atomic signatures like syn,syn-ack,ack, and hello packet and permit to fire if the trafic doesn't match.

Perhaps Cisco will add this feature in a next version :)

Anybody agree with me?

Regards.

Alberto Giorgi from Spain