FreePBX | Register | Issues | Wiki | Portal | Support

Hacker setting call forwarding?

freepbx
Tags: #<Tag:0x00007fcd22f9e1a0>

(David Johnson) #1

I have several FreePBX distro’s configured on VPS environments. Each of them have different phones and gateways installed on them. I have been noticing what I believe to be hacking or fraud attempts on my PBX configurations. I am running the most current patches on all systems (FreePBX 14.0.5.1) and patch regularly. I am not running adaptive firewall and each PBX is set to allow only the specific remote customer network to access them (and my office network for system management). The issue I have been seeing has happened both to a digital extension (i.e. VoIP phone like the VVX 4410) and an extension defined as one port on a Grandstream gateway (gxw4008). The issue I am having is as follows.

Occasionally, I discover that the phone or gateway extension has been forwarded to *720112250100345 and in every case the originator is 6313387799 (but I suspect this is spoofed?). Some how they are setting the same extension to call forward with *720112250100345 and then they call the extension in an attempt to have the PBX connect the overseas call. Fortunately my current system is configured to allow ONLY domestic calls so in this case the fraud is prevented.I am baffled as to how they keep setting the same extension to call forward to the number above? I have changed the password to the extension 3 times but they still manage to set it to call forward all calls to the overseas number. I now check every AM that NO lines are call forwarded. I have since just disabled *72 (dont need it) but I am baffled as to how they did this on a gateway extension and a specific VoIP extension on 2 different PBX systems? In one case they were able to set call forwarding within only a few hours of setting up a new server! My VoIP phone user says he could see the 011 calls coming in as well and when he answered it no one was there (phone would ring, 011 was displayed, he picked up, no one was there).

I suspect there is some process where they may have gleamed the MAC address of the extension/phone and are using TFTP to download the config and parsing it? (could explain why its always the same devices? out of 100 phones/gateway ports, its always the same 2) Any suggestions?

  1. How do you password protect TFTP on freePBX? I read text on protecting FTP and HTTP but not TFTP?
  2. On a standard Distro, running the regular install script, are there any internal passwords one much change when setting up a new system? I only changed the root and admin passwords as prompted in the install.
  3. I want to open up locations by enabling adaptive firewall but I am worried, I cant seem to keep the closed system secured, let alone something open to any IP address.

(Lorne Gaetz) #2

You can’t password protect tftp, and as such it’s completely unsuitable to expose tftp to any untrusted traffic. You need to lock that down asap. If your extension secrets have leaked, there will be evidence of spurious registrations in /var/log/asterisk/full with lines like this:

[2018-11-20 08:36:42] VERBOSE[29084] chan_sip.c: Registered SIP '2002' at xx.xx.xx.xx:xxxx

where the x’s represent the IP and port of the malicious user. If using PJSIP, the log line will be different but similar.


(Tom Ray) #3

Has it been considered that if you have updated that extension’s password (and thus the phones config) three different times and each time it is being hacked but no other accounts are, the phone or user in question themselves have been hacked?

To dial *72 (or anything) and the PBX to accept it, the other side needs to auth. That is unless you are using Chan_SIP and have allowguests=yes in which case, you let anyone in. If this is setup correctly then that *72 request is going to be challenged with a 401 Unauthorized and they are responding back with proper auth.

You should 100% verify that the phone itself is OK. The “Hacking phone, setting up CF to high cost destination” scam has been happening since the beginning of VoIP being a public service.


(David Johnson) #4

ok, if I “lock down” TFTP what do I use in its place? Also, keep in mind, I have the firewall set to only speak to the customer IP and my IP, doesn’t this include TFTP? How can they TFTP download my config if I have the firewall enabled and only specify 2 networks as permitted?


(David Johnson) #5

How does one hack 1 port on an 8 port gateway? How can 1 user be hacked when I changed the password for that 1 users account (i.e. SIP registration for the extension)? Please explain “the user has been hacked” position above,


(David Johnson) #6

/var/log/asterisk/full only shows registrations from the customer’s IP. I only see todays date in this file, do I need to enable something to allow the file to grow larger or is there another file that has more historical data.


