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.
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.
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.
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.
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?
