Hi, Permissions module tries to avoid REGISTER with privileged IP's in Contact (using "register.deny" file) but I have some doubs about this security.
I'll play with the example explained in "register.deny" file:
--------------------------------------------------------------------------------------- # Suppose that we have a PSTN gateway with IP address 1.2.3.4 # We should prevent REGISTER messages that contain that IP # address in Contact header field because that can cause serious # security hole (a malicious user might be able to register such # a contact and bypass security checks performed by the SIP proxy). # # The following line prevents registering Contacts with IP 1.2.3.4 # (Don't forget to list also all hostnames that can be used to # reach the PSTN gateway)
ALL : "^sip:.*1.2.3.4" ---------------------------------------------------------------------------------------
Ok, now a malicious user could just use SipSak to send a malicious REGISTER to call for free to a PSTN number 01666555444:
~# sipsak -U -C sip:01666555444@1.2.3.00004 -a passwd -s sip:200@domain.org
Note the "000004" !!!!
So this causes a entry in "location" with fields: - username = 200 - domain = domain.org - contact = sip:01666555444@1.2.3.00004
And sure 1.2.3.00004 is a valid IPv4.
This is: if the user calls itself (sip:200@domain.org) he'll get a free PSTN call. Oppss...
Ok, a solution could be to improve the regular expression by avoiding any number of 0's:
ALL : "^sip:.*0*1.0*2.0*3.0*4"
Ok, but now the malicious user can register a domain "hacking_my_proxy.com" to resolve to IP 1.2.3.4, and send this REGISTER:
~# sipsak -U -C sip:01666555444@hacking_my_proxy.com -a passwd -s sip:200@domain.org
So this will bypass the "register.deny" policy !!!!
Note that "register.deny" file says: # (Don't forget to list also all hostnames that can be used to # reach the PSTN gateway)
Of course, it's not possible to list all hostnames and domain resolving an IP (anyone can register a domain to any IP).
So then... is it really valid this "register.deny" security????
Solution for this? -------------------------
- Forbid hostnames or domains in Contact: Ohh, too much anti-RFC 3261 (what would "alice@pc33.atlanta.com" think about it? XDDD).
- Do a DNS query for the "Contact" during REGISTER: What about if DNS changes later?
- Match the resolved IP against IP's in "register.deny" for every INVITE leaving OpenSer. Humm.
- Avoid OpenSer using internet DNS system (so "hacking_my_proxy.com" wouldn't be resolved) and allow just secure domains (internal DNS or /etc/hosts): and what about outbound calls? isn't this solution an atrocity?
How to handle it? is it not a real security hole?
Comments are welcome. Regards.
Iñaki Baz Castillo writes:
How to handle it? is it not a real security hole?
1) buy pstn gws that accept no hostnames (just its own ip address) in the hostpart of r-uri. example, cisco ios with later software releases.
2) forget the hostpart check all together and instead check the userpart, where you have put something special that the gw then removes.
-- juha
El Friday 14 December 2007 07:02:37 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
How to handle it? is it not a real security hole?
- buy pstn gws that accept no hostnames (just its own ip address) in
the hostpart of r-uri. example, cisco ios with later software releases.
So really isn't there solution just in OpenSer-Registrar side??
- forget the hostpart check all together and instead check the userpart, where you have put something special that the gw then removes.
So you mean for example:
register.deny: -------------------- ALL : "^sip:.*secret_word_.*@" ----------------------
And later, in any call to PSTN OpenSer should add:
$ru = "secret_word_" + $ru;
so the uri arriving to the gw becomes:
sip:secret_word_01666555444@gw_ip_or_hostname
And the gw should just allow calls from OpenSer with urri username beginning with "secret_word_" and it should strip it.
Is this what you mean? anyway, a little complex, isn't it? XDD
Regards.
El Friday 14 December 2007 09:59:36 Iñaki Baz Castillo escribió:
El Friday 14 December 2007 07:02:37 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
How to handle it? is it not a real security hole?
- buy pstn gws that accept no hostnames (just its own ip address) in
the hostpart of r-uri. example, cisco ios with later software releases.
I've tryed this with Asterisk as GW. It works by adding:
sip.conf: ------------- allowexternaldomains=no domain=85.95.0.111 -------------
And in OpenSer:
register.deny: ------------- ALL : "^sip:.*0*85.0*95.0*0.0*111" -------------
Anyway, do really people take care about it? Regards.
Iñaki Baz Castillo writes:
- buy pstn gws that accept no hostnames (just its own ip address) in
the hostpart of r-uri. example, cisco ios with later software releases.
So really isn't there solution just in OpenSer-Registrar side??
this is registrar solution. you use parmissions module and don;t accept registrations where ip address in hostpart of contact belongs to your gws.
- forget the hostpart check all together and instead check the userpart, where you have put something special that the gw then removes.
So you mean for example:
register.deny:
ALL : "^sip:.*secret_word_.*@"
And later, in any call to PSTN OpenSer should add:
$ru = "secret_word_" + $ru;
you can use lcr module to add the prefix.
so the uri arriving to the gw becomes:
sip:secret_word_01666555444@gw_ip_or_hostname
And the gw should just allow calls from OpenSer with urri username beginning with "secret_word_" and it should strip it.
that is correct, but the prefix does not need to be secret, just something that doesn't normally appear in userparts.
Is this what you mean? anyway, a little complex, isn't it? XDD
why do you think it is complex? one row in register.deny and one strip at the gateway.
-- juha
Curve ball suggestion:
Surely just authenticate all register requests with www-challenge. Hide your gateway and SER behind a firewall so your Gateway cannot be seen from the outside work (from a SIP Signalling perspective), and for PSTN calls from authenticated users do a rewritehost and forward to send the INVITEs on to the PSTN gateway?
Neill....;o)
-----Original Message----- From: users-bounces@lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf Of Juha Heinanen Sent: 14 December 2007 10:05 To: Iñaki Baz Castillo Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] Security hole in REGISTER's Contact using domain
Iñaki Baz Castillo writes:
- buy pstn gws that accept no hostnames (just its own ip address) in
the hostpart of r-uri. example, cisco ios with later software releases.
So really isn't there solution just in OpenSer-Registrar side??
this is registrar solution. you use parmissions module and don;t accept registrations where ip address in hostpart of contact belongs to your gws.
- forget the hostpart check all together and instead check the userpart, where you have put something special that the gw then removes.
So you mean for example:
register.deny:
ALL : "^sip:.*secret_word_.*@"
And later, in any call to PSTN OpenSer should add:
$ru = "secret_word_" + $ru;
you can use lcr module to add the prefix.
so the uri arriving to the gw becomes:
sip:secret_word_01666555444@gw_ip_or_hostname
And the gw should just allow calls from OpenSer with urri username
beginning
with "secret_word_" and it should strip it.
that is correct, but the prefix does not need to be secret, just something that doesn't normally appear in userparts.
Is this what you mean? anyway, a little complex, isn't it? XDD
why do you think it is complex? one row in register.deny and one strip at the gateway.
-- juha
_______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Neill Wilkinson writes:
Surely just authenticate all register requests with www-challenge. Hide your gateway and SER behind a firewall so your Gateway cannot be seen from the outside work (from a SIP Signalling perspective), and for PSTN calls from authenticated users do a rewritehost and forward to send the INVITEs on to the PSTN gateway?
Neill....;o)
perhaps you didn't understand the problem. authenticating register requests is not enough. you also need to check what user puts in contact(s), since you cannot hide your gws from your proxies.
-- juha
Fair point.
Neill...;o)
-----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: 14 December 2007 10:33 To: Neill Wilkinson Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] Security hole in REGISTER's Contact using domain
Neill Wilkinson writes:
Surely just authenticate all register requests with www-challenge. Hide
your
gateway and SER behind a firewall so your Gateway cannot be seen from the outside work (from a SIP Signalling perspective), and for PSTN calls from authenticated users do a rewritehost and forward to send the INVITEs on
to
the PSTN gateway?
Neill....;o)
perhaps you didn't understand the problem. authenticating register requests is not enough. you also need to check what user puts in contact(s), since you cannot hide your gws from your proxies.
-- juha
Neill Wilkinson writes:
Surely just authenticate all register requests with www-challenge. Hide
your
gateway and SER behind a firewall so your Gateway cannot be seen from
the
outside work (from a SIP Signalling perspective), and for PSTN calls
from
authenticated users do a rewritehost and forward to send the INVITEs on
to
the PSTN gateway?
Neill....;o)
perhaps you didn't understand the problem. authenticating register requests is not enough. you also need to check what user puts in contact(s), since you cannot hide your gws from your proxies.
btw: IMO this is a bug in SIP. The RFC tells us that the SIP proxy should store the Contact URI and route calls based in this URI. But AFAIK the RFC does not tell us to validate the Contact URI.
Never trust user provided data blindly. The Contact is user provided :-(
regards klaus
El Friday 14 December 2007 12:18:31 klaus.mailinglists@pernau.at escribió:
btw: IMO this is a bug in SIP. The RFC tells us that the SIP proxy should store the Contact URI and route calls based in this URI. But AFAIK the RFC does not tell us to validate the Contact URI.
Never trust user provided data blindly. The Contact is user provided :-(
I see other problem related:
Imagine a multidomain SIP proxy in which there are rules and filters between domains. For example:
- domain_A and domain_B in same proxy. - domain_A has a policy that dissallowes calls from domain_B. - But domain_B allowes calls from domain_A.
- sip:user_A@domain_A calls sip:user_B@domain_B - During the dialog user_B takes a look to received "Contact" from user_A.
- Later user_B sends a malicious REGISTER: ~# sipsak -U -C sip:user_A@Contact_user_A -a pw -s sip:user_B@domain_B
- Now user_B@domain_B calls himself and gets a call to user_A@domain_A. - So domain_A interdomain permissions rules have been bypassed :(
If NAT wouldn't exist in this IPv4 world, "Contact" header could be matched against the source IP of the REGISTER. But of course NAT makes it impossible.
Maybe OpenSer could add some security check to disallow "Contact" header containing public IP if the REGISTER is detected as natted. Could it be possible?
El Friday 14 December 2007 11:21:09 Neill Wilkinson escribió:
Curve ball suggestion:
Surely just authenticate all register requests with www-challenge. Hide your gateway and SER behind a firewall so your Gateway cannot be seen from the outside work (from a SIP Signalling perspective), and for PSTN calls from authenticated users do a rewritehost and forward to send the INVITEs on to the PSTN gateway?
Sorry, but that is not enough, that is the reason I opened this thread. Of course I do all you say there, but the problem exists if a user sends a malicious REGISTER indicating in the "Contact" a domain pointing to the gw IP with a username as PSTN number.
Later if other user calls the previous one, the proxy will do "lookup" and get this RURI:
sip:PSTN_number@gw_domain
The proxy then will send there the INVITE (to its gateway). Of course, no www-challenge auth is done from proxy to gw, so gw will accept this call (it comes from proxy IP !!!).
Solutions for this has been given by Juha in previous replies.
Regards.
El Friday 14 December 2007 11:04:40 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
- buy pstn gws that accept no hostnames (just its own ip address) in
the hostpart of r-uri. example, cisco ios with later software releases.
So really isn't there solution just in OpenSer-Registrar side??
this is registrar solution. you use parmissions module and don;t accept registrations where ip address in hostpart of contact belongs to your gws.
Yes, but without gateway collaboration you get nothing. Proxy must avoid REGISTER with gateway IP in Contact but in case of a "Contact: domain_to_gw" the only solution is gw avoiding not IP ruri domain. Proxy can do nothing in that case.
- forget the hostpart check all together and instead check the userpart, where you have put something special that the gw then removes.
So you mean for example:
register.deny:
ALL : "^sip:.*secret_word_.*@"
And later, in any call to PSTN OpenSer should add:
$ru = "secret_word_" + $ru;
you can use lcr module to add the prefix.
so the uri arriving to the gw becomes:
sip:secret_word_01666555444@gw_ip_or_hostname
And the gw should just allow calls from OpenSer with urri username beginning with "secret_word_" and it should strip it.
that is correct, but the prefix does not need to be secret, just something that doesn't normally appear in userparts.
Is this what you mean? anyway, a little complex, isn't it? XDD
why do you think it is complex? one row in register.deny and one strip at the gateway.
I'm trying it with some SIP providers and I see:
INVITE sip:0034666555444@sip_provider_domain
and I get in the "183" and "200" a Contact like:
Contact: sip:aa+ibc@IP:5090
So I assume that "aa" is the privileged prefix.
Hi!
This is what I do:
1. use permissions module to: - deny REGISTER with contact which points to IP of gateways by using a regexp which also detects leading 0 - deny domain names in contact URI. yes, this is not RFC conform and will break SMTP style forwarding
2. newer openser with blacklist feature: - put all the sensitive IP addresses on the blacklist - if the proxy routes a call by purpose to the gateway (detects PSTN call) then the blacklist is not activated - for all other calls the blacklist is activated thus the proxy can not send a request to the gateway by mistake.
3. older openser without blacklist feature - either check domain part of RURI in gateway (like Juha told), (make sure to reject out-of-dialog requests with pre-laoded route set in strict-router syntax which will cause some gateways to use the Route set instead of the target URI) - use some secret which is known only to the proxy and the gateway, e.g: - add a certain header which is checked for existence in the gateway (works of course only with gateways which allows this feature like Asterisk) - do not use a prefix to the RURI as secret as Cisco and Asterisk will use the userpart of RURI in the userpart of Contact URI - those the secret prefix is visible to the attacker - use certain port for communication with gateway. e.g. configure openser to listen on port 6060 too. This port will be blocked by firewall from outside - thus SIP client can not send requests to port 6060. In openser, when sending a request to the gateway do a "force_send_socket("ip:6060")". This causes openser to not use default 506 but 6060 as source port (works only with UDP). Then in the gateway accept only SIP requests coming from port 6060 (e.g. ip access rules in Cisco gateways, iptables with Asterisk). If the proxy sends a request to the gateway by mistake (attack) it will send the request from port 5060 and it can't be sent to the gateway as the firewall blocks.
cheers klaus
Hi, Permissions module tries to avoid REGISTER with privileged IP's in Contact (using "register.deny" file) but I have some doubs about this security.
I'll play with the example explained in "register.deny" file:
# Suppose that we have a PSTN gateway with IP address 1.2.3.4 # We should prevent REGISTER messages that contain that IP # address in Contact header field because that can cause serious # security hole (a malicious user might be able to register such # a contact and bypass security checks performed by the SIP proxy). # # The following line prevents registering Contacts with IP 1.2.3.4 # (Don't forget to list also all hostnames that can be used to # reach the PSTN gateway)
ALL : "^sip:.*1.2.3.4"
Ok, now a malicious user could just use SipSak to send a malicious REGISTER to call for free to a PSTN number 01666555444:
~# sipsak -U -C sip:01666555444@1.2.3.00004 -a passwd -s sip:200@domain.org
Note the "000004" !!!!
So this causes a entry in "location" with fields:
- username = 200
- domain = domain.org
- contact = sip:01666555444@1.2.3.00004
And sure 1.2.3.00004 is a valid IPv4.
This is: if the user calls itself (sip:200@domain.org) he'll get a free PSTN call. Oppss...
Ok, a solution could be to improve the regular expression by avoiding any number of 0's:
ALL : "^sip:.*0*1.0*2.0*3.0*4"
Ok, but now the malicious user can register a domain "hacking_my_proxy.com" to resolve to IP 1.2.3.4, and send this REGISTER:
~# sipsak -U -C sip:01666555444@hacking_my_proxy.com -a passwd -s sip:200@domain.org
So this will bypass the "register.deny" policy !!!!
Note that "register.deny" file says: # (Don't forget to list also all hostnames that can be used to # reach the PSTN gateway)
Of course, it's not possible to list all hostnames and domain resolving an IP (anyone can register a domain to any IP).
So then... is it really valid this "register.deny" security????
Solution for this?
- Forbid hostnames or domains in Contact: Ohh, too much anti-RFC 3261
(what would "alice@pc33.atlanta.com" think about it? XDDD).
- Do a DNS query for the "Contact" during REGISTER: What about if DNS
changes later?
- Match the resolved IP against IP's in "register.deny" for every INVITE
leaving OpenSer. Humm.
- Avoid OpenSer using internet DNS system (so "hacking_my_proxy.com"
wouldn't be resolved) and allow just secure domains (internal DNS or /etc/hosts): and what about outbound calls? isn't this solution an atrocity?
How to handle it? is it not a real security hole?
Comments are welcome. Regards.
-- Iñaki Baz Castillo
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Friday 14 December 2007 11:28:10 klaus.mailinglists@pernau.at escribió:
Hi!
Thanks for so complete and didactic reply ;)
This is what I do:
- use permissions module to:
- deny REGISTER with contact which points to IP of gateways by using a
regexp which also detects leading 0
- deny domain names in contact URI. yes, this is not RFC conform and will
break SMTP style forwarding
Opssss, bob and alice will be very angry with you.
- newer openser with blacklist feature:
- put all the sensitive IP addresses on the blacklist
- if the proxy routes a call by purpose to the gateway (detects PSTN
call) then the blacklist is not activated
- for all other calls the blacklist is activated thus the proxy can not
send a request to the gateway by mistake.
Nice solution, but: I want to allow that some SIP domains of OpenSer use their own gateway (maybe an Asterisk), and this Asterisk could be behind dynamic ADSL and NAT. Later when users of that domain makes a PSTN call, my OpenSer looks for "pbx" registered user (Asterisk) and sends the INVITE to that location (keeping the extension called):
if call to PSTN number { $var(rU_original) = $rU; $rU="pbx"; if (lookup("location")) { $rU=$var(rU_original); t_relay(); exit; } }
So in this case I should play with prefix in username or headers.
- older openser without blacklist feature
- either check domain part of RURI in gateway (like Juha told), (make
sure to reject out-of-dialog requests with pre-laoded route set in strict-router syntax which will cause some gateways to use the Route set instead of the target URI)
- use some secret which is known only to the proxy and the gateway, e.g:
- add a certain header which is checked for existence in the gateway
(works of course only with gateways which allows this feature like Asterisk)
- do not use a prefix to the RURI as secret as Cisco and Asterisk will
use the userpart of RURI in the userpart of Contact URI - those the secret prefix is visible to the attacker
But this is not a problem if you set: ALL : "^sip:\s*secret.*" in "register.deny".
- use certain port for communication with gateway. e.g. configure openser
to listen on port 6060 too. This port will be blocked by firewall from outside - thus SIP client can not send requests to port 6060. In openser, when sending a request to the gateway do a "force_send_socket("ip:6060")". This causes openser to not use default 506 but 6060 as source port (works only with UDP). Then in the gateway accept only SIP requests coming from port 6060 (e.g. ip access rules in Cisco gateways, iptables with Asterisk). If the proxy sends a request to the gateway by mistake (attack) it will send the request from port 5060 and it can't be sent to the gateway as the firewall blocks.
Really thanks for all!
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
klaus.mailinglists＠pernau.at -
Neill Wilkinson