[Snort-devel] ssh preprocessor: incorrect event 'SSH_EVENT_PROTOMISMATCH'

Bram bram-fabeg at ...3414...
Thu Jul 11 12:20:12 EDT 2013


Hi,


The ssh preprocessor produces an incorrect event for  
'SSH_EVENT_PROTOMISMATCH' on some streams.
Attached is a cap file which can be used to trigger this.


snort configuration:

dynamicpreprocessor directory /usr/lib/snort_dynamicpreprocessor/
preprocessor stream5_global: track_tcp yes, \
    track_udp yes, \
    track_udp no, \
    track_icmp no, \
    max_tcp 262144, \
    max_udp 131072,
preprocessor stream5_tcp: policy first, ports client 21

preprocessor dcerpc2: memcap 102400, events [co ]
preprocessor ssh: server_ports { 22 2222 } \
                 enable_protomismatch


alert ( msg: "SSH_EVENT_PROTOMISMATCH"; sid: 4; gid: 128; rev: 1;  
metadata: rule-type preproc, service ssh ; )

output alert_fast: stdout


Running snort:

$ snort -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/ -r  
/tmp/port_2222_tmp.cap  2>&1  | grep -i protocol
     Protocol Aware Flushing: ACTIVE
     Protocol Mismatch Alert: ENABLED
Breakdown by protocol (includes rebuilt packets):
07/12-13:02:31.460723  [**] [128:4:1] (spp_ssh) Protocol mismatch [**]  
[Priority: 0] {TCP} 192.168.240.254:39360 -> 192.168.174.134:2222
07/12-13:02:31.486612  [**] [128:4:1] (spp_ssh) Protocol mismatch [**]  
[Priority: 0] {TCP} 192.168.240.254:39360 -> 192.168.174.134:2222
07/12-13:02:33.632790  [**] [128:4:1] (spp_ssh) Protocol mismatch [**]  
[Priority: 0] {TCP} 192.168.240.254:39360 -> 192.168.174.134:2222
07/12-13:02:33.635832  [**] [128:4:1] (spp_ssh) Protocol mismatch [**]  
[Priority: 0] {TCP} 192.168.240.254:39360 -> 192.168.174.134:2222
07/12-13:02:33.639342  [**] [128:4:1] (spp_ssh) Protocol mismatch [**]  
[Priority: 0] {TCP} 192.168.240.254:39360 -> 192.168.174.134:2222
07/12-13:02:34.860170  [**] [128:4:1] (spp_ssh) Protocol mismatch [**]  
[Priority: 0] {TCP} 192.168.240.254:39360 -> 192.168.174.134:2222
07/12-13:02:34.865636  [**] [128:4:1] (spp_ssh) Protocol mismatch [**]  
[Priority: 0] {TCP} 192.168.240.254:39360 -> 192.168.174.134:2222

Analysing this shows that the incorrect event is generated on packets  
after the client version string.

The problem appears to be in spp_ssh.c: ProcessSSH:

spp_ssh.c: 529:
         /* Make sure this preprocessor should run. */
         if (( !packetp ) ||
             ( !packetp->payload ) ||
             ( !packetp->payload_size ) ||
         ( !IPH_IS_VALID(packetp) ) ||
             ( !packetp->tcp_header ) ||
         /* check if we're waiting on stream reassembly */
         ( packetp->flags & FLAG_STREAM_INSERT))
         {
                 return;
         }

spp_ssh.c: 660:
                 if ( (sessp->state_flags & SSH_FLG_BOTH_IDSTRING_SEEN)
                         != SSH_FLG_BOTH_IDSTRING_SEEN )
                 {
                         if ( ProcessSSHProtocolVersionExchange( sessp,
                                         packetp, direction, known_port ) ==
                                 SSH_FAILURE )
                         {
                                 /*Error processing protovers exchange msg */
                         }


Checking it with gdb shows:

Breakpoint 1, ProcessSSH (ipacketp=0xbffff138, contextp=0x0) at spp_ssh.c:530
530     spp_ssh.c: No such file or directory.
(gdb) print packetp
$1 = (SFSnortPacket *) 0xbffff138
(gdb) print  packetp->flags
$2 = 16777304
(gdb) print  packetp->payload
$3 = (const uint8_t *) 0x902dd72 "SSH-1.99-OpenSSH_5.1p1 Debian-5\n"
(gdb) print packetp->flags & 0x00000010
$4 = 16


For the 'server version': the flag 'FLAG_STREAM_INSERT' is set in  
'packetp->flags' which means the code returns early and does not call  
'ProcessSSHProtocolVersionExchange'.
Because of this the 'SSH_FLG_SERV_IDSTRING_SEEN' flag is not set.

For the 'client version': the flag 'FLAG_STREAM_INSERT' is not set,  
'ProcessSSHProtocolVersionExchange' is called,  
'SSH_FLG_CLIENT_IDSTRING_SEEN' is string

For later packets: 'SSH_FLG_BOTH_IDSTRING_SEEN' is not set, the alert  
is generated.


It would appear that ProcesSSH expects to be called when the stream is  
'reassembled' but this never seen to happen.
Should it be called again?


Best regards,

Bram


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: port_2222_tmp.cap
Type: application/octet-stream
Size: 4091 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130711/08813861/attachment.obj>


More information about the Snort-devel mailing list