Summary:ASTERISK-11245: [authenticaion] in sip.conf: A malicius "Contact" header in REGISTER can get free calls through SIP provider
Reporter:Iñaki Baz Castillo (ibc)Labels:
Date Opened:2008-01-16 05:57:39.000-0600Date Closed:2008-09-12 15:27:58
Versions:Frequency of
Environment:Attachments:( 0) 20080721__bug11776.diff.txt
( 1) 20080728__bug11776.diff.txt
( 2) 20080829__bug11776.diff.txt
Description:Hi, a malicius "Contact" header can be very damaged as I explain in the following example:

Suppose our Asterisk has configured a SIP provider "sip_provider" with "realm=sip_provider.com" and a SIP local phone "2001" who is not allowed to do calls through "sip_provider":

auth = client_number:client_password@sip_provider.com

type = peer
host = sip_provider.com

[2001] ; local phone
type = friend
secret = 1234
context = from_phone

; Just allow to do test calls
exten => 500,1,Echo
exten => 501,1,PlayBack(demo-congrats)
exten => _200X,1,Dial(SIP/${EXTEN}) ; call to himself and other local phones

Note that for the "sip_provider", instead of using "secret" and "username" in the peer definition we have defined an "auth" in [autheticacion] section. AFAIK this is perfectly valid.

Note too that "phone" is just allowed to call 500, 501 and 200X (so calling to 2001 he would call himself).

Now because the owner of 2001 phone is angry he decides to hack the enterprise PBX by doing it:

 sipsak -U -C "sip:0034999000111@sip_provider.com:5060" -a "1234" -s sip:2001@asterisk_ip

This will cause a malicious registration in Asterisk for the AoR "sip:2001@asterisk_ip".

Now this person calls to himself by calling to 2001 extension:

- Asterisk then by the execution of dialplan will do:

- This will cause an INVITE to the sip_provider and replies like:

* asterisk_ip -> sip_provider.com
INVITE sip:0034999000111@sip_provider.com:5060 SIP/2.0
From: "asterisk" <sip:asterisk@asterisk_ip>
To: <sip:0034999000111@sip_provider.com:5060>

* sip_provider.com -> asterisk_ip
SIP/2.0 407 Proxy Authentication Required
Proxy-Authenticate: Digest algorithm=MD5, realm="sip_provider.com", nonce="1748d3"

* asterisk_ip -> sip_provider.com
INVITE sip:0034999000111@sip_provider.com:5060 SIP/2.0
From: "asterisk" <sip:asterisk@asterisk_ip>
To: <sip:0034999000111@sip_provider.com:5060>
Proxy-Authorization: Digest username="client_number", realm="sip_provider.com", algorithm=MD5, uri="sip:0034999000111@sip_provider.com:5060", nonce="1748d3", response="70d491d8998a961dc"

* sip_provider.com -> asterisk_ip
183 Session Progress

ooohhhhhh !!!

So the malicious user has made a PSTN call by free!


For now, the only way I can imagine to avoid it is not using [authentication] section in sip.conf, and set always "username" and "secret" in peer configuration.

So maybe this is not a bug but a potential danger anyway.
Comments:By: Olle Johansson (oej) 2008-01-16 06:53:29.000-0600

This is surely an interesting case. Adding the auth headers to the sip_provider peer would fix the issue. The main question here is how we can apply ACLs to Contact: headers that people register with us. That's something that we don't do.

Any other SIP location servers out there that filter Contact: headers?

By: Olle Johansson (oej) 2008-01-16 06:53:57.000-0600

And this is not a bug, just an insecure configuration.

By: Iñaki Baz Castillo (ibc) 2008-01-16 07:06:03.000-0600

Yes, I agree that this it's not a bug, but a insecure configuration. Maybe this could be advised in doc.

About filtering "Contact", I started a thread in Openser maillist[1] in which some people recognized filtering "Contact" containing domain names. Other solution is to filter "Contact" containing usernames starting by "aa" (for example) and when routing calls to gateways prefix de URI with "aa" (so the gateway knows it and must take it off).

[1] http://lists.openser.org/pipermail/users/2007-December/014853.html

By: Olle Johansson (oej) 2008-01-16 07:13:35.000-0600

Thanks for the reference to the discussion on OpenSER. I missed that.

I need to brainstorm a bit with myself and collegues here.

By: Olle Johansson (oej) 2008-03-26 07:32:09

If we tried to match the Contact URI (after resolving it to IP) to the ACL, we could use the ACLs (permit/deny) to limit the range. You could then implement an ACL that restricts the user from using any known serviceprovider's IP address.

Would that be a way to fix this?

