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

[Cal Leeming [Simplicity Media Ltd]]

Sorry, I might have misunderstood but that doesn't clarify the potential
security flaw of using set_user.

I agree that the call needs correct context, but forcing a call from a
gateway to use the context of the user they are calling doesn't sound like
the right thing to do.

Am I missing something here??

Cal

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

> **
> No, you want to have a gateway user that you use that has the right
> context, so they can't dial out on their own, but the user CAN transfer
> them to something external if you want.
>
> --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 12:12:55 -0800
>
> *Subject:* Re: [Freeswitch-users] mod_xml_curl - missing dialplan
> variable (domain of originating user for blind transfer)
>
> >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
>>
>>
>
>
>
> _________________________________________________________________________
> 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/20121231/2db8c612/attachment-0001.html