Unwanted calls from extension

FreePBX Security
1

Hi,

I use FlowRoute as our trunk provider and they sent me an alert of suspicious calls, so I went to check our CDR reports in FreePBX and realized there were calls being made from several user extensions to 715 and 641 area code numbers that we were not making.
I have checked with FlowRoute and they advised that the traffic was coming from just one IP address, which is our phone server’s IP, so most likely it was an issue with our FreePBX configuration.
We use the userdevice mode, so since then I have deleted any unused extensions and devices, updated all of our extension passwords, device secrets, reset our trunk password, disable transfer feature codes *2 and ##.
After doing this, the majority of extensions stopped making these calls, but I still have two extensions presenting this behavior.
What could be causing this?

I am pretty new on this, so I would need a little guidance on where to look to discover what is exactly causing the issue and try to fix it.

Thanks!

2

That’s not true. FlowRoute will always see your FreePBX’s IP, unless you are for some abnormal reason including the IP address from the original caller’s endpoint in the SIP headers.

Since you are using devices and user mode, I assume you are using a older version of FreePBX. What version are you using?

Your concern should be how the attackers got the password.
Were the password generated by FreePBX? If so, how many characters are there in the password?

Are you in someway provisioning these devices? (AFAIK, D&U mode isn’t supported in EPM in newer versions) if so, is port 80 or whatever port you are using exposed to the world wide web?

Do you have the FreePBX firewall and fail2ban running?

Is there a chance they have compromised your server and that’s how they have the passwords?

The reason I am asking all these questions, is as mentioned, you must know how they got the password. If it was a simple brute force attack, then changing your passwords and tightening security/restricting access is the solution.
If they exploited your system over http or they actually compromised your system and it is not behind a firewall, then there’s no point in changing passwords.
If your system is being a firewall, stop and block any remote sessions until you have hired a professional to clean up the mess.

3

Hi @PitzKey, thanks for your response. You are right, I meant FlowRote said the traffic was coming from our FreePBX’s IP.

I am using the following:

PBX Version:15.0.16.76
PBX Distro: 12.7.8-2008-1.sng7
Asterisk Version: 13.36.0

The original secrets where the ones provided by FreePBX and I have used a software (KeePass) to generate new random long passwords.

Physical devices are provisioned using TFTP via End Point Manager and softphones are configured manually and remotely by me with the credentials on each user’s computer.
I checked our IP address with nmap and it says port 80/tcp open http.

Yes, FreePBX firewall is enabled and I added the known IP’s to the Connectivity > Firewall> Network tab. The responsive firewall is also enabled and fail2ban is running.

For international calls I use a different provider that asks me to enable the Allow Anonymous Inbound SIP Calls to receive incoming calls. They don’t support PJSIP and send traffic from different IP’s so this is why they ask that option to be set to YES. Can this be the reason that these unwanted calls are being generated?
I found that there are also calls several calls from random extensions that don’t even exist 100, 201, 7001, etc.

Thank you very much.

4

I took a brief look at the log and suspect that the fraudster may not have stolen SIP credentials, but rather exploited an issue related to call transfer, forwarding, access via voicemail, etc.

Although the call appears to have been made from extension 5963, the caller ID is set up as ext. 3984. Unless this is part of your setup, it’s worth looking at the log just prior to 14:30:46 to see whether an incoming call triggered the fraudulent one.

If not, check whether the log shows any registrations for 5963 (Asterisk outbound calls don’t require registration, but some fraudulent calling software registers anyhow).

Assuming that your physical devices are on your LAN make sure that TFTP is not accessible from outside. If you have remote phones, you must convert to a secure provisioning protocol.

Also, make sure that your provisioning data is not accessible from outside via another protocol. For example, your phones are provisioned with TFTP (properly locked down), but the same data is accessible from the outside via HTTP (bad news).

It would require another configuration error, but those are common so it’s certainly possible. I looked up your UK number and it appears to be with AQL, is that correct? I couldn’t quickly find it, but I’m sure that they will give you a list of the IP addresses (or small netblocks) from which they send calls. Create a pjsip trunk and list those addresses in the Match (Permit) field. Of course, you have to tell the provider to send calls to your pjsip listening port.

