[Freeswitch-users] mod_xml_curl - missing dialplan variable (domain of originating user for blind transfer)

Sun Dec 30 23:12:55 MSK 2012

>From what I can tell - that's not entirely correct from a security stand
point.

Let's say a call comes in from an external gateway (DDI 442476100401), it's
routed to user 2001.

If you do 'set_user' then you'd be effectively saying that Leg A of the
call is an authorized user - is this correct?

If so - this could have all sorts of implications when performing
sanity/security checks on later events.

Please let me know if I'm wrong, as I haven't used 'set_user' much.

Cal

On Sun, Dec 30, 2012 at 7:38 PM, Dave R. Kompel <drk at drkngs.net> wrote:

> **
>  Since this is for use in external generated XML, and for the most part
> it should be code that is generating it, the easiest way to handle calls
> from gateways, is to back them with users in the directory. When A calll is
> from a gateway, simply do a set_user in your dialplan, and then a transfer
> back to the number dialed in the context ${user_context}, which will be set
> after you do the set_user.
>
> This way you don't have to do anything special for calls that come from a
> gateway, transfers and other things just work right.
>
> --Dave
>
>
>  ------------------------------
> *From:* Cal Leeming [Simplicity Media Ltd] [mailto:
> cal.leeming at simplicitymedialtd.co.uk]
> *To:* FreeSWITCH Users Help [mailto:freeswitch-users at lists.freeswitch.org]
> *Sent:* Sun, 30 Dec 2012 10:04:57 -0800
> *Subject:* Re: [Freeswitch-users] mod_xml_curl - missing dialplan
> variable (domain of originating user for blind transfer)
>
>
> I have started to move some of this information into the wiki.
>
> However, my previous comments about
> forcing sip_auth_realm/sip_auth_username are generally considered unsafe
> from a security point of view.
>
> If you force those variables, under some circumstances a blind transferred
> call from an external gateway could later on be considered an authorized
> internal user and lead to undesired behaviour.
>
> Forcing sip_invite_domain however is acceptable, as some request context
> will lose this information during a blind transfer or bridge.
>
> I am currently building up a spreadsheet of different call scenarios,
> along with the request variables for each one, so it is easy to see how the
> variables change depending on what event is happening.
>
> Cal
>
> On Tue, Nov 20, 2012 at 1:21 PM, Cal Leeming [Simplicity Media Ltd] <
> cal.leeming at simplicitymedialtd.co.uk> wrote:
>
>> Hi Anthony,
>>
>> Thanks for the reply, yeah I spent some time looking at alternative ways
>> and came up with one that seems to get the job done
>>
>> I am convinced now that there is no bug as such - but one thing that is
>> absolutely clear, is that mod_xml_curl is in desperate need of
>> normalization.. even if it was fully documented, some of the variants don't
>> make logical sense. However, the information is there, and as long as you
>> do the correct conditional checks, then it will work flawlessly.
>>
>> To make the authenticated domain stick when passing through to a gateway,
>> we use the following;
>>
>> <action application="bridge"
>> data="{sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}sofia/gateway/{{
>> dst.gateway.name
>> }}/{{dst.gateway.fs_dial_prefix}}{{dst.dst_number_e164}}"/>
>>
>> The most important part of the above being;
>>
>> {sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}
>>
>> However, this alone doesn't deal with the fact that you have to look in
>> different places for the correct variables depending on what the current
>> call context is.
>>
>> To a certain extent, your own business logic will also determine which
>> variables should be used, and a combination of conditional checks may need
>> to be used in order to figure out which variable you should be using in the
>> first place lol.
>>
>> Here are the patterns we have found so far - this is just an information
>> dump for now, and later down the road I will update the mod_xml_curl
>> documentation.
>>
>> # Ensure that variable_sip_auth_username / variable_sip_auth_realm
>> #
>> # If Call-Direction is inbound, then;
>> # src_user = variable_sip_auth_username
>> # src_domain = variable_sip_auth_realm
>> # dst_user = variable_sip_to_user
>> #
>> # If Call-Direction is outbound, then;
>> # originate_user = variable_sip_auth_username
>> # originate_domain = variable_sip_auth_realm
>> # src_user = variable_sip_to_user
>> # src_domain = variable_sip_to_host
>> # dst_user = Caller-Destination-Number
>>
>> * gateway to gateway (442476100401 > 442476100402)
>> * domain to gateway - blind xfer to gateway (2000 > 442476100401
>> > 442476100402)
>> * domain to gateway - blind xfer to domain (2000 > 442476100401 > 2002)
>> * domain to gateway (2000 > 442476100401)
>> * domain to domain (2000 > 2001)
>>
>> ----
>>
>> # Check if variable_sip_to_host is present and known gateway
>> #
>> # If variable_dialed_user and variable_dialed_domain are present;
>> # originate_user = variable_dialed_user
>> # originate_domain = variable_dialed_domain
>> # src_user = variable_sip_from_user
>> # src_domain = variable_sip_to_host
>> # dst_user = Caller-Destination-Number
>> #
>> # If not present;
>> # src_user = variable_sip_from_user
>> # src_domain = variable_sip_to_host
>> # dst_user = variable_sip_to_user
>>
>>  * gateway to domain (442476100401 > 2002)
>> * gateway to domain - blind xfer to gateway (442476100401 > 2000
>> > 442476100402)
>> * gateway to domain - blind xfer to domain (442476100401 > 2000 > 2002)
>>
>> ----
>>
>> # check for variable_dialed_domain
>> # If match;
>> # src_user = variable_dialed_user
>> # src_domain  = variable_dialed_domain
>> # dst_user = Caller-Destination-Number
>>
>>  * domain to domain to gateway (2000 > 2001 > 442476100402)
>>
>>
>> On Tue, Nov 20, 2012 at 2:55 AM, Anthony Minessale <
>> anthony.minessale at gmail.com> wrote:
>>
>>> One thing you can do is set the variable when you do know it, from the
>>> dialplan.  So it will be there in all the subsequent events.
>>>
>>>
>>>
>>>  On Mon, Nov 19, 2012 at 1:34 AM, Cal Leeming [Simplicity Media Ltd] <
>>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>>
>>>>  Last update, then I'm really going to sleep!
>>>>
>>>>  Apologies for the noise btw, in hindsight I should have collected all
>>>> this info and posted in one go.
>>>>
>>>> I've tried enabling auth-all-packets (along with auth_calls), as I
>>>> thought maybe having authentication on REFER packets might make a
>>>> difference, but sadly it had no effect (the SIP headers show
>>>> proxy-authorization in the REFER, but nothing extra showed in mod_xml_curl)
>>>>
>>>> I've managed to narrow down the circumstances in which this happens;
>>>>
>>>> CORRECT:
>>>>
>>>> * User receives call from gateway, blind transfer to another
>>>> user (shows correctly as variable_dialed_user/variable_dialed_domain)
>>>> * User receives call from another user, blind transfer to
>>>> gateway (shows correctly as variable_dialed_user/variable_dialed_domain)
>>>> * User receives call from another user, blind transfer to another
>>>> user (shows correctly as variable_dialed_user/variable_dialed_domain)
>>>> * User makes call to another user, blind transfer to another
>>>> user (shows correctly as variable_dialed_user/variable_dialed_domain)
>>>> * User makes call to another user, blind transfer to a gateway (shows
>>>> correctly as variable_dialed_user/variable_dialed_domain)
>>>>
>>>> MISSING:
>>>>
>>>> * User makes call to a gateway, blind transfer to another gateway (no
>>>> clean variables for domain)
>>>> * User makes call to a gateway, blind transfer to another user (no
>>>> clean variables for domain)
>>>>
>>>> So, the problem seems to happen specifically when you blind transfer a
>>>> call that is already in progress on a gateway, where the call was
>>>> originated by a user and not a gateway.
>>>>
>>>> I did a bit more looking through code, added a few switch_log_printf()
>>>> calls, and found that the following method is NOT called in those two
>>>> scenarios where these variables are missing;
>>>> mod_dptools.c: "switch_call_cause_t user_outgoing_channel"
>>>>
>>>> This is about as far as I can go on this, as I just don't know enough
>>>> about C to give any more in-depth info :/
>>>>
>>>> Cal
>>>>
>>>> On Mon, Nov 19, 2012 at 5:52 AM, Cal Leeming [Simplicity Media Ltd] <
>>>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>>>
>>>>> Sorry, another update.. after tinkering with the SIP headers, we found
>>>>> that we're able to pass any user/host along in an INVITE, and this is
>>>>> passed onto mod_xml_curl.
>>>>>
>>>>> To fix this particular part of the problem, we enabled auth_calls and
>>>>> this gives us correct/clean variables we can trust, specifically;
>>>>>
>>>>>   u'variable_sip_auth_username': u'2000',
>>>>>  u'variable_user_name': u'2000',
>>>>>
>>>>> However, when attempting to do the blind transfer again, this
>>>>> variables are all missing.
>>>>>
>>>>> At this point I'm convinced that attempting to extract the user/domain
>>>>> from the Refer headers is probably not the right thing to do... But I'm
>>>>> still no closer to figuring out what the correct approach should be to
>>>>> expose the authenticated user/domain to mod_xml_curl.
>>>>>
>>>>> Cal
>>>>>
>>>>>
>>>>> On Mon, Nov 19, 2012 at 4:58 AM, Cal Leeming [Simplicity Media Ltd] <
>>>>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>>>>
>>>>>> Another quick update on this before I pass out from lack of sleep..!
>>>>>>
>>>>>> Just had a look through the mod_sofia.c/h source and found the
>>>>>> following;
>>>>>>
>>>>>>  mod_sofia.c/mod_sofia.h
>>>>>> #define SOFIA_REFER_TO_VARIABLE "sip_refer_to"
>>>>>> if (!zstr(full_ref_by)) {
>>>>>> switch_channel_set_variable(t_channel, SOFIA_SIP_HEADER_PREFIX
>>>>>> "Referred-By", full_ref_by);
>>>>>> }
>>>>>> if (!zstr(full_ref_to)) {
>>>>>> switch_channel_set_variable(t_channel, SOFIA_REFER_TO_VARIABLE,
>>>>>> full_ref_to);
>>>>>> }
>>>>>> if (!zstr(full_ref_to)) {
>>>>>> switch_channel_set_variable(t_channel, SOFIA_REFER_TO_VARIABLE,
>>>>>> full_ref_to);
>>>>>> }
>>>>>> switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session),
>>>>>> SWITCH_LOG_DEBUG, "Process REFER to [%s@%s]\n", exten, (char *)
>>>>>> refer_to->r_url->url_host);
>>>>>>
>>>>>> If the correct approach is deemed to be patching code, then I figured
>>>>>> it could be as simple as this;
>>>>>>
>>>>>>  switch_channel_set_variable(t_channel, "Referred-By-User", exten);
>>>>>> switch_channel_set_variable(t_channel, "Referred-By-Domain", (char *)
>>>>>> refer_to->r_url->url_host);
>>>>>>
>>>>>> This is pretty much where my knowledge of C ends, I can (just about)
>>>>>> read and copy chunks of C code, but that's about it :)
>>>>>>
>>>>>> Cal
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 4:38 AM, Cal Leeming [Simplicity Media Ltd] <
>>>>>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>>>>>
>>>>>>> Not sure if this is relevant but thought I'd point it out.
>>>>>>>
>>>>>>> The following field seems to contain the IP of the domain we were
>>>>>>> expecting ('c1881.voiceflare.co.uk')
>>>>>>>
>>>>>>>   u'variable_sip_from_host': u'89.238.182.137',
>>>>>>>
>>>>>>> Normally, this field would contain the hostname and not the IP.
>>>>>>>
>>>>>>> Cal
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 4:34 AM, Cal Leeming [Simplicity Media Ltd]
>>>>>>> <cal.leeming at simplicitymedialtd.co.uk> wrote:
>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> In a nut shell, it appears that when attempting to perform a blind
>>>>>>>> transfer under certain conditions (explained below), mod_xml_curl does not
>>>>>>>> expose the originating domain in a clean format.
>>>>>>>>
>>>>>>>>  My initial plan was to find the point where these variable were
>>>>>>>> being generated, look at what was available, then add an extra variable for
>>>>>>>> the domain and submit a patch.
>>>>>>>>
>>>>>>>> Sadly my C isn't great and I hit a brick wall, so if anyone can
>>>>>>>> help out, I will ensure the mod_xml_curl documentation is updated and/or
>>>>>>>> assist with any patching/testing required.
>>>>>>>>
>>>>>>>> Please take the following scenario;
>>>>>>>>
>>>>>>>> * Extension 2000 calls an external number via a gateway (i.e.
>>>>>>>> bridge sofia/gateway/name/e164_number_here).
>>>>>>>> * Call connects fine, audio stays good, no disconnection problems
>>>>>>>> etc.
>>>>>>>> * Call is blind transferred to another extension
>>>>>>>>
>>>>>>>> As a result, the following is determined;
>>>>>>>>
>>>>>>>> * User initiating the blind transfer is 2000
>>>>>>>> * Domain initiating the blind transfer is c1881.voiceflare.co.uk
>>>>>>>> * Destination number of the call is 447866123456
>>>>>>>> * Number to blind transfer to is 2001
>>>>>>>> * Call to mod_xml_curl is made
>>>>>>>>
>>>>>>>> It makes reference to the User in the following 'clean' variables
>>>>>>>> (by clean, I mean variables that just contain 2000 and don't require
>>>>>>>> mangling to extract the info);
>>>>>>>>
>>>>>>>>   u'Caller-ANI': u'2000',
>>>>>>>>   u'Caller-Username': u'2000',
>>>>>>>>   u'Caller-Caller-ID-Number': u'2000',
>>>>>>>>   u'Hunt-ANI': u'2000',
>>>>>>>>   u'Hunt-Caller-ID-Number': u'2000',
>>>>>>>>   u'Hunt-Username': u'2000',
>>>>>>>>   u'variable_last_sent_callee_id_number': u'2000',
>>>>>>>>   u'variable_sip_from_user': u'2000',
>>>>>>>>
>>>>>>>> It also has the User in the following unclean variables;
>>>>>>>>
>>>>>>>>  u'variable_bridge_channel': u'sofia/external/
>>>>>>>> 2000 at c1881.voiceflare.co.uk:5060',
>>>>>>>>   u'variable_sip_from_uri': u'2000 at 89.238.182.137',
>>>>>>>>  u'variable_sip_full_from': u'"foxx" <sip:2000 at 89.238.182.137
>>>>>>>> >;tag=XryjFQp3rB2NF',
>>>>>>>>   u'variable_sip_h_Referred-By': u'"foxx" <
>>>>>>>> sip:2000 at c1881.voiceflare.co.uk:5060>',
>>>>>>>>
>>>>>>>> However, it only references the domain in the following unclean
>>>>>>>> variables;
>>>>>>>>
>>>>>>>>  u'variable_bridge_channel': u'sofia/external/
>>>>>>>> 2000 at c1881.voiceflare.co.uk:5060',
>>>>>>>>  u'variable_sip_h_Referred-By': u'"foxx" <
>>>>>>>> sip:2000 at c1881.voiceflare.co.uk:5060>',
>>>>>>>>  u'variable_sip_refer_to': u'<sip:2001 at c1881.voiceflare.co.uk:5060
>>>>>>>> >',
>>>>>>>>
>>>>>>>> Lets say that we want to determine the user/domain that has
>>>>>>>> initiated this transfer, doing so would mean mangling with one of those
>>>>>>>> above variables, which seems a bit dirty (plus it is not clear which is the
>>>>>>>> correct one to use).
>>>>>>>>
>>>>>>>> I have attached the SIP trace of the entire blind transfer event,
>>>>>>>> and the full mod_xml_curl request being sent.
>>>>>>>>
>>>>>>>>  If anyone could answer the following, it'd be much appreciated;
>>>>>>>>
>>>>>>>> * Should there be an improvement patch that exposes the domain of
>>>>>>>> the user that originated the blind transfer?
>>>>>>>> * Are there better/alternative ways to extracting the domain of the
>>>>>>>> user that originated the blind transfer?
>>>>>>>>
>>>>>>>> Many thanks
>>>>>>>>
>>>>>>>> Cal
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at freeswitch.org
>>>> http://www.freeswitchsolutions.com
>>>>
>>>> 
>>>> 
>>>>
>>>> Official FreeSWITCH Sites
>>>> http://www.freeswitch.org
>>>> http://wiki.freeswitch.org
>>>> http://www.cluecon.com
>>>>
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Anthony Minessale II
>>>
>>> FreeSWITCH http://www.freeswitch.org/
>>> ClueCon http://www.cluecon.com/
>>> Twitter: http://twitter.com/FreeSWITCH_wire
>>>
>>> AIM: anthm
>>> MSN:anthony_minessale at hotmail.com
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org
>>> googletalk:conf+888 at conference.freeswitch.org
>>> pstn:+19193869900
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121230/4451b3bb/attachment-0001.html 