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

Victor Roemer vroemer at ...402...
Tue Jul 16 12:18:59 EDT 2013


Comments inline


On Mon, Jul 15, 2013 at 2:24 AM, Bram <bram-fabeg at ...3414...> wrote:

> 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.
>

Yep, here is the basic rundown

dcerpc2's auto-detection temporarily enable's reassembly on port 2222

1st data packet is queued for reassembly --  sets FLAG_STREAM_INSERT.

SSH checks FLAG_STREAM_INSERT -- skipping raw packet data that should be
received later as a rebuilt PDU.

dcerpc2 disables reassembly for that session

SSH never receives a rebuilt PDU



>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130716/153665b1/attachment.html>


More information about the Snort-devel mailing list