| 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-0600 | Date Closed: | 2008-09-12 15:27:58 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Registration |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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": sip.conf: ------------------------------------------ [authentication] auth = client_number:client_password@sip_provider.com [sip_provider] type = peer host = sip_provider.com [2001] ; local phone type = friend secret = 1234 context = from_phone ------------------------------------------ extensions.conf: ------------------------------------------ [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: Dial(SIP/2001) - 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! ****** ADDITIONAL INFORMATION ****** 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 10.10.10.10, 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: [general] blacklist = 90.90.90.90, 91.91.91.91 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: [sip_provider] host = sip.sip_provider.com ; resolvs to 90.90.90.90 type = peer dissable_blacklist = true So then, a INVITE is only allowed to 90.90.90.90 if the Dial is like: Dial(SIP/sip_provider/XXXX) or Dial(SIP/XXXX@sip_provider) 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@192.168.128.5:5060 -a 1234 -s sip:2001@192.168.128.112 warning: ignoring -i option when in usrloc mode Anyone seen that before? 192.168.128.5 is the "sip provider", and 192.168.128.112 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 '192.168.128.106' 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@192.168.128.106:5060" -a "1234" -s sip:2001@192.168.128.113 received: SIP/2.0 400 Bad Request Via: SIP/2.0/UDP 127.0.0.1:32778;branch=z9hG4bK.03cd3d33;alias;received=192.168.128.113;rport=32778 From: sip:2001@192.168.128.113;tag=7431c7ed To: sip:2001@192.168.128.113;tag=as34af6227 Call-ID: 1949419501@127.0.0.1 CSeq: 2 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 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 sip.conf ~~~~~~~~ [general] dynamic_exclude_static=yes contactdeny=0.0.0.0/0.0.0.0 contactpermit=192.168.128.113/255.255.255.255 UPDATE/EDIT: 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: contactpermit=192.168.128.0/255.255.255.0 And I still get the rejection. I also tried specifically using: contactpermit=192.168.128.103/255.255.255.255 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 @oej: I think the response should be "403 Forbidden" rather than "400 Bad request". @blitzrage: Can you try with?: -------------- sip.conf [general] dynamic_exclude_static=yes contactdeny=192.168.128.5/255.255.255.255 sipsak -E UDP -U -C "sip:11776@192.168.128.05:5060" -a "1234" -s -------------- Note the "05" instead of "5". By: Leif Madsen (lmadsen) 2008-08-27 10:55:03 @ibc: My sipsak didn't like me using that interface -- it wanted to route over the 192.168.128.106 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 '192.168.128.106' 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 192.168.128.100 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' sip.conf -------- [general] 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=0.0.0.0/0.0.0.0 ; Use contactpermit and contactdeny to contactpermit=192.168.128.100/255.255.255.255 ; 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 192.168.128.106 (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 Patches: 20080829__bug11776.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76, blitzrage ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=142865 | ||