(Tom Ray) #7

full log rotates there should be full-YYYYMMDD for the last four rotations in there.

grep <pattern> /var/log/asterisk/full*


(David Johnson) #8

Yes I saw that, only 7 days of data, I need to go back further than that to locate the initial attack…


(Dave Burgess) #9

The problem isn’t necessarily in your system. If I was a betting man, I’d guess that the remote user’s system has been hacked. Since they then have access to your local network, they can do a lot to make mischief in your network.

I’d reset the Call Forward on both problem children on your end, then start a ‘tcpdump’ (or similar) to watch when the options get reset. Limit the dump to the IP address of the suspect network, and review the file often.

Note that asking us hypothetical questions without any other information isn’t a great way to get support. We can help you is you help us by giving us clear descriptions of the configuration of the gateway and the phone, as well as telling us about the config of the extension.

One way that jerks can get access to your network is through interaction with UCP. If you are using UCP for this particular account’s access, you might try changing the UCP password for that user.

The more I read on this and the more I think about it, I have little doubt that this is a hacked trusted account and that all you can really do is try to limit the damage until they fix their environment.


(David Johnson) #10

I doubt the remote system has been hacked (at 2 separate networks, i.e. 2 different clients) the only thing common is they each have phones connected to a remote PBX running FreePBX. The FreePBX servers are on two different VPS machines, separate instances, different password, installed on different dates. They are both using similar end user hardware (polycomm VVX 410 phones, Grandstream gateways of various models). All devices are configured in FreePBX to download and use the latest version of the firmware available in endpoint manager.

I don’t know how much more detail I can give. The admin passwords for all devices were set to non-default values when installed, the user PIN was changed at install, I didn’t have any UCP setup at the time but I added a UCP login for the extension that keeps getting call forwarded so I can unset the feature remotely (freepbx needs tomake this easier to clear). Both the polycomm and grandstreams are setup using chan_sip. Usernames are the extension (7 digits) and the passwords are really long auto generated when the extensions were added. No special configurations and both the phones and gateways involved were configured from factory default condition.

In extensions I added the phone or gateway, gave it a name, long auto generated password, under advances added NAT, and on the “OTHER” tab added the brand, MAC, template, model, and which account to use (on phones its account 1, on the gateways the account number is the port of the gateway)

Out of 100 phones mixed between polycomms and ports on the gateways, its always the same 1 phone and 1 port on 1 gateway. I have a few dozen phones and at least 5 gateway devices (gxw4008, gxw4216, gxw4224, gxw4248) buts its always the (1) polycomm and port 3 of a specific gateway that keeps getting forwarded. I have changed the SIP registration password for the extension several times and the hacker has managed to reset the call forwarding again several times (again, always the same extension in each case, on system A its gateway port 3 extension x7902 and on system B its the polycomm vvx410 extension x9290).

My firewall is enabled, I do not have adaptive firewall enabled, I have a very short list of networks trusted and my PBX LAN interface Zone is set to Internet. I have fail2ban enabled 4 tries in 600 seconds, ban for 1800 seconds.

Currently I have disabled the codes for all call forwarding options, my SIP provider is configured to allow only US48 state calls, and my dial plan only allows 7 digit extension and 10/11 digit external (i.e. 1-NPA-NNX-XXXX or NPA-NXX-XXXX) calling but I suspect they will just look for another vulnerability.

What else can I provide to help? What log files? What should I look for? I want to roll out thousands of extensions and would need to enable adaptive firewall since some remotes will have DHCP addresses but I need to be more assured it will be secure. I would really like to figure out how they are doing it so I can not only block it but better understand what the vulnerability is.


(Tom Ray) #11

OK so let’s cover some basics

In order for CF to be active at the FreePBX level it has to exist in the AstDB as /CF/{ASTUSER}/{CFDEST} and there are only a few ways that can be done.

  1. Feature Code is used.
  2. UCP is used
  3. AMI command is used
  4. database command from Asterisk Console is used

