UCM6202 hacked. Is there an unknown backdoor?


#29

Alan, We really need to talk more often… I could save you endless technical hurt…you could have even asked Craig from Aristel to talk to me…

MYPBX - are an Asterisk based PBX like that of the UCM in any variant.

The TELEPHONE SYSTEM is not a firewall… Draytek/Mikrotik/Watchguard/Sonicwall/EdgeRouter/PFSense are,.

Kev


#30

Thank you for all the feedback. Yes, we can all take the advice for implementing external firewall measures.
It is a pity that Grandstream et al do not advise this in their IP-PBX training.
The same advice was not given on Yeastar MyPBX or S-series training - only setting up the internal firewall rules.

Grandstream have just advised that there were vulnerabilities in earlier firmware versions which provided malicious attack on the systems by way of SQL injections.
Systems must be upgraded to the latest release, and the ‘admin’ password changed after upgrade.

Extracted from email:-

We recently published a new firmware version for the UCM series of IP PBXs that adds a number of major enhancements, detailed below. Version 1.0.20.23 also fixes a reported critical security vulnerability. To ensure that every UCM series IP PBX is fully secure and protected from the security risk, we urgently suggest that you take the following 2 steps to upgrade all UCM devices:

Steps to update the UCM series

  1. Update each UCM6200 series and UCM6510 device to firmware version 1.0.20.23 (for UCM6100 series models, upgrade to 1.0.18.18)
  2. IMPORTANT - Immediately change the admin password after installing the upgrade to keep the UCM secure

The security vulnerability in question is associated with unauthenticated password retrieval.

Grandstream Security Bulletin
GS20-UCM005 indicates:-

Grandstream received reports of SQL injections that could allow malicious unauthenticated users to
retrieve the passwords of created users from the UCM61xx/62xx/6510 series IP PBX appliances with
firmware 1.0.20.20 or older for UCM62xx/6510 and firmware 1.0.18.17 or older for UCM61xx. When
certain actions are invoked on specific ports, the related modules will be vulnerable to the
aforementioned SQL injections and brute force attacks.

BACKDOOR LOCATED AND SHUT.

Yes Damiano and Kevin, an external firewall needs to be introduced into the network to shield the IP-PBX from future attacks - we get that, now.


#31

The base of the Voip are:

  • the basic knowledge of the SIP Protocol.
  • the Security (therefore external firewall).
  • the general rules of infrastructure to properly support VoIP.

Without the knowledge of these 3 rules you don’t go to install VoIP and all that competes.
Grandstream, like all manufacturers assume that the installer knows these 3 rules well.


#32

Hello
There is a serious and effective vulnerability now in your system and these are the links of the vulnerability!

Grandstream UCM6200 Series WebSocket 1.0.20.20 - ‘user_password’ SQL Injection

https://www.exploit-db.com/exploits/48271

Grandstream UCM6200 Series CTI Interface - ‘user_password’ SQL Injection

https://www.exploit-db.com/exploits/48270

And works to withdraw the information of the manager, even if he changed the information, the new is withdrawn by injection !?


#33

update the fw of UCM and above all make sure you have the firewall NAT rules in ACL and you will have no problems.
And don’t open identical posts, just mix it up.


#34

Thanks NINJA.
It transpires that Grandstream were aware of this vulnerability a month ago.
You can read all about it here:


A lot of people may be surprised and disappointed with Grandstream having such an easily breached system, and have only just applied a fix.
Yes, Damiano, it would all be avoided by the use of an external firewall. We’ve had that hammered into us sufficiently, but I’m still pretty bummed by the lack of proper protective measures within the box.


#35

your thinking is not correct, that’s a problem that involves many manufacturers, I’ve just for example updated QNAP, Draytek etc… so no use complaining here.
The firewall is mandatory, it’s required by law (here in Italy it’s mandatory, but not everyone does it is another matter), and it’s required by the seriousness of any installer.
The problem should not be searched in GS, on the contrary should be praised that they have quickly found the solution.
If, for example, thieves come to your home to steal, do you report the thieves or who produced the access door to your home?
Unfortunately, the bad guys work daily to “hack” the systems, and the Manufacturers work daily to protect the systems.
And this happens in all active devices, Firewall, Router, “Server”, A.P., VoIP server etc…
So it’s useless to come here and complain and argue about the Manufacturer. Open a ticket and you can make as many complaints as you want.
Welcome to the complicated world of computing.

Good Job


#36

