Hi Polycom Community Team,
We have a vulnerability observed by our security team for the Polycom phones and the model impacted is Polycom IP Soundstation 6000 phone. We do not use the SSL/TLS capacbility as this is not supported by the PBX so want to know how we can disable this certificate or mitigate this vulnerability.
Firmware version is the latest.
|UC Software Version||188.8.131.520|
Hello @Tejas ,
Welcome to the Poly Community.
I am not fully sure what you mean by this?
Is this in regards of browsing to the Web UI of the Phone and the browser displaying the error?
If yes this is completely normal as the phone contains a self-signed certificate which we add in the factory and obviously your browser does not trust. You can download the Polycom Root CA from http://pki.polycom.com/pki
You could maybe disable HTTPS using the attached. Simply download, unzip and import using the Web Interface:
If this is no it there is to my knowledge no way to disable TLS SIP signalling. You can only change the TLS versions via the Web UI:
in order to change the minimum version.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
I have exported the configuration to the Phone and waiting for a reply from the Security Team if the scan does not find the SSL certificate vulnerability anymore. ANd yes this vulnerability was observed for the admin access that we take using the admin mode to do changes on the device and there is no option to disable particular SSL versions and TLS are already on the latest ones i.e 1.2 enabled.
And normally how is the admin password stored in this polycom devices. Is it # based,clear text or ?
its not in clear text.
We have our own internal CA and would require now the steps to create the CSR and upload this new generated certificate instead of the Polycom devices Certificates as we are observing an SSL X.509 certificate vulnerability on all Polycom devices and to mitigate the same we need to update the certificate.
Vulnerability Details :
Plugin ID : 51192
Description :SSL Certificate Cannot Be Trusted
Port : 443
First Discovered On : Dec 14, 2019 13:20:26 CET
The server's X.509 certificate cannot be trusted. This situation can occur in three different ways, in which the chain of trust can be broken, as stated below : - First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority. - Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's 'notBefore' dates, or after one of the certificate's 'notAfter' dates. - Third, the certificate chain may contain a signature that either didn't match the certificate's information or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize.If the remote host is a public host in production, any break in the chain makes it more difficult for users to verify the authenticity and identity of the web server. This could make it easier to carry out man-in-the-middle attacks against the remote host.
Solution : Purchase or generate a proper certificate for this service.
Any support to get the new SSL certificate generated for these polycom devices so that we can change to https use only instead of http to resolve this vulnerability.