13 Dec
2007
13 Dec
'07
11:58 p.m.
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(a)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
14 Dec
14 Dec
8:02 a.m.
New subject: [OpenSER-Users] Security hole in REGISTER's Contact using domain
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
10:59 a.m.
El Friday 14 December 2007 07:02:37 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
So really isn't there solution just in OpenSer-Registrar side??
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.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
11:41 a.m.
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?
>
> 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.
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
ibc(a)in.ilimit.es
12:04 p.m.
Iñaki Baz Castillo writes:
this is registrar solution. you use parmissions module and don;t accept
registrations where ip address in hostpart of contact belongs to your
gws.
you can use lcr module to add the prefix.
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.
So really isn't there solution just in OpenSer-Registrar side?? 2) 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.
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
12:21 p.m.
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(a)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(a)lists.openser.org
Subject: Re: [OpenSER-Users] Security hole in REGISTER's Contact using
domain
Iñaki Baz Castillo writes:
this is registrar solution. you use parmissions module and don;t accept
registrations where ip address in hostpart of contact belongs to your
gws.
you can use lcr module to add the prefix.
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.
So really isn't there solution just in OpenSer-Registrar side?? 2) 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.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
12:32 p.m.
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
12:38 p.m.
Fair point.
Neill...;o)
-----Original Message-----
From: Juha Heinanen [mailto:jh@tutpro.com]
Sent: 14 December 2007 10:33
To: Neill Wilkinson
Cc: users(a)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
1:18 p.m.
Neill Wilkinson writes:
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
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.
2:37 p.m.
El Friday 14 December 2007 12:18:31 klaus.mailinglists(a)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?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
12:35 p.m.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
12:29 p.m.
El Friday 14 December 2007 11:04:40 Juha Heinanen escribió:
you can use lcr module to add the prefix.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Iñaki Baz Castillo writes:
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.
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.
So really isn't there solution just in OpenSer-Registrar side?? 2) 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.
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.
12:28 p.m.
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(a)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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
12:59 p.m.
El Friday 14 December 2007 11:28:10 klaus.mailinglists(a)pernau.at escribió:
Hi!
Thanks for so complete and didactic reply ;)
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
Opssss, bob and alice will be very angry with you.
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.
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.
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
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
ibc(a)in.ilimit.es
6191
days inactive
6192
days old
13 comments
5 participants
participants (5)
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
klaus.mailinglists＠pernau.at -
Neill Wilkinson