[Freeswitch-users] Outbound call limit bypass prevention

[Brian West]

Or you could just set limit_ignore_transfer=false 

https://wiki.freeswitch.org/wiki/Limit#Variables_that_affect_limit

limit_state_handler in switch_limit.c

 
--
Brian West
brian at freeswitch.org
FreeSWITCH Solutions, LLC
PO BOX 2531
Brookfield, WI 53008-2531
Twitter: @FreeSWITCH , @briankwest
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com

T: +1.918.420.9001  |  F: +1.918.420.9002  |  M: +1.918.424.WEST
iNUM: +883 5100 1420 9001
ISN: 410*543
Skype:briankwest
PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)













On Mar 3, 2014, at 3:09 AM, Dmitry Sytchev <kbdfck at gmail.com> wrote:

> Hi all!
> 
> <intro>
> If you use FS or other softswitch with to provide services with limited amounts of concurrent calls and have enabled REFER method for your SIP users (you may disable it by disable-transfer in profiles, default false), your setup may be vulnerable to call limit bypass attack.
> 
> For example, someone stoles credentials or bruteforces account password of your SIP user and sends an amount of calls to premium numbers or longdistance directions. These attempts should be at least limited with customer call limit, but there is a method to bypass it.
> 
> When attacker sees the call limit is set on account, and call limit > 1, he tries to bypass it to increase speed and amount of outbound calls. He makes one outbound call, then makes second. At this moment there is four channels - two inbound channels to FS, and two outbound channels from FS to PSTN or SIP gw. FS sets call limit usage to 2.
> Now attacker issuing transfer request by sending REFER to bridge two outbound channels with each other. After successful transfer, two inbound channels are destroyed and outbound channels are bridged together. After that, FS decreases call limit, since it destroyed channels limit was set on.
> </intro>
> 
> The problem is the method people often use to limit concurrent calls. Something like that:
> 
> <action application="limit" data="hash OutboundLimit ${pbx_subscriber_customer_id} ${pbx_customer_call_limit} !CALL_REJECTED"/>
>  <action application="bridge" data="{ignore_early_media=false,hangup_after_bridge=false}sofia/gateway/gw/$1"/>
> 
> Now limit is set on inbound channel. When attacker bridges outbound channels, their A-legs (inbound channels) get destroyed and FS decreases limit due to channel destruction. So attacker have 2 outbound bridged channels, and limit is still 0. Then the process repeats, allowing attacker effectively bypass your call limits.
> 
> One of possible solutions is to move limits on B-legs after answer, while keeping limits on A-legs too in order prevent exceeding limit by unanswered calls:
> 
> We set limit on A-LEG, then on answer we decrease limit on A-LEG and "move" it to B-leg by calling limit on outbound channel.
> 
> <action application="export" data="nolocal:execute_on_answer_1=set api_result=${uuid_limit_release(${uuid} hash OutboundLimit ${pbx_subscriber_customer_id})}"/>
> <action application="export" data="nolocal:execute_on_answer_2=limit hash OutboundLimit ${pbx_subscriber_customer_id} ${pbx_customer_call_limit} !CALL_REJECTED"/>
> <action application="limit" data="hash OutboundLimit ${pbx_subscriber_customer_id} ${pbx_customer_call_limit} !CALL_REJECTED"/>
> <action application="bridge" data="{ignore_early_media=false,hangup_after_bridge=false}sofia/gateway/gw/$1"/>
> 
> Now limit is correctly evaluated for non-answered outbound calls, and doesn't allow excessive calls.
> 
> Hope this helps somebody. Maybe you guys know more effective and correct ways to prevent limit bypassing in this scenario?
> 
>                 
> 
> 
> 
> -- 
> Best regards,
> 
> Dmitry Sytchev,
> IT Engineer
> _________________________________________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140303/7ba2754c/attachment.bin