Hacker makes international calls through my FreePBX IVR

We fixed it an hour ago and stated it in here. The ticket is also open for all to see.

And commented on, again, thank you for paying attention. That is all from me, Problem identified and hopefully fixed.

You released it into the Edge Track? Isn’t this important enough to release into the Standard Track?

Given the concern has been around as long as time, and Andrew pulled together a quick fix, I believe the edge track is the appropriate place to release it and make sure there are no side effects.

I swear this was discussed long before Andrew was on the team there… and it pops up every now and again.

1 Like

I guess it can stay in Edge for a short while - things like this just give FreePBX a bad name - I audited about 20 of my boxes just to make sure I had remembered not to enable T on Trunk Dial - and I had, but still it gave me a bit of a jolt when I read this thread - and Google has already found this thread.

It seems like a script-kiddie level exploit, but still, it would be a bummer if a bunch of boxes were hijacked waiting for the fix to be applied - and is it going to be pushed back into 12? 11?

If it’s not going to be back-ported, I guess its a strong reason to upgrade, but in my experience almost no one updates these PBX’s once they are in production - they are afraid to. So this is now a thing to scan for with an automated dialer and exploit?

One of the risks is that that the “bad guys” are also “clever guys” they read all the forums and pounce when they can . . . (call it it opportunism, even if the risk has been there since day 1, it will be likely be re-noticed)

I’ve switched to edge track and updated that one module. I’ll update if I see anything bad happen.

I also updated to core 13.0.72 on several of my boxes - our test box, our office box, and a customer that has a lot of less-than-competent people making changes.

It’s a nice bit of code Andrew - and perhaps fixes the problem once and for all - let’s all beat on it, and if it doesn’t cause problems, lets get it moved into Standard.

Can anybody weigh in on how hard it would be to back-port it to 12? 11?

Do you all keep stats on how many installed FreePBX 10, 9, and 8’s are still out there in the wild? I would be curious.

A note on edge. This is an issue as @dicko has pointed out can be resolved via configuration. If you feel an urgency please make the config adjustments. The fix is touching loooooooooong stable call processing code. This is the kind of thing that will blow up in someone’s face . this is exactly what esge is for. Anyone running the latest framework can pull the edge module immediately. Something like this needs the in depth testing that edge allows. Changing a tool tip could skip edge, touching a water main, we want to be sure there is no flood.

I already stated my stance on 12

The farther back you go the more complicated this becomes. It can be resolved via configuration. I just added some fancy code that allows internal to work whilist blocking external (inbound). It’s not being immediately pushed because it messes with some pretty advanced parts of the dialplan and @jfinstrom pretty much nailed why this is in edge and why it won’t be pushed into 2.11 or lower. Though I will review your considerations with @plindheimer tomrrow

Sounds good to me - sorry I didn’t see your statement on 12 - it’s a long thread.

1 Like

I am sorry, but I am still having a problem with understanding why denying “T” on an incoming call will ever be a problem to anyone. Please can someone explain why it screws up the FreePBX internal dialplan apart from possible malicious manipulation . Maybe I’m just stupid or just missing something the clever guys know about.

Like I said, I checked twenty boxes at random, and I had already removed it from all of them - and these are production boxes and I have heard no complaints - but I only use SIP phones - no Analog sets or softphones that don’t have a transfer button - maybe I am missing something also.

I believe the problem is that the setting combines these two things (from the hint/pop-up text in FreePBX 13 on Asterisk Dial Options)

“Options to be passed to the Asterisk Dial Command when making internal calls or for calls ringing internal phones.”

(emphasis added)

When you are making internal calls, it would be valid for the caller or the callee to perform transfers. When a call comes in from outside and rings an internal phone, it is not appropriate for the caller to perform transfers.

I think that Andrew’s patch is good, or separate these two options, just like the outbound trunk dialing Dial options are separated.

1 Like

Actually, I’m not getting any email notifications from FreePBX’s JIRA or from the FreePBX forums (even though I double checked my profile lists my email address correctly), so I never knew about your request for more information. EDIT: I received all of my messages between 6pm 13 April 2016 (yesterday) and 4am today! I was busy trying to learn the dial plan syntax so I could figure out what could have been the issue. But we’ve discovered it now.

Thank you for addressing the issue, limiting the T option to inside users.

I (and some employees) listened in on a few of these fraudulent calls and it was clearly a shady calling card service piggy backing on unexpecting Asterisk users (I won’t say FreePBX, since I’m sure every Asterisk based system leaves that “T” in by default for the users that actually DO need it.

I’m only glad this is now posted on many forums so that users can discover what is going on. (I couldn’t find ANYTHING online exposing this issue, and it is not listed on any “Best Practices” for Asterisk or FreePBX).

Grrr. I can’t respond if I don’t get notified until 6pm a day later… actually I don’t think I ever got a notice for the JIRA comment.

I strongly urge anyone reading this thread to NOT apply patches that are being presented to “fix” this from “Andrew” (me) in FreePBX 12 from other forums. I have looked over other forums said patches and have determined that they are only less than half of the required patch and furthermore that they will give you a false sense of security when the underlying issue will still be there.

The correct patch is in github or above and requires changes to more files than just dialparties.agi

Thanks.

Andrew - to clarify your last note. You’re still confident in the “edge” patch you applied to 13?

Yes. The patch that was released in another forum only patched dialparties.agi

This was just a clarification for non-developers who do not understand the code. We don’t expect non-developers to know the code or even look at the diff’s to see what actually changed. In some cases you can slap code between versions and it will work as intended. This is not one of those cases.

1 Like