The save function from the registrar module uses the To header to disect and store the username for the location table according to observations and documentation http://www.kamailio.org/docs/modules/stable/modules/registrar.html#registrar...
After troubleshooting a ticket from an enduser unable to receive calls where all looked fine but the username used for authentication wasn't showing up in the location database. Finally I found the REGISTER was added to the location database, but not with the user its username, instead it was using the username (phonenumber) specified in the To header. Till now I always assumed that the username in the location table would be the username used during authentication(*).
This opens the door to hijacking incoming calls to other users on the same kamailio registrar if one knows/guesses other usernames and use those in the To header. This realisation is kind of shocking to me.
The solution is simple (if authentication is required): save("location", "0x00", "sip:$au@$rd");
*: which kind of answers my question in the subject, what else can be used if there is no authentication required?
Hello,
RFC 3261 § 10.2.1 says:
The address-of-record is included in the To header field of the REGISTER request.
-- Alex
On 15.05.17 14:14, Daniel Tryba wrote:
The save function from the registrar module uses the To header to disect and store the username for the location table according to observations and documentation http://www.kamailio.org/docs/modules/stable/modules/registrar.html#registrar...
After troubleshooting a ticket from an enduser unable to receive calls where all looked fine but the username used for authentication wasn't showing up in the location database. Finally I found the REGISTER was added to the location database, but not with the user its username, instead it was using the username (phonenumber) specified in the To header. Till now I always assumed that the username in the location table would be the username used during authentication(*).
This opens the door to hijacking incoming calls to other users on the same kamailio registrar if one knows/guesses other usernames and use those in the To header.
SIP allows third party registrations. From header indicates who performs the registration. To header indicates for who is done the registration. Auth username is the account/private identity associated with From. All these three can be different in SIP. In kamailio, we check that all of them are the same via the parameter options of auth_check().
If you give different public and private identities, then you need to keep the relation between them and check there is a match, otherwise, yes, I have an account on the same service with you, then I can register my phone on your behalf. uri_db module is supposed to offer a database-based solution, but you can use other modules (e.g., sqlops, htable, ...).
This realisation is kind of shocking to me.
Contact IETF guys, Alex pointed the reason in the other email ;-)
The solution is simple (if authentication is required): save("location", "0x00", "sip:$au@$rd");
*: which kind of answers my question in the subject, what else can be used if there is no authentication required?
Cheers, Daniel
On Mon, May 15, 2017 at 03:06:38PM +0200, Daniel-Constantin Mierla wrote:
This opens the door to hijacking incoming calls to other users on the same kamailio registrar if one knows/guesses other usernames and use those in the To header.
SIP allows third party registrations. From header indicates who performs the registration. To header indicates for who is done the registration. Auth username is the account/private identity associated with From. All these three can be different in SIP. In kamailio, we check that all of them are the same via the parameter options of auth_check().
If you give different public and private identities, then you need to keep the relation between them and check there is a match, otherwise, yes, I have an account on the same service with you, then I can register my phone on your behalf. uri_db module is supposed to offer a database-based solution, but you can use other modules (e.g., sqlops, htable, ...).
Okay, didn't see it as a feature, only as a way to hijack. Never looked at auth_check, but I'm glad someone thought about this.
This realisation is kind of shocking to me.
Contact IETF guys, Alex pointed the reason in the other email ;-)
I'm over it now :)
Thanks for you and Alex's feedback.
-
Alex Balashov -
Daniel Tryba -
Daniel-Constantin Mierla