IVR And Feature Code Exploit

[BlazeStudios (Tom Ray)]

I’m not a 100% sure what we are testing since this is all become a pile of crisscrossed information and details.

The focus seems to be stuck on the IVR and an exploit expect so far nothing has actually shown that. The initial logs provided are showing calls being Originated via Local channels from the PBX out the SIP trunk to this destination. Nothing shows this happening via an Incoming call to the PBX that is hitting the IVR and then a transfer is happening. Not only that, it shows a lot of calls happening in succession via Local channels.

Now it very well could be the PBX was setup to with Tt as dial options for both the PBX dialing “internally” and outbound calls and this was the immediate jump. But nothing supports this IVR exploit theory. It seems more attention is being paid on the witness statement then the evidence. So let’s look at the evidence, shall we?

1. Calls are being originated via Local channels and in rapid succession.

2. The CDR/CEL does not show this being Inbound or hitting an IVR.

3. There is zero Transfer events in the CEL of this call or in the traces of it. There would be an ATTENDEDTRANSER or a BLINDTRANSFER event listed in the CEL.

4. Incoming calls to trunks shouldn’t be using from-internal context.

5. The original trace shows that your outbound trunk was allowing In-Call Transfers for both caller/callee.

[2018-11-03 03:38:11] VERBOSE[20825][C-0000ba84] pbx.c: Executing [s@macro-dialout-trunk:23] Dial(“Local/20025284071821@from-internal-000039b3;2”, “SIP/TRUNK-SEEHOA/0025284071821,300,Tt”) in new stack

6. Your original trace and your “testing” trace show completely different call flow paths and data being logged. Your test shows how a call enters the PBX from the PSTN and the original trace is showing a call that enters the PBX via a local command/AMI/ARI or how a user makes a call (from-internal).

7. Transfers do not use Local channels. A new channel is created and then a REFER is used to make the channels swap and join the two parties together.

I think you are conflating the IVR/In-Call Transfers (which you seem to have enabled) and what is actually happening here. Because even if Local channels where some how being used, the amount of calls that were happening and as quickly as they were happening would mean multiple and simultaneous incoming calls to your PBX/IVR, all quickly and faster than a human can transferring calls right back out your SIP Trunk.

So is there proof in your CDRs or other logs that (based on your first trace at least 6-8 calls at once) almost 12-16 calls where happening at once on your PBX? Because there would be the inbound and then the “transferred” outbound call in the logs.

[Stewart1 (Stewart)]

@xtranetcc

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.

Are you certain that the system you are using for making the test calls doesn’t have the T option enabled for the trunk? If it did, then your *2 would be interpreted by the calling system and it would transfer your call (not an ‘exploit’, just a normal call transfer). Of course, you would see the transferred-to number in the CDR for the test system.

Otherwise, is your test system also using a Seehoa trunk? If so, the provider may be specially handling calls to numbers on their own network (bypassing the PSTN) and the resulting INVITE sent to the destination system may have an anomaly that is triggering the exploit.

Finally, it would be very useful if you could explain the big picture to us. Where are you (South Africa, Somalia, somewhere else)? Who are you (working for Simbithinet, Seehoa, a contractor providing systems to owners of SEE properties, etc.)? Is the Somalia number in your logs someplace that you would normally call, or just a number chosen by the attacker? Do you have any other trunks you could use for testing, either on the calling system or the system being called?