[asterisk-bugs] [Asterisk 0018051]: SIP brute force attemps having a DoS effect

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18051 
====================================================================== 
Reported By:                eeman
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18051
Category:                   Channels/chan_sip/General
Reproducibility:            have not tried
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
JIRA:                       SWP-2343 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-09-24 19:00 CDT
Last Modified:              2010-12-09 15:56 CST
====================================================================== 
Summary:                    SIP brute force attemps having a DoS effect
Description: 
We've all seen the brute force attempts where a script blasts asterisk with
thousands of attempts to learn valid accounts

example:
[Sep 24 15:46:51] NOTICE[19686] chan_sip.c: Registration from
'"9941"<sip:9941 at 1.2.3.4>' failed for '81.31.148.109' - No matching peer
found
[Sep 24 15:46:51] NOTICE[19686] chan_sip.c: Registration from
'"9942"<sip:9942 at 1.2.3.4>' failed for '81.31.148.109' - No matching peer
found
[Sep 24 15:46:51] NOTICE[19686] chan_sip.c: Registration from
'"9943"<sip:9943 at 1.2.3.4>' failed for '81.31.148.109' - No matching peer
found
[Sep 24 15:46:51] NOTICE[19686] chan_sip.c: Registration from
'"9944"<sip:9944 at 1.2.3.4>' failed for '81.31.148.109' - No matching peer
found

this seems to be having a second effect of creating a DoS attack on
inbound calls. It seems that the instigating attacker's IP finds its way
into legitimate SIP messages as the Contact: url. The result is the ACK
messages to the corresponding 200 messages are sent instead to this IP.
Observe the Contact header in this simple ACK message (i sanitized the IP
addresses except for the script running ass; he can get his own DoS from
this post for all i care):

rUJy`\=EX+U.HFE at SIP/2.0 200 OK
Via: SIP/2.0/UDP
4.3.2.1:5060;branch=z9hG4bK78126bc7;received=4.3.2.1;rport=5060
From: "BLUEGRASSNET" <sip:+18598064913 at 4.3.2.1>;tag=as684e24f7
To: <sip:+18129442733 at 1.2.3.4>;tag=as52fe0a2e
Call-ID: 4544269969f074577549d403673538de at 4.3.2.1
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:+18129442733 at 81.31.148.109>
Content-Type: application/sdp
Content-Length: 211

v=0
o=root 19653 19653 IN IP4 1.2.3.4
s=session
c=IN IP4 1.2.3.4
t=0 0
m=audio 14936 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

as a result the ACK messages and BYE messages get sent to an IP
81.31.148.109 in the RIPE number space. 
====================================================================== 

---------------------------------------------------------------------- 
 (0129514) twilson (administrator) - 2010-12-09 15:56
 https://issues.asterisk.org/view.php?id=18051#c129514 
---------------------------------------------------------------------- 
Since the only way I can see this happening is if you have to have
knowledge of (or somehow astronomically manage to duplicate, which still
wouldn't do it if pedantic=yes is set) the Call-ID, I'm not considering
this a security issue. For one thing, there are tons of things you can do
to mess things up if you aren't using secure signaling and someone can
insert valid looking packets. I am committing a patch that should fix this
particular problem, though. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-12-09 15:56 twilson        Note Added: 0129514                          
======================================================================