By: Iñaki Baz Castillo (ibc) 2008-03-26 07:55:06

Note that then Asterisk should match the Contact URI and resolve it to IP for each call to that AoR since a domain can be altered in the time (a malicious user could send a REGISTER with "Contact: mydomain.com" and in that moment "mydomain.com" resolvs to, but later it can modify the DNS and point to a provider).

In OpenSer there is a nice way to handle it: blacklists.
- You set a blacklist with providers IP.
- By default the blacklist is active.
- When OpenSer must do a call it resolves the destination IP and if the IP is blacklisted it denies the call.
- When the proxy explicitely wants to route a call to a blacklisted ip (a provider) it deactivates blacklist for that call.

I don't know how it could be implemented in Asterisk, maybe a parameter in sip.conf:

 blacklist =,

and a new parameter "dissable_blacklist" for peers . If it's set then it dissables the blacklist when a call is made throught that peer:

 host = sip.sip_provider.com  ; resolvs to
 type = peer
 dissable_blacklist = true

So then, a INVITE is only allowed to if the Dial is like:

PD: Note also that in OpenSer there can be more than one blacklist referred each one by a id or name.

By: Olle Johansson (oej) 2008-03-26 08:15:38

So in general, it seems like you think that using the ACL would be a good idea, with the extra benefit of actually adding a new ACL for blacklisting. That seems very doable.

By: Sergey Tamkovich (sergee) 2008-03-26 08:38:08

I would like to see ACLs as a separate entity in asterisk (not depending on chan_sip or anything else). E.g. in separate file (may be acl.conf) - there would be a number of named lists. With such approach we could use them not only for solving this particular issue, but also for replacing all permit/deny set with centralized collection of ACLs...

By: Olle Johansson (oej) 2008-03-26 08:47:36

That's an interesting idea too. Should not be too hard to implement that either.

By: Sergey Tamkovich (sergee) 2008-03-26 08:55:47

i'm keeping it more then 6 months already, unfortunately i'm stuck with h323 bugs and didn't have time to implement cisco-style ACLs yet.

By: Tilghman Lesher (tilghman) 2008-07-21 17:58:45

Patch uploaded, that implements this with "contactpermit" and "contactdeny" elements.

By: Olle Johansson (oej) 2008-07-22 01:59:51

Cool stuff. I think we could benefit from having a global setting as well.

I've been thinking about adding "named ACLs". First defining an ACL in the general section, then being able to refer to it in many places - or maybe a separate configuration file. Then we only need to define it once and have it in memory once, and can refer to it in many places.

Thanks for coding this!

By: Tilghman Lesher (tilghman) 2008-07-22 08:37:33

oej:  why not just use the existing template system within the config file format?

By: Olle Johansson (oej) 2008-07-22 10:14:22

We would still have multiple in-memory ACL lists.

It would be nice if you could have one in-memory list used for 1500 peers.

By: Tilghman Lesher (tilghman) 2008-07-28 16:29:04

Okay, new patch uploaded that implements both types of lists.  Also implemented a single setting which will disallow dynamic registrations from any peer for which a peer exists with a static address (usually SIP providers).

By: Leif Madsen (lmadsen) 2008-08-18 17:12:24

I'm trying to reproduce this, but for some reason I'm getting an error using sipsak 0.9.6 when trying to use the line as provided:

sipsak -U -C sip:11776@ -a 1234 -s sip:2001@
warning: ignoring -i option when in usrloc mode

Anyone seen that before? is the "sip provider", and is the local Asterisk server.

By: Iñaki Baz Castillo (ibc) 2008-08-19 03:38:27

Don't worry, it occurs the same to me (some sipsak internal issue or warning).
But the registration *is* done, don't you see it in Asterisk?

By: Leif Madsen (lmadsen) 2008-08-19 07:42:52

Well that's the thing, I have only been able to get it to actually send the registration one time. Every other time it just ended up not sending anything. At the suggestion of Mark Michelson, I added the -E UDP to the end, and that seemed to work the very first time, but after that, I couldn't get sipsak to send anything.

I even did a tshark trace locally to see if it just wasn't getting to the other end, but nothing seemed to be generated.

After I did generate the first time though, and placed the call, I was able to place a call through the "service provider", so I can at least confirm this bug exists. I'm still trying to get sipsak to consistantly work so I can test the patch.

What version of sipsak are you using? I'm on CentOS 5.x with latest updates in a VMware virtual machine with bridged networking. Never seemed to have a problem with that setup before. Perhaps I'll give the SVN checkout a try. Using 0.9.6 right now...

By: Iñaki Baz Castillo (ibc) 2008-08-19 08:10:39

