Customer (K12 with nearly 2000 devices on the network) has a local FPBX 14 system with about 130 phones, mostly older Yealink T22P and T28P phones. They’ve detected at least 6 hacked phones recently so I’m working to secure their installation and prevent further hacks. I suspect there is a compromised device on the network that is sniffing traffic in order to pull extensions and secrets since provisioning is via TFTP, but it’s just a guess.
So I have two questions:
Are there other ways these phones could be hacked? (details are most welcome)
These phones do not support HTTPS provisioning so what is the best way to secure them? Even if I use HTTP provisioning with username/password they could still be sniffed if there is a compromised device, right? And even if they did support HTTPS, the username and password would still need to be passed to the phones via DHCP option 66 which again, is cleartext and sniffable. Right? So again, what is the best way (best practices) to secure them?
A very common way of hacking phone systems is through open ports on the firewall.
If the SIP port is open to the internet and not secured by whitelisting IP addresses only allowing traffic from your SIP provider, then hackers will try to repeatedly register an endpoint to your server and after successfully guessing username/password or obtaining those through provisioning files, then they would be able to make fraudulent calls.
I’d be interested to hear more about the way this is phrased - the phones being hacked is a very specific way to describe the problem in this community, so if you could supply more details about what the effect of the hacked phones is, we might be able to help.
The TFTP files are readable by anyone with access to the network, so your problem may be simpler than someone sniffing the network,
To narrow down the possible culprits, you could put all of the phones in a narrow network block and set the Integrated Firewall to block access to the TFTP port except by trusted phone IP Address ranges.
If the network is switched, the likelihood that ‘sniffing’ on the local network is an issue is effectively reduced. Even with the interface in promiscuous mode, the only traffic that it’s going to see is broadcast traffic and traffic for that MAC address.
I’m usually reticent to recommend VLANs (since I personally find them to be more trouble than they’re worth) but this case might call for such a thing. Splitting the network into smaller LANs (where reasonable) might help you narrow the visibility of the traffic (if that turns out to be part of the problem).
The more you can tell us about the hacks, the more we can narrow the problem without having to suggest a bunch of guesses that don’t yield satisfactory results.
The question is how they’ve detected 6 hacked phones (by checking logfiles?), by the way I guess is more easier for a hacker to hack a server than compromised device on the network for sniffing traffic.
I’m agree with avayax reply.
I asked the IT guy on-site how he knew they were hacked. His response:
The phones were making calls… initiated by an external IP address. Once I changed the password, the calls stopped… so I assume in order for a call to be made, that the password between the system and the phone has to be used…
Their network is already segmented into several VLANs however, routes exist between the phone VLAN and most others. So one of my planned mitigation steps is to remove the routes between the phone VLAN and most/all of the others.
Yes, so it’s not your phones that got hacked, it’s either that hackers got ahold of the phones’ SIP credentials by either trying username/password combinations until they are successful or by obtaining those through provisioning files.
Your server’s SIP port is exposed to the internet, which allows hackers to register an endpoint to your server even though they are somewhere on the internet.
Ask your IT guy if port 5060 (or potentially a different port used for SIP) is forwarded to your FreePBX server without whitelisting any IP addresses.
It’s not sufficient to just change passwords.
The system sits behind a hardware firewall. I scanned the external IP for open ports and only found port 80 which I know to be open for Let’s Encrypt. The FPBX firewall is enabled and configured to allow SIP traffic from the Local and Other zones only. Let me know if there is any other information that would be useful.
Password are used for registration process not for initiating calls.
Better to deeply analysis about how; “making calls… initiated by an external IP address”
There is no such thing as a general purpose UDP port scanner. That’s because the host will respond only if it receives a packet with the protocol it is running on the port being scanned.
However, you shouldn’t have to ‘scan’ anything, because you have access to the system you’re trying to secure and you can see which ports are being used for pjsip and chan_sip. Then, check whether the firewall is forwarding either of those ports. Or, use svmap or similar from an outside IP to see whether you get a response.
You guys pushed me to dig and at the end of the day, that makes for a great day!
And you were right of course. I dug into the firewall and found ports for TFTP, Chan_SIP, and PJSIP were all being forwarded. Easy fix, and much learned on my part. Thanks for your help!
You might need that forwarded for inbound calls from your SIP provider to work, but it’s often that the firewall is set to only forward traffic from specific IP addresses, i.e. your SIP providers’ IPs.
This is actually one of our “best practices”. If you don’t need the entire world to be able to connect a phone to your system, only allow addresses that you KNOW need to connect to access the port. Locking it down twice (once at the NAT Firewall and once at the PBX is best).
One of the things I do is never put the passwords in the provisioning config files. All of the other settings are there. I find the most secure thing to do is provision the phones using the file but then login to the phone manually to add the user and password. If that’s not possible, you could minimize the issue by adding the user and password once. Once the phones pick up the user and password change the config file so it no longer contains those things. You don’t need to keep telling the phone what the user and password is. Remove those items from the config files because you never know who is going to get that information.
That’s good that you resolved the issue. I still would never put passwords in the provisioning file. If you have remote phones then you might have to open ports and forward them to the PBX. Change 5060 to something else, and try to limit who can connect to your ports. If it’s phones from a specific IP address, allow only that IP into your PBX. You can use dynamic DNS for non-static remote phones and only allow them in. You’d need a firewall with this capability. Cheaper routers will often not give you the opportunity to put in a source IP Name, only a source IP address.