I could not make sense of your log. It starts with an outbound call; a quick search did not find any reference to an inbound context.
However, if you have IP phones (or softphones with transfer functionality) and don’t need the DTMF-controlled transfer features, simply disable them. In Advanced Settings, set: Asterisk Dial Options: r Asterisk Outbound Trunk Dial Options: (blank)
Submit, Apply Changes, test.
IMO, transferring calls via DTMF is a specialty function, e.g. if you want to allow an incoming call sent to a mobile phone (follow-me, forwarding, misc destination, etc.) to be transferred by the mobile user. Otherwise, keep it disabled. In addition to security issues, it can interfere with DTMF control of remote systems or result in loud DTMF beeps being heard by the connected party, and adds needless load to the system.
That was the first setting i changed, view below…but i am still able to dial in and while
the ivr is playing i dial *2destination and the call goes through.
So i thought maybe the GUI on this PABX wasnt writing to the core asterisk files, so i tested it on 2 other
installations and changed those 2 settings, and the result was the same, as successfull call via the IVR.
Is the context for your incoming trunk correct? If it’s set to from-internal, that’s a serious security vulnerability, even without transfers enabled.
Please make a test call and provide a log showing the problem. Make the call from your mobile (or another phone not on your PBX). The log should start with when Asterisk first sees a call on the incoming trunk.
The reason it looks like an outbound calls is because it is an outbound call. These calls are being generated from the PBX via Originate commands. This is being dialed via a Local channel which is what Asterisk uses for originating calls. This could be a FollowMe or some other function (like Ring Groups) that uses Local channels to initiate calls.
These are also being generated back to back to back. So now the big question, does TRUNK-SEEHOA actually exist and it is yours? Because they are not only going out that trunk, they are going through your Outbound Routes and matching.
[2018-11-03 03:41:33] VERBOSE[C-0000ba8b] pbx.c: Executing [[email protected]:4] ExecIf(“Local/[email protected];2”, “1?Set(TRUNKCIDOVERRIDE=000000000000)”) in new stack
I agree with @BlazeStudios analysis. It shows outbound calls to Somalia and raises several questions.
Is the initial ‘2’ an intentional trunk access code on your system? If not, it’s been compromised (presumably over the internet) by an attack unrelated to the transfer vulnerability.
As a secondary security measure, it’s good practice to restrict outbound calling, e.g. allowing calls only to countries you need to call.
But in any case, you were writing about an inbound call being inappropriately transferred to an external destination. Your log needs to show the inbound call and how it is handled – if you start with the outbound call made by the attacker, the important information is not present.
Sure, but the OP stated that he could call into the system (and two other installations) and transfer to an external number. A log of this attempt would almost certainly show the incoming leg and indicate whether the behavior was caused by malicious modification.
For centuries, Somalia has been famous for piracy. It appears that they are moving from ships to chips.
Is http://www.simbithinet.co.za/ relevant to the OP? If so, please describe your role. Are you representing Simbithi, the HOA, or a business with property in the Estates?
Yes, Trunk-Seehoa is the trunk to my voip server for outbound calls.
Here is my test call log from earlier : https://pastebin.freepbx.org/view/4abf4cc1
It is not a compromised box. Like i stated above, feature codes on trunk is disabled under advance settings, yet it works on this install and 2 new installs we have done.
One of the latest boxes we did didnt have any ivr, so i went as far as setting up a test ivr, changed the advance sip settings to disable dtmf on the trunks. I dialled in and dialed *2destination# and the call went through.
Third pabx i tested had an ivr, without changing anything, i tested the exploit and it worked. I then disabled dtmf on trunk and the *2 and ## and tested, call via *2destination# and it worked.
Note i am testing the exploit from a Freepbx server with a Yealink handset. I tried the exploit from a mobile phone and a standard analogue line and it did not work.