In order for #1 to happen the user must call in and be authed. Authorizing for a call does not require the device to be registered, it just needs to answer the 401 Unauthorized channel with the proper user/pass details. So you may never see the IP of the offender actually register. But #1 takes the From user of the device, which matches the extensions (AMPUSER) that is used to set the CF settings in the AstDB.

So either your firewall is not as secure as you believe it is and IPs are getting in, OR something is happening via the two users locations that are sending calls from either their devices or something other app running on their network that is making calls as them.

Have you tried completely changing the admin/user passwords for those two devices as well?

Have you tried to give them a new account (you can mask their callerid for their current CID)?

If the activity continues on the previous accounts during the testing then something is up. But if the activity starts with the new account and password on the same devices, then it could be something at both their locations.


(David Johnson) #12

The first time it happened, I deleted the extension and recreated it from scratch. You say change the admin password for the device? Which account is that? The pin to access the admin feature is not default, I set it at install on the PBX and is the same for all devices on the PBX.


(Jared Busch) #13

TFTP sends data over the network unencrypted. Every router between the phone and the PBX has access to those packets.

You use HTTPS provisioning without a user/pass at a minimum to ensure the packets are encrypted across the wire. Preferably with a user/pass, but that can be device dependant.

I don’t know of any modern phones that cannot do HTTPS provisioning.


(Jared Busch) #14

You can’t. That history is gone.


#15

That is all how you configure your log rotations, use google for any number of solutions


(Erik Carlseen) #16

You can’t password protect tftp, and as such it’s completely unsuitable to expose tftp to any untrusted traffic.

This.

TFTP files can be enumerated and bulk-downloaded by anyone with IP-level access. Unless you have absolute confidence in your network security, TFTP should be disabled or firewalled off. HTTPS is the way to go.


(Erik Carlseen) #17

That is all how you configure your log rotations, use google for any number of solutions

Several points:

  1. Log storage is cheap. Abuse this. FreePBX normally stores CDR info in a MySQL database (asteriskcdrdb is the default) that is fairly trivial to access and query. If you’re not using this, then you should be.

  2. Syslog is your friend! Even a FOSS solution like syslog-ng (installs as a package in pretty much every Linux/BSD distro), with sensible rotation settings, and a good familiarity with grep / sed / awk for ad-hoc searches will be serviceable for most use cases. Every on-prem VoIP device should be sending syslog info to a collector (preferably multiple collectors).

  3. Backup your VPSs, if your storage is capable of dealing with the checkpointing/snapshotting without causing service interruptions. You can use archived instances to look for tampering.

We normally maintain at least two years of log files, if for no other reason than it costs us practically nothing to do so. I can’t think of any justification for purging logs more aggressively unless you are actively pursuing anonymous communication for your end-users.


(Daniel Friedman) #18

Hello @dvsatech,

I suspect that you are allowing the tT dial options in the pbx. You can transfer the calls even if you are dialing to an IVR.

t: Allow the called party to transfer the calling party by sending the DTMF
sequence defined in "features.conf". This setting does not perform policy
enforcement on transfers initiated by other methods.

T: Allow the calling party to transfer the called party by sending the DTMF
sequence defined in "features.conf". This setting does not perform policy
enforcement on transfers initiated by other methods.

You can check your feature code table like that (check the current column if it is enabled):

[root@pbx01 asterisk]# rasterisk -x'features show'
Builtin Feature           Default Current
---------------           ------- -------
Pickup                    *8      *8     
Blind Transfer            #              
Attended Transfer                        
One Touch Monitor                 *300   
Disconnect Call           *              
Park Call                                
One Touch MixMonitor                     

Dynamic Feature           Default Current
---------------           ------- -------
apprecord                 no def  *300   

Feature Groups:
---------------
(none)     

There is a possibility that they are using the voicemail operator option if it is enabled.

Another option is that your Polycom ip phone is being hacked. You can use the Shodan website (open an account before the query - https://www.shodan.io/search?query=polycom+port%3A80+country%3A%22US%22 to determine if your phone is exposed to the internet with the default passwords.

Thank you,

Daniel Friedman
Trixton LTD