This rule is subject to false positives. The description makes it clear
that the exploit only works on ssh version 1, yet it triggers on version 2
traffic as well.
"This event is generated when an attempt is made to exploit a known
vulnerability in implementations of Secure Shell (ssh) version 1."
However, under affected systems, the rule states:
"Cisco IOS 12.0S
Cisco IOS 12.1xx-12.2xx
SSH Communications Security SSH 2.x and 3.x
SSH Communications Security SSH 1.2.23-1.2.31
F-Secure SSH versions prior to 1.3.11-2
OpenSSH versions prior to 2.3.0"
Hmm....so version 2 is affected? Or not?
Here's the rule:
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"EXPLOIT ssh CRC32
overflow filler"; flow:to_server,established; content:"|00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00|"; reference:bugtraq,2347;
reference:cve,2001-0144; reference:cve,2001-0572;
classtype:shellcode-detect; sid:1325; rev:6; )
Here's a legitimate packet from a ssh version 2 session between a Putty
client and a FreeBSD server running OpenSSH 4.2pl ( ssh -V
OpenSSH_4.2p1 FreeBSD-20060930, OpenSSL 0.9.7e-p1 25 Oct 2004):
0000 00 00 0c 07 ac 01 00 11 43 bd b8 52 08 00 45 00 ........C..R..E.
0010 02 fc 18 8f 40 00 40 06 00 00 81 6e 03 1c 42 dd ....@.@....n..B.
0020 65 f8 fb c0 00 16 a2 3c 4c 4e 5b 25 32 df 80 18 e......<LN[%2...
0030 80 bc 30 4e 00 00 01 01 08 0a 29 14 2b 61 2f 20 ..0N......).+a/
0040 a5 af 00 00 02 c4 05 14 3a 39 56 af ca 62 c9 78 ........:9V..b.x
0050 c3 d5 a3 8c 37 96 13 ff 00 00 00 59 64 69 66 66 ....7......Ydiff
0060 69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70 ie-hellman-group
0070 2d 65 78 63 68 61 6e 67 65 2d 73 68 61 31 2c 64 -exchange-sha1,d
0080 69 66 66 69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 iffie-hellman-gr
0090 6f 75 70 31 34 2d 73 68 61 31 2c 64 69 66 66 69 oup14-sha1,diffi
00a0 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70 31 e-hellman-group1
00b0 2d 73 68 61 31 00 00 00 0f 73 73 68 2d 64 73 73 -sha1....ssh-dss
00c0 2c 73 73 68 2d 72 73 61 00 00 00 9d 61 65 73 31 ,ssh-rsa....aes1
00d0 32 38 2d 63 62 63 2c 33 64 65 73 2d 63 62 63 2c 28-cbc,3des-cbc,
00e0 62 6c 6f 77 66 69 73 68 2d 63 62 63 2c 63 61 73 blowfish-cbc,cas
00f0 74 31 32 38 2d 63 62 63 2c 61 72 63 66 6f 75 72 t128-cbc,arcfour
0100 31 32 38 2c 61 72 63 66 6f 75 72 32 35 36 2c 61 128,arcfour256,a
0110 72 63 66 6f 75 72 2c 61 65 73 31 39 32 2d 63 62 rcfour,aes192-cb
0120 63 2c 61 65 73 32 35 36 2d 63 62 63 2c 72 69 6a c,aes256-cbc,rij
0130 6e 64 61 65 6c 2d 63 62 63 40 6c 79 73 61 74 6f ndael-cbc@lysato
0140 72 2e 6c 69 75 2e 73 65 2c 61 65 73 31 32 38 2d r.liu.se,aes128-
0150 63 74 72 2c 61 65 73 31 39 32 2d 63 74 72 2c 61 ctr,aes192-ctr,a
0160 65 73 32 35 36 2d 63 74 72 00 00 00 9d 61 65 73 es256-ctr....aes
0170 31 32 38 2d 63 62 63 2c 33 64 65 73 2d 63 62 63 128-cbc,3des-cbc
0180 2c 62 6c 6f 77 66 69 73 68 2d 63 62 63 2c 63 61 ,blowfish-cbc,ca
0190 73 74 31 32 38 2d 63 62 63 2c 61 72 63 66 6f 75 st128-cbc,arcfou
01a0 72 31 32 38 2c 61 72 63 66 6f 75 72 32 35 36 2c r128,arcfour256,
01b0 61 72 63 66 6f 75 72 2c 61 65 73 31 39 32 2d 63 arcfour,aes192-c
01c0 62 63 2c 61 65 73 32 35 36 2d 63 62 63 2c 72 69 bc,aes256-cbc,ri
01d0 6a 6e 64 61 65 6c 2d 63 62 63 40 6c 79 73 61 74 jndael-cbc@lysat
01e0 6f 72 2e 6c 69 75 2e 73 65 2c 61 65 73 31 32 38 or.liu.se,aes128
01f0 2d 63 74 72 2c 61 65 73 31 39 32 2d 63 74 72 2c -ctr,aes192-ctr,
0200 61 65 73 32 35 36 2d 63 74 72 00 00 00 55 68 6d aes256-ctr...Uhm
0210 61 63 2d 6d 64 35 2c 68 6d 61 63 2d 73 68 61 31 ac-md5,hmac-sha1
0220 2c 68 6d 61 63 2d 72 69 70 65 6d 64 31 36 30 2c ,hmac-ripemd160,
0230 68 6d 61 63 2d 72 69 70 65 6d 64 31 36 30 40 6f hmac-ripemd160@o
0240 70 65 6e 73 73 68 2e 63 6f 6d 2c 68 6d 61 63 2d penssh.com,hmac-
0250 73 68 61 31 2d 39 36 2c 68 6d 61 63 2d 6d 64 35 sha1-96,hmac-md5
0260 2d 39 36 00 00 00 55 68 6d 61 63 2d 6d 64 35 2c -96...Uhmac-md5,
0270 68 6d 61 63 2d 73 68 61 31 2c 68 6d 61 63 2d 72 hmac-sha1,hmac-r
0280 69 70 65 6d 64 31 36 30 2c 68 6d 61 63 2d 72 69 ipemd160,hmac-ri
0290 70 65 6d 64 31 36 30 40 6f 70 65 6e 73 73 68 2e pemd160@openssh.
02a0 63 6f 6d 2c 68 6d 61 63 2d 73 68 61 31 2d 39 36 com,hmac-sha1-96
02b0 2c 68 6d 61 63 2d 6d 64 35 2d 39 36 00 00 00 1a ,hmac-md5-96....
02c0 6e 6f 6e 65 2c 7a 6c 69 62 40 6f 70 65 6e 73 73 none,zlib@openss
02d0 68 2e 63 6f 6d 2c 7a 6c 69 62 00 00 00 1a 6e 6f h.com,zlib....no
02e0 6e 65 2c 7a 6c 69 62 40 6f 70 65 6e 73 73 68 2e ne,zlib@openssh.
02f0 63 6f 6d 2c 7a 6c 69 62 00 00 00 00 00 00 00 00 com,zlib........
0300 00 00 00 00 00 00 00 00 00 00 ..........
Clearly the rule is triggered because of the padding, which follows the
payload, both of which use |00| as "filler" meaning "null". But what does
that have to do with the CRC32 checksum attack? And shouldn't you be able
to strip off the padding when detecting? Or does the padding become part
of the problem?
According to Bugtraq, the problem lies in a 32 bit representation of the
ssh packet length being assigned to a 16 bit integer. I don't see how you
could possibly detect that in the packets since the improper assignment
would occur inside the binary after the packet has been received.
It seems like this rule is ripe for some sort of byte_jump,byte_test
shenanigans.
Or at least a content match for ssh type: content:"ssh"; nocase; within 2;
pcre:"/[12]\."; within 5; pcre:"/[12]";
--
Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
p7srVEogyOQMO.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
