Summary:	ASTERISK-09872: Important vulnerability after native transfer: the transferred gets context privileges
Reporter:	Iñaki Baz Castillo (ibc)	Labels:
Date Opened:	2007-07-13 03:47:15	Date Closed:	2007-09-01 16:04:13
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Any common company using a PBX needs: - Calls between local users can be transferred in both directions --> tT - Outgoing calls can be transferred just by the local caller --> T In Asterisk this is a simple context/dialplan for that common need: ---------------------------------------------------------------------------- [users] ; In internal calls we want bidirectional transfer -> tT exten => _2XX,1,Dial(SIP/${EXTEN}|60|tT) ; In outgoing calls we just want transfer by the caller (us) -> T exten => _6XXXXXXXX,1,Dial(Zap/1/${EXTEN}|60|T) ---------------------------------------------------------------------------- This means: we DON'T want that a external called could transfer us. Now imagine this common scenary: - SIP/200 calls to a mobile 666777888    Dial("SIP/200", "Zap/1/666777888|60|T") - They speak for a while and 200 wants to transfer him to 201. 200 can transfer because the Dial had "T". It doesn't matter if the transfer is blind or attended:    Transferring Zap/1-1 to '201' (context users) priority 1    Dial("Zap/1-1", "SIP/201|60|tT") in new stack    <--- **** "tT" !!! ****    -- Called 201 - 201 answers and starts a conversation with 666777888. The BIG vulnerability is that now the mobile CAN transfer by pressing the DTMF code of features.conf for blind/attended trasference:    Started music on hold, class 'default', on SIP/201    -- <Zap/1-1> Playing 'pbx-transfer' (language 'en')   <------ !!!!!!!! This means that the remote called can transfer us by calling to any number available in [users] context, that generally are all the numbers in the world. This is a important issue that can cost money for people/companies using Asterisk. I've checked this bug and more people has done it in their Asterisk. You can check it just with the simple dialplan of above that I think is very common. A solution could be to check the Dial parameters after a native transfer and sure that the called doesn't get privileges it shouldn't have. Hope a solution for this. Best regards. ****** STEPS TO REPRODUCE ****** Explained in the description, just modify the dialplan of [users] context for your enviroment.
Comments: