Dear Yealink,
I have three Yealink phones (T32, T46). I changed the password as soon as I received the phones (to an eight random character value), patched to the latest firmware and adjusted the setting to block IP calls, so the phones at least did not spontaneously ring any more. In spite of these steps, all of the phones were hacked to redirect calls to an international number.
I logged onto all the phones and turned off the forwarding, set new 50-character passwords, uploaded my backed-up config settings, checked the autoprovisioning (nothing there) and do not see any residual evidence of tampering. I also set my logging settings to level 6. But the next day one of my phones is again compromised. So perhaps there is a backdoor in the software.
I would like to take some security precautions, but am not sure how or whether they are currently possible:
1) I would like to remedy this by simply blocking all IP's except for my voip server and subnet. This should be straightforward on a linux based sytem like the Yealink phones (modify the /etc/hosts.allow file), but I can't find any information about how to do this. I found documentation on allow lists for action USIs but I suspect it is the web interface getting cracked.
2) I would like to use pubkey authentication for making changes to the phone settings rather than password access. Is something like this possible?
Thank you in advance for your help.
I think he already had one of those listed (Block IP Calls). I too am curious as to how they got through. Did you pull a syslog. If not I would enable it so when it happens you can probably see how they did it.
(02-25-2016 05:47 AM)Yealink_Karl Wrote: [ -> ]I think the FAQ can help you, please try this.
FAQ: http://support.yealink.com/faq/faqInfo?id=181
Hi Yealink Karl,
Thanks for the link, but it doesn't help. As I mentioned, I have block IP calls enabled, and do not experience phantom ringing. The other feature, Accept SIP trust server only, is also already enabled.
Could you kindly respond directly to the questions I posed? I would also be grateful if you could help me spot the means of intrusion. I will post a dump of my level 6 syslog files in a separate reply.
Cheers,
Jordan
(02-25-2016 11:40 AM)elementpbx Wrote: [ -> ]I think he already had one of those listed (Block IP Calls). I too am curious as to how they got through. Did you pull a syslog. If not I would enable it so when it happens you can probably see how they did it.
Thanks for suggesting the syslog. I had switched it to level 6 prior to the recent intrusion. I am posting the logs file here in case someone knows how to parse it. The intrusion would have taken place overnight, and the times shown seem to be 5 hours in advance of the real time. The REDACTED_IP and REDACTED_USERNAME were inserted by me.
FWIW, all of my phones with random 50 character passwords have now succumbed.
Dear readers, Yealink support was of no help at all in resolving my issue. Take this into account when deciding upon your next purchase. However, I tried a few things that seem to be working. Based on my experience, here is some advice to fellow users:
1) New Yealink phones appear to have security open by default. Make sure to not only set a strong password, block IP calls, and trust SIP only from the server for *every account*, but also to set action_uri_limit_ip to some value (like 0), even if you are not using action uri's or have no idea what that is. Otherwise the whole world can (and will) remote control your phone.
2) You need to have a server and learn how to autoprovision to make your phone work properly, because at the time of writing, essential security features (such as block IP call) are not accessible from the web interface of all Yealink phones.
3) If you get hacked, don't waste time trying to figure out what they changed. Just hold the OK button for 10 seconds to reset your phone to factory settings. This was the only way I was able to prevent my phones from reverting to their pwned state. I suspect the hackers installed files that influenced operation beyond what is visible in the web interface.
4) If you're unfamiliar with VOIP phones, people are trying to hack your phone all the time. Make sure you get your security locked down right away. Also, due to apparent security flaws in these phones, a seven-letter password was insufficient. A 50-character password seems to be holding for now.
To all those using the suggestions above: last night, my phone was hacked again in spite of all these precautions. It seems like there is nothing that will stop it. These phones are simply built with flawed security.
@jppopenk
What internet gateway are you using? Is it an off the shelf piece of hardware?
Also are you opening any ports for sip, rtp & html (for these phones)? are you using upnp?
We are having the exact same issue. There is undoubtedly a security bug in these phones that is allowing them to be exploited, regardless of password or GUI settings. Yealink, please address.
In my experience, this happens to all models of phones that have a web interface that is left exposed to the open internet. I have had to disable the web interface on many a Polycom phone for this same reason.
The primary cause is that the phone is not behind a firewall that would automatically block the web interface from anywhere but your LAN. While there is surely a way to break the security on the web interface of these phones that should not exist, I can't really expect Yealink and Polycom to keep up with hackers, particularly when they cannot push security updates like traditional desktop operating systems. They must depend on the customer to manually update the firmware, and this must be phased out after testing for larger deployments.
A proper firewall will also block the Ghost calls with no need for the phone to do anything. Router\firewalls that have full cone NAT are the reason random IP's are able to intercept the port you are registered to your Voip provider on.
https://en.wikipedia.org/wiki/Network_ad...ranslation
All that being said, I took a look at the log you attached, and these may provide a hint to what the problem may be. I don't know much about http security, but this appears that it may be part of a SSL downgrade exploit.
2016-02-24 11:49:41: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
2016-02-24 11:49:42: (connections.c.305) SSL: 1 error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2016-02-24 11:49:55: (connections.c.305) SSL: 1 error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
2016-02-24 11:49:56: (connections.c.305) SSL: 1 error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request