I might be out of touch on how this is used so please weigh in. In-call transfer features (## and *2) seem to be legacies of analog and are uncommonly used in modern VoIP systems other than to be exploited for fraud. Pretty much any SIP phone can do blind or attended transfers using SIP methods, so these inband functions are not needed.
My proposal is to disable the in-call transfer functions by default on new installations of FreePBX. Disable these settings:
I would support such a petition. I suspect the vast majority of users are not using these features, so the incremental improvement in security will probably outweigh the inconvenience to those who donāt realize they need to be enabled before using.
I recommend filing a feature request once discussion here dies (if it even starts).
I use them from time to time, but the default being the more secure choice is something I can support. As long as we can turn them back on, Iām all for it.
While InCall transfers are more for analog or those using feature codes as their main way to do things because of a crappy phone or not wanting to learn new things. They can be used for macros on phones to help with one-touch or shortcut type soft/line keys to do transfers, etc.
That said, the only way the InCall transfers can work is if the T or t options are set in the Dial() string. That only happens with internal facing Dial()'s. Now since an external call can be bounced around and still be sent out the trunks for any reason (FM, etc) there is this setting that is on by default:
At that point as long as the call has all the proper flags/variables set on it the system will strip/remove the ability to have the T option (called party can transfer) since the called party is external and at that point the calling party is either an extension or local channel.
Honestly, Iāve never seen an incident where InCall transfers have caused fraud. Iāve seen people opening up themselves to allow external callers to set CF and others things (DISA) so thatās happened. Plus Iāve seen it where a device gets compromised or the account is and they setup Call Forward on the account to send the calls somewhere.
But as it stands unless someone really screws with settings, adds custom stuff without consideration or turns off this protection the system already has mitigation for stopping what you are referring to.
External call comes into the PBX that is Channel A, now in order for InCall transfers to work there must be a answered and bridged call. So now the caller needs to be sent somewhere that answers the call. Where would that be? An IVR? Queue? Extension?
Even then theyāll hit *2 or ## which will now put the called channel (Channel B) on hold and then dial Channel C. So if that call passes all the routes and goes out to the PSTN when itās all said and done the caller has to complete the transfer and then Channel B is transferred to Channel C.
How is that fraud call going to happen? What is Channel B active on? At this point the Channel C has zero ability to do any type of transfers themselves and I guess Channel B could if it was an actual person. However, at that point you have bigger issues to deal with.
Letās been clear, Iām not questioning/arguing for/against disabling or leaving InCall transfers enabled by default. Iām rather indifferent on it. The reasoning behind it though, that is what Iām questioning.
There are not enough details to say for sure that this was an inband transfer exploit, but itās plausible. Anyway, itās what the user claims, and should be tested thoroughly.
I would hope that āDisallow transfer features for inbound callersā is water-tight, but I can be absolutely certain of it if inband transfer features are disabled globally.
I would classify this as belt and suspenders. Should the belt fail at some future date for any of a dozen unknown possible reasons, the suspenders pick up the slack. Shouldnāt be necessary, but nice to have in case it is.
Set original setup of the inbound route that has been used was:
InboundRoute -> Misc Destination -> Call to a number
Misc. Destinations will dial something as if they are an internal caller which, right there, makes all that stuff for āinbound callersā moot. I got back to my previous statements about the users doing stuff to allow things to happen from external callers.
Which means the ticket opened against this issue is also under that.
KEYWORD:INBOUND_NOTRANS
Disallow transfer features (Normally ## and *2) for callers who passthrough inbound routes (Such as external callers)
Hereās the tool tip for Misc Destinations:
Enter the number this destination will simulate dialing, exactly as you would dial it from an internal phone. When you route a call to this destination, it will be as if the caller dialed this number from an internal phone.
Pretty subtle; I would call it a booby trap. More compelling reason to disable internal transfer features globally by default.
That means something wrote to the AstDB either wrong or on purpose like that because when the checks are made against the DB and external calls have the AMPUSER variable not set, it will pull those and use those if called upon.
This is something else that needs to be looked at. Iām unaware of a way an external caller can write things to the AstDB.
Caller called in and initiated a transfer by doing ## or *2. Then the caller dialed *75 (default feature code for adding a speed dial) followed by numbers to set up each of the speed dials that got written to astdb.
In the ticket he put a comment saying that he can also do transfers when the inbound route is sent to a queue and not to Misc Dest. I have not tested that myself, but if so, thatās clearly a bug and not a user mistake.
Here is my theory on this: Itās a Queue. When the caller is put into the Queue, that is where the caller is. When the Queue is calling the agents the call is via Local channels from the Queue to the Agents.
Now when that Local channel calls the external number itās from the Queue so all the variables that hold this is an external call are not there. So now when the Queue then merges those calls together they are now bridged and the ONLY WAY this call can be use InCall Transfers is if the Dial() to the external agent allows it.
Since this is an external agent one can theorize that this agent, like their internal counter parts, will need to be able to transfer calls they made or received. This would require calls out the trunk to that external agent to actually have the Tt options on it to facilitate this.
So far this is not sounding like a bug but a poorly setup method of handling external agents.
I am the one created the ticket and the post. I have updated the ticket with a trace but I am starting to believe that for some reason channels are swappped. For now on all of our installations we have disabled unneeded feature codes (including ## and *2)
Is it possible that you could make a list and post here of the other unneeded feature codes you disable by default (in particular, those that are exploited by unsavory characters)?
What @lgaetz said. Its different for each of our clients. For some I disabled all features code, for some only the call forward codes.
If you ask what are the feature codes that could be exploited most, these are, in my opinion, the call forward, speed dial and in call tranfer codes. But as I said, it depends on the client.
On most systems, you can press Transfer, dial extension, hear voicemail, press Cancel and be back with original caller. What kind of phone is help desk using? What goes wrong using normal Transfer key?
Can you put a call (picked up from the queue) on hold (with the Hold key), then resume that call? If not, then there is a bug in the queue logic. Otherwise, something must be wrong with the Transfer logic, because an uncompleted transfer should appear to Asterisk as nothing more than a call placed on hold and later resumed.
In your failing case, what does the help desk user see after the cancel? Does he have an option to resume the original call? If so, what does he hear and see when he presses it?