These may be just attempts, rather than completed calls; check the log. If some of these did get through and managed to make outgoing calls, please paste an example and post the link.

5

chan_pjsip is not a different kind of SIP it’s the driver/SIP Stack asterisk uses and can work with any vendor.
I would turn off anonymous calls and feel free to work with us to properly configure that Trunk.

6

Where’s the logfile? Did I miss something?

7

Hi @PitzKey there was a log but I removed it since I wasn’t sure if it was safe to post that information here. Should I add the link again?

8

Hi @Stewart1. I have already disable forwarding feature codes *2 and ## and “Disallow transfer features for inbound callers” option is set to YES.

This is not how it should be setup. How would I check if an incoming call triggered the fraudulent one? How will that show in the logs?

Our phones are remote. I guess that way we are provisioning the phones may be the problem?
We have old Polycoms so I don’t think those can be provisioned via HTTP.

I checked with our provider Gradwell and they said they don’t work with PJSIP. They did provide a list of IP’s where they send traffic from, but they said they may change this at any moment and that is why they require the Allow Inbound Anonymous SIP calls option set to YES.
I am sure this is also affecting us greatly. Do you know any good sip trunk providers with good rates to the UK by any chance?

Thank you.

9

Yeah, I did a couple of tests to both your +1954 and +44203 numbers and the transfer functions were indeed blocked. Unfortunately, when attempting to check for voicemail issues, I was surprised that Kremena answered the line and I apologize for hanging up on her. I did not try the +44800.

If your system was not very busy at the time, manually inspect the preceding minute. Or, maybe you can find a fraudulent call made at a time when the system would be idle. Otherwise, search the preceding few minutes for 5963 and for 3984.

Ouch. You have Soundpoint IP 301, 500, etc.? If they are looking for e.g. 0004f2123456.cfg, that is very easy to exploit because the bad guys know the range of Poly MAC addresses and can just iterate through them until they get a hit. If they did this recently, you should find the attempts in /var/log/messages*.

The easiest fix may be to put the files in a folder with a ‘secret’ name, rather than directly in /tftpboot. This is probably sufficient protection from the criminals who scan every IPv4 address looking for a system to exploit, but may not be adequate if your breach was an inside job.

That makes no sense. If they specify the required authentication, headers, etc., you can configure pjsip to do that.

If they give you reasonable notice, even a few days, that shouldn’t be too bad. As you probably remember, Flowroute changed servers some months ago and sent out multiple notices, starting 90 days before the change. If they won’t do that, there may be a workaround if their portal allows you to specify the user part of the SIP URI to which they send calls. You could then have a custom ‘anonymous’ context that drops the call if the username doesn’t match. (You would fetch the called DDI from the To header.)

Unfortunately, what you need is good rates from the UK. I have an account with Voxbeam. It’s in USD but you can get one in UKP. Sample outbound rates on their Platinum (best) route are London fixed, $0.0025/min.; other fixed, $0.0051; major mobile (EE, Orange, Telefonica, Three, Vodafone), $0.0078-0.0092, billed in 1-second increments. However, their inbound rates are IMO way high at $11.50/mo./channel + $0.40/mo./number (no charge for incoming calls). They also offer numbers for $0.80/mo., limited to 2 channels, capped at 10,000 minutes/mo., with a $0.01/min. charge for overage. How many concurrent incoming calls do you have at peak times?

You might also look at AnveoDirect, a Voxbone (no relation to Voxbeam and recently acquired by Bandwith) reseller. $6.50/mo./channel + $0.64/mo./number, or $0.004/min. + $1.00/mo./number. I believe that their pricing is typical of Voxbone resellers.

10

Hi @Stewart1. Thank you so much for all of the valuable information and recommendations.
Our server only allows TFTP connections from local/trusted networks. It seems that our secrets had been leaked somehow, since we had registrations with valid credentials.

I thought I had changed all of the device secrets, but I had not updated ALL of them (Polycom secrets). I have now done that and also found there were some unused devices so I removed them. After doing this the 715 calls seem to have stopped.

Thanks for everything!

11

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.