I use SipSak 0.9.6-1.1build1 in Ubuntu 8.04.
I haven't used it too much, but never seen your problem.

By: Leif Madsen (lmadsen) 2008-08-27 09:50:54

Update! I can reproduce reliably now. Will let you know how the patch testing goes.

By: Leif Madsen (lmadsen) 2008-08-27 10:08:23

OK, this is looking good so far, will try a couple more tests and see if I can break it and get around it.

*CLI> [Aug 27 07:15:05] WARNING[17040]: chan_sip.c:8260 parse_register_contact: Host '' disallowed by rule
[Aug 27 07:15:05] WARNING[17040]: chan_sip.c:8784 register_verify: Failed to parse contact info

[root@localhost ~]# sipsak -E UDP -U -C "sip:11776@" -a "1234" -s sip:2001@
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP;branch=z9hG4bK.03cd3d33;alias;received=;rport=32778
From: sip:2001@;tag=7431c7ed
To: sip:2001@;tag=as34af6227
Call-ID: 1949419501@
User-Agent: Asterisk PBX
Supported: replaces
Date: Wed, 27 Aug 2008 11:15:05 GMT
Content-Length: 0

error: didn't received '200 OK' on register (see above). aborting



Seems this is a bit TOO restrictive... perhaps I am doing something wrong, but I have changed the contactpermit to be fairly open now, with:


And I still get the rejection. I also tried specifically using:


Which is the IP address of the phone that I want to permit registration.

Maybe I'm doing something wrong here? It seems to reject all IPs even when you have a contactpermit line.

By: Iñaki Baz Castillo (ibc) 2008-08-27 10:18:20

I think the response should be "403 Forbidden" rather than "400 Bad request".

Can you try with?:

sipsak -E UDP -U -C "sip:11776@" -a "1234" -s
Note the "05" instead of "5".

By: Leif Madsen (lmadsen) 2008-08-27 10:55:03


My sipsak didn't like me using that interface -- it wanted to route over the interface. I'm guessing you want me to test the .05 to see whether the contactdeny will pick that up?

By: Iñaki Baz Castillo (ibc) 2008-08-27 11:07:11

yes yes, use any IP you can use in your network enviroment. I just wanted to try the case in which you add a useless 0 into the IP.

By: Tilghman Lesher (tilghman) 2008-08-29 10:23:50

Okay, new patch uploaded.

By: Leif Madsen (lmadsen) 2008-09-12 13:34:16

OK, from what I can tell this is all working now!

[Sep 12 10:34:00] WARNING[4158]: chan_sip.c:8276 parse_register_contact: Host '' disallowed by rule
[Sep 12 10:34:00] WARNING[4158]: chan_sip.c:8800 register_verify: Failed to parse contact info
   -- Registered SIP '2001' at port 57664 expires 3600
[Sep 12 10:34:10] NOTICE[4158]: chan_sip.c:15473 handle_request_subscribe: Received SIP subscribe for peer without mailbox: 2001
   -- Executing [2001@bug11776:1] Dial("SIP/2001-120964e0", "SIP/2001") in new stack
   -- Called 2001
   -- SIP/2001-120a01b0 is ringing
 == Spawn extension (bug11776, 2001, 1) exited non-zero on 'SIP/2001-120964e0'


dynamic_exclude_static = yes   ; Disallow all dynamic hosts from registering
                               ; as any IP address used for staticly defined
                               ; hosts.  This helps avoid the configuration
                               ; error of allowing your users to register at
                               ; the same address as a SIP provider.

contactdeny=           ; Use contactpermit and contactdeny to
contactpermit=  ; restrict at what IPs your users may
                                      ; register their phones.

So I restricted chan_sip to only allow my softphone from my laptop to register. When I tried to perform the register to forward the call to (my 'service provider' I ended up with the denial message.

Calls worked as expected when I registered with the softphone from the allowed IP address.

So from what I can tell, this is all working now!

By: Digium Subversion (svnbot) 2008-09-12 15:27:55

Repository: asterisk
Revision: 142865

U   branches/1.4/channels/chan_sip.c
U   branches/1.4/configs/sip.conf.sample

r142865 | tilghman | 2008-09-12 15:27:54 -0500 (Fri, 12 Sep 2008) | 11 lines

Create rules for disallowing contacts at certain addresses, which may
improve the security of various installations.  As this does not change
any default behavior, it is not classified as a direct security fix for
anything within Asterisk, but may help PBX admins better secure their
SIP servers.
(closes issue ASTERISK-11245)
Reported by: ibc
      20080829__bug11776.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, blitzrage