I got an email from my phone company about fraudulent calls. I don’t expose the system to the internet so they are dialing in and then dialing another number over the phone. I’ve had it before where they guessed a SIP extension password and made calls that way. But that isn’t the case here since I don’t forward any ports from the firewall. I don’t use DISA. Any thoughts by looking at the logs?
Take a look in extensions_custom.conf sip_custom.conf manager…etc if you’ve got anything weird or unexpected.
Why not if there’s some devices forwarded somewhere.
Check if your system accepts any anonymous sip and calls. It should not!
Think to update your system (O.S + FreePBX modules) as well!
Another important thing to check is your voicemail PINs. Fraudsters will sometimes leave a voicemail from a spoofed international number, then use weak voicemail PINs to call back to the number that left the voicemail through the voicemail system.
1 Like
danardf:
extensions_custom.conf is blank. Same with sip_custom.conf. I do not allow anonymous sip calls. I do have some module updates to do but I was hoping to test the issue by doing what these people were doing and then patching to make sure that fixed it. I still can’t figure out from the logs what they are doing.
jsmith:
I don’t think I provide voicemail access from the outside. And since I don’t expose SIP to the outside, I dont’ think that could be happening.
Did they dial something special to get inside and then be able to dial any number? I’m having a hard time following the CDR report. Would me posting the asterisk logs be more helpful?
Below is the log from the day they were making the calls. And here are the bad numbers they dialed.
8769263700
8764100943
8766191578
4734028440
6493477814
2687700939
Someone is using ## or *2 to do a transfer. You have Dial options of Tt set which allows transfers from caller or called party.
[2020-01-12 00:53:52] VERBOSE[20234][C-0000087c] pbx.c: -- Executing [s@macro-auto-blkvm:8] ExecIf("Local/17172937715@from-internal-0000025a;1", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=)") in new stack
[2020-01-12 00:53:58] VERBOSE[20236][C-0000087c] res_musiconhold.c: -- Started music on hold, class 'default', on DAHDI/1-1
[2020-01-12 00:53:58] VERBOSE[20236][C-0000087c] file.c: -- <Local/17172937715@from-internal-0000025a;2> Playing 'pbx-transfer.ulaw' (language 'en')
[2020-01-12 00:54:05] VERBOSE[20279][C-0000087c] pbx.c: -- Executing [18769263700@from-internal-xfer:1]
This issue was discussed in another thread, which I can’t find at the moment. Depending on the complexity of your dialplan, there are more opportunities for someone to bypass the safeties and use the transfer codes.
As @billsimon said.
It appears that the incoming call is being forwarded to an external 717-293-xxxx number, using DAHDI (which lacks answer supervision). So, the call appears almost immediately answered and as an outgoing call, which allows the transfer.
You can confirm the vulnerability by calling in from your mobile and pressing *2 or ## while the forwarded-to number is ringing.
Then, set Asterisk Trunk Dial Options for your trunks to (blank) (remove any T or t from the list). Submit, Apply Config, retest to confirm that *2 and ## are ignored.
Of course, this prevents the use of these codes to transfer calls. Assuming that you have IP phones with transfer buttons or softkeys, you should not need these codes.
yep indeed.
[2020-01-12 00:53:48] VERBOSE[20234][C-0000087c] res_agi.c: -- dialparties.agi: Added extension 17172937715# to extension map
[2020-01-12 00:53:48] VERBOSE[20234][C-0000087c] res_agi.c: -- dialparties.agi: Extension 17172937715# cf is disabled
[2020-01-12 00:53:48] VERBOSE[20234][C-0000087c] res_agi.c: -- dialparties.agi: Filtered ARG3: 17172937715
[2020-01-12 00:53:52] VERBOSE[20234][C-0000087c] pbx.c: -- Executing [s@macro-auto-blkvm:8] ExecIf("Local/17172937715@from-internal-0000025a;1", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=)") in new stack
[2020-01-12 00:53:58] VERBOSE[20236][C-0000087c] res_musiconhold.c: -- Started music on hold, class 'default', on DAHDI/1-1
[2020-01-12 00:53:58] VERBOSE[20236][C-0000087c] file.c: -- <Local/17172937715@from-internal-0000025a;2> Playing 'pbx-transfer.ulaw' (language 'en')
[2020-01-12 00:54:05] VERBOSE[20279][C-0000087c] pbx.c: -- Executing [18769263700@from-internal-xfer:1] Macro("Local/18769263700@from-internal-xfer-0000025b;2", "user-callerid,LIMIT,EXTERNAL,") in new stack
Inbound callers exploiting the in-call transfer feature codes was a known issue a few months ago and resolved in core versions 14.0.28.19 and 15.0.9.46.
1 Like
Once again, need to update systems as often as possible.
In-call transfer (by DTMF) is a specialty function that is needed by very few users. In addition to security issues, the feature sometimes interferes with DTMF control of a remote system or results in loud beeps being played to a caller. Metadata displayed on the transferring phone is often inaccurate.
IMO, these features should be disabled by default for new installs.
If needed, it should be enabled only for the required path. For example, if you use Follow Me to forward some calls to mobiles who need to transfer calls, do that via a ‘special’ trunk with the ‘t’ option, so the authorized mobile user can perform the transfer. Normal outbound calls should not have that option, otherwise the callee could trick the caller into placing him on hold, then make a fraudulent call via *2.
1 Like
There is a ticket open with this suggestion; please vote for it. [FREEPBX-20583] Disable in-call transfer and disconnect functionality by default - Sangoma Issue Tracker
I might be wrong but is *2 (?? In-Call Transfer) required for Parking Lot? I remember in the past trying to have it work but could not without having *2 enabled. Our workaround is using the phone’s Hold - Transfer.
You guys are the best! I’ll test and confirm. Thank you so much!
Upgrading the modules took care of it. Thank you guys! Take care!
Don’t know about that but you if you are using FOP2 and performing attended transfers you need the In-Call Asterisk Attended Transfer enabled.
You can however change it to anything other but the well known default *2.
Parking Phone App does use the incall blind transfer code.
I’m not using that so I should be ok.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.