[asterisk-bugs] [Asterisk 0016226]: 1.4.26.3 security issue - Chinese IPs somehow are making calls without authentication

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16226 
====================================================================== 
Reported By:                faxguy
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16226
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.26.3 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-11-11 17:15 CST
Last Modified:              2009-11-12 00:10 CST
====================================================================== 
Summary:                    1.4.26.3 security issue - Chinese IPs somehow are
making calls without authentication
Description: 
This is from the CLI.  I don't know who 113.105.15.56 is, but for at least
a week now they've (that whole Class C network) been making calls out
through my Asterisk system without authentication.  I don't know how...

    -- Executing [011441616604001 at default:1]
Dial("SIP/113.105.152.56-08e4b3a8",
"IAX2/obfuscated-user:obfuscated-pass at voip-co2.teliax.com/011441616604001")
in new stack
    -- Called
obfuscated-user:obfuscated-pass at voip-co2.teliax.com/011441616604001
    -- Call accepted by 63.211.239.28 (format ulaw)
    -- Format for call is ulaw
    -- IAX2/63.211.239.28:4569-15287 is ringing
    -- IAX2/63.211.239.28:4569-15287 stopped sounds
    -- IAX2/63.211.239.28:4569-15287 answered SIP/113.105.152.56-08e4b3a8
    -- Hungup 'IAX2/63.211.239.28:4569-15287'
  == Spawn extension (default, 011441616604001, 1) exited non-zero on
'SIP/113.105.152.56-08e4b3a8'

To remedy this I have simply firewalled out their IP range.  But I'd like
to fix the problem with the SIP driver directly.
====================================================================== 

---------------------------------------------------------------------- 
 (0113699) faxguy (reporter) - 2009-11-12 00:10
 https://issues.asterisk.org/view.php?id=16226#c113699 
---------------------------------------------------------------------- 
qwell, I am not trying to imply in any way that there is no weakness in my
dialplan.  I'm just trying to report a bug.  I have now read
doc/security.txt, and while it's clear that I did not follow it in my
diaplan construction the document doesn't say that the "default" context in
the dialplan is intentionally available to the public.  The document
doesn't say *why* one should avoid using the "default" context for outbound
calls, I assume that it's only because the "default" context is easy to
guess its name.

I'm completely capable of reworking the dialplan to keep these rogue
callers from getting anywhere.  But what I'm concerned about, and what I'm
trying to report here is that there is a security vulnerability that's
allowing this to happen.

I understand that the information I've provided is insufficient to figure
out what is going on.  I've provided it as a mere illustration in case it
was a known issue or in case it was otherwise obvious to someone more
familiar with the inner-workings of the SIP channel driver.  Since it does
not seem to be a known issue, and since it is insufficient, please tell me
what I should do to give you adequate information.  How do I give you the
incoming channel and the SIP debug in an unattended way? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-11-12 00:10 faxguy         Note Added: 0113699                          
======================================================================