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

Bram bram-fabeg at ...3414...
Mon Jul 15 02:24:36 EDT 2013


Hi,


Testing further shows that there appears to be a link between the  
problem and the 'dcerpc2' preprocessor.


When the configuration is appended with:
    preprocessor dcerpc2_server: default, autodetect [tcp 2222 ]
then the event is generated

When the configuration is appended with
    preprocessor dcerpc2_server: default, autodetect [tcp 2221 ]
then the event is not generate.

Just for reference: default config of dcerpc2_server:
   preprocessor dcerpc2_server: default, policy WinXP, \
       detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \
       autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \
       smb_max_chain 3, smb_invalid_shares ["C$", "D$", "ADMIN$"]


Best regards,

Bram


Quoting Victor Roemer <vroemer at ...402...>:

> Bram,
>
> Thank you for your bug submission. I have reproduced your scenario and
> opened a bug so that we can address the problem.
>
> In the mean time, enabling TCP reassembly on port 2222 would resolve the
> problem.
>
>
> Thanks,
> Victor
>
>
> On Thu, Jul 11, 2013 at 12:20 PM, Bram <bram-fabeg at ...3414...> wrote:
>
>> 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 ( ProcessSSHProtocolVersionExcha**nge( 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 '**
>> ProcessSSHProtocolVersionExcha**nge'.
>> 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, '**
>> ProcessSSHProtocolVersionExcha**nge' 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.





More information about the Snort-devel mailing list