[Snort-devel] SIP preprocessor: false positives on DNS traffic

Bram bram-fabeg at ...3414...
Fri Aug 16 08:56:56 EDT 2013


Hi,


It appears that the SIP preprocessor generates alerts on DNS traffic  
which happens to be using port 5060, 5061 or 5600.

Attached is a capture file which consist of a dns query.
The dns query happens to be using source port 5060 (randomly chosen).

On the dns response the alert 'SIP_EVENT_EMPTY_REQUEST_URI' is generated.


Config:
	dynamicpreprocessor directory /usr/lib/snort_dynamicpreprocessor/
	preprocessor stream5_global: track_tcp yes, \
	   track_udp yes, \
	   track_icmp no

	preprocessor stream5_tcp: ports both 53
	preprocessor stream5_udp: timeout 180

	preprocessor dns: ports { 53 } enable_rdata_overflow
	preprocessor sip: max_sessions 10000, \
	   ports { 5060 5061 5600 }, \
	   methods { invite \
	             cancel \
	             ack \
	             bye \
	             register \
	             options \
	             refer \
	             subscribe \
	             update \
	             join \
	             info \
	             message \
	             notify \
	             benotify \
	             do \
	             qauth \
	             sprack \
	             publish \
	             service \
	             unsubscribe \
	             prack }, \
	   max_uri_len 512, \
	   max_call_id_len 256, \
	   max_requestName_len 20, \
	   max_from_len 256, \
	   max_to_len 256, \
	   max_via_len 1024, \
	   max_contact_len 512, \
	   max_content_len 2048

	alert ( msg: "SIP_EVENT_EMPTY_REQUEST_URI"; sid: 2; gid: 140; rev: 1;  
metadata: rule-type preproc ; )

	output alert_fast: stdout

Running it:
	$ snort -v -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/ -r  
/tmp/140_2_1.cap 2>&1   | grep '140:'
	07/28-21:40:12.713181  [**] [140:2:1] (spp_sip) Empty request URI  
[**] [Priority: 0] {UDP} 192.48.79.30:53 -> 10.10.1.1:5060

Looking in the code: ./src/dynamic-preprocessors/sip/sip_parser.c:  
'sip_startline_parse' shows:

When the packet starts with 'SIP/' then it is assumed to be a SIP Response.
If this is the case then it will check the version and if the version  
is invalid it generates the alert 'SIP_EVENT_INVALID_VERSION'
It then proceeds to check the status code. If no status code is found  
no alert is generated (judging by the code)
If a status code is found and invalid then the alert  
'SIP_EVENT_BAD_STATUS_CODE' is generated.

When the packet does not start with 'SIP/' it assumes this is a request.
It first looks for the method, and then extracts the URI.
When the URI is empty the alert 'SIP_EVENT_EMPTY_REQUEST_URI' is generated.
When the URI is longer than 'maxUriLen' then the alert  
'SIP_EVENT_BAD_URI' is generated.
It then proceeds to check if 'SIP/' with a version number is found.

This can (and does) results in false positive...

I'm not sure what the proper fix for this is..
Checking the 'SIP/' keyword before generating the 'SIP_EVENT_BAD_URI'  
alert will break the alert (it was added for CVE-2007-1306 which is a  
SIP request without SIP keyword/version).
It should probably check if this is a DNS request/response but I'm not  
sure that is proper fix...


Best regards,

Bram


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 140_2_1.cap
Type: application/octet-stream
Size: 534 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130816/65af2add/attachment.obj>


More information about the Snort-devel mailing list