[OpenSER-Users] kagoor voiceflow replacement

[Klaus Darilion]

>>> Otherwise any client in your network may populate your usrlow
>>> without credentials and depending on your setup just grab other
>>> users accounts.
>> Even if you save() during request processing and have "bad" data in
>> the usrloc table account hijacking shouldn't be possible because if
>> the registration fails on the registrar, the registrar wont forward
>> incoming calls to openser.
> 
> Consider the following sequence:
> 1) User A registers sucessfully. openser usrloc and upstream usrloc are in
> sync.
> 2) User B fakes user A registration. upstream says no - but openser
> already saved => usrlocs are out of sync
> 3) call from outside which should get to A will go to B
>    (and B might forward to A, staying in the middle of course)

In step 3 it depends.

Usually, if openser forwards the REGISTER it has to manipulate it.

E.g the following scenario (for simplicity no NAT traversal and no 
multi-domain):
user aor: sip:alice at atlanta.com
user contact: sip:1.2.3.4

Registrar is a dumb SIP registrar at domain atlanta.com

Openser acts as outboundproxy, listening on domain obp.atlanta.com.

When openser forwards the REGISTER to the registrar it has to replace 
the contact header with the contact of itself (so that the registrar 
will forward the requests to openser). Further, openser has to put some 
id into the userpart to match incoming INVITEs to the proper user, e.g:

alice ----REGISTER-----> openser
REGISTER sip:alice at atlanta.com
To: sip:alice at atlanta.com
Contact: sip:1.2.3.4

openser ----REGISTER-----> registrar
REGISTER sip:alice at atlanta.com
To: sip:alice at atlanta.com
Contact: sip:userid at obp.atlanta.com

usrloc table of openser:
             AoR            | contact
---------------------------+----------------------------
sip:userid at obp.atlanta.com | sip:1.2.3.4

usrloc table of registrar:
             AoR            | contact
---------------------------+----------------------------
sip:alice at atlanta.com      | sip:userid at obp.atlanta.com



Now, depending on how the "userid" is generated in the openser, the 
system is vulnerable in the above step 3 or not. Of course if the 
attacker find out how "userid" is generated or it makes brute force 
registration with all possible userid then the system is vulnerable. 
Anyway, you are correct - the save() should happen in the reply route 
after successful 200 OK.

I think a good generic solution would be to make a save() function which 
takes AoR and Contact from a parameter, e.g.: 
save("string/pv-spec","string/pv-spec") and this save function should 
work in reply route too. In single-domain setup the "userid" could be 
just the username of the AoR, e.g:
in request route:
   $avp(s:contact) = $ct;
   remove_hf("Contact");
   append_hf("Contact: sip:$tU at obp.atlanta.com\r\n");
   t_on_reply(...)

in reply route
   if (200 OK)
     save("sip:$tU at obp.atlanta.com","$avp(s:contact)");


Thus, for a nice solution I guess you are right - source code 
modification would be necessary (but it shouldn't be that hard to expand 
save() to take parameters)

regards
Klaus