Hi damiano, one question.
what do you mean with firewall rules on firewall?
This problem is present only when managing port (as 8089) are opened from external, or there is security issue also having only sip and rtp port opened on firewall (for gswave for example)?


#37

hi Manuel,

on any data server, voip server, Router etc… NEVER open the doors to ALL, but only in ACL, this is a simple rule to always respect.

https://www.ittsystems.com/access-control-list-acl/


#38

I’m starting to think I’m one of the few people using NAT in ACL, and consider that I’m not an IT guy.
this thing gives me a lot to think about.


#39

Damiano
Sure I use ACL on firewall, by default I permit for example only european or national ip, but if I need to allow users to connect GSWave from phone without configure VPN on all devices, and I they use UMTS connection with dynamic ip, I need to keep SIP and RTP ports onpen.
or not?


#40

ACL are only done correctly if to/from the voip operator’s IP and on trusted public IPs, allowing European or national IPs is like opening a door wide, in my opinion it’s not absolutely fine.
Remote extensions must be done on VPN.
Then there are several voices of thought, I have never suffered “hacking” so I continue with my policy.

All it takes is an “unknown ip to do damage”, imagine authorizing in ACL your country, unless you know all the inhabitants perfectly :slight_smile:


#41

I am by no means a security expert, just an old phone guy using UCMs.

Is it normal practice to change the HTTP Server port from 8089 to something else when you install these units??

I always change the port, as well as set a strong password.


#42

it’s no use if you don’t “protect” UCM


#43

Is it common practice? I’m sure many do, but with today’s level of folks that want to try and get in, moving a port is simply a shell game, and they have infinite time to play. I leave it where it is, but in doing so, it is not naked to the Internet. I limit IPs, or use VPNs, etc.


#44

Greg,

Hire Larry @lpneblett for a once over of the scenario to assist you so the customer is not having to fork out copious amounts of money to the provider or you have to compensate the customer.

The above will give you expert local USA advice on the correct procedures to follow so you arent here trying to put out fires on a public forum with your skill sets as you may not be asking all of the questions as needed to help the end users 100%.

just my 2 cents…


#45

It really comes down to your security strategy and I must agree with Damiano70 strategy who is well know for a long time in promoting the use of ACL. Which in current times is really the best and most effective. Allow only one Ip to access to the device.
With one simple search it is possible to get the port version of your ucm and public Ip(changing your port may become more a of a headache for you not so much for a hacker) with such information( see picture)

being indexed and available to any hacker your best defence is to lock down your box to only 1 IP that comes with some pros and cons like ease of remote support , use of remote extensions


#46

I want to add my personal story to this post. I currently manage roughly a bit over 50 UCM units between the US and International. Out of all these units must are entirely behind a firewall (Sonicwall), two I have remote mobile extensions (only required ports are open on the firewall), and two are configured as routers (beyond my control at this time). I try to keep up with the latest updates but always wait for feedback from the forum on any bugs (at the time was 1.0.20.20).
On the units that are exposed and semi-exposed, i would say i get roughly between 500 and 2000 login attempts to either to the extension (port 5060) or the interface (port 8089).
All my units are configured with 14 character complex passwords, and permanent band using fail2band after the first login failed attempt. Alerts via email every time there is a failed login attempt, or admin successful attempt, as well as for every fail2band trigger.
When 1.0.20.23 was released, I saw the urgency to upgrade without waiting for feedback as I attempted to login to the two units that are fully exposed I noticed I was not able to due to the wrong password. I proceeded to check ALL the alert email to see if I would find any successful login attatempt to these two units unit the admin or any other account but did not find anything.
My question is. Is Grandstream truly secure and is Grandstream doing all they can to keep the system fully secure. I don’t fully trust fail2band (but there is nothing better), some of the issues I see are partial IP login attempts (200.2, or 234), at times the IP is not band and the unit needs to be rebooted in order for fail2band to continue working).
Should GEO Protection be added as an additional layer of protection?
Should there be a option to disable web interface access for user’s accounts?
Should there be an option only to allow an extension to connect from the internal network?


#47

maybe it’s not clear, let me get this straight,
as long as you continue to allow the attacker to get to the UCM you will have problems, the NAT must be done in ACL and you will NOT have problems, other questions or improvised settings are useless.

p.s.: the NATs from my clients are made in ACL permissions to 5 public IPs and I’ve never had any problems.


#48

@JMart that is already there (Extension -> Media -> ACL Policy)