Dear all, ---Abstract--- Yealink RPS contains several vulnerabilities that can lead to leaking of PII and/or MITM attacks. Some vulnerabilities are unpatched even after disclosure to the manufacturer. ---/Abstract--- We are Stefan Gloor and Jeroen Hermans. We are independent computer security researchers working on a disclosure process for critical vulnerabilities we found in Yealink telecommunication devices and infrastructure. In the past few months, we have been working with Yealink to patch a few extremely sensitive vulnerabilities. Although we are still in a 60 days disclosure procedure, Yealink has decided to publicly disclose the vulnerabilities [1]. Although we appreciate the effort Yealink is putting in disclosing the vulnerabilities, we think some information in the manufacturer's statement is incorrect or incomplete, which is why we feel the need to inform the security community. Please let us explain: 1. Unauthorised Access to RPS data During our research, we have been able to access the private key of the "Yealink Equipment Issuing CA". This allows us to issue rogue client certificates with which we were able to contact the RPS (Redirection and Provisioning Service). The data we obtained from the RPS server was highly confidential and contains data such as: * provisioning URL * provisioning credentials * provisioning certificates With these credentials it is trivial to contact the customer's provisioning service and obtain a great deal of data incl. PII such as: * SIP username/password * LDAP credentials * address book of the device and/or organisation In the statement mentioned before, Yealink argues that this issue is fixed and was only relevant for EOL devices. This is unfortunately both incorrect: * We have actively tested this vulnerability with a T44U device which is currently not EOL [2]. * We have re-tested the vulnerability using our exploit code today. The vulnerability is still present. In the statement of Yealink, they call the vulnerability "medium severity", but leaking address books (PII) and SIP credentials is a major issue for customers in the EU (GDPR) and outside the EU (ISO27001). After careful deliberation, we decided to disclose our findings in a way we feel is not putting Yealink customers at risk. 2. Firmware Encryption Yealink has released new firmware for all devices to mitigate the fact that we have obtained the AES key to decrypt the firmware. During our communication with Yealink, they classified this vulnerability as "high severity". However, Yealink did ultimately not publish this one vulnerability they themselves consider high severity. We are unable to determine whether obfuscating the firmware with a new AES key leads to improved security, but please be advised that Yealink has released new firmware for most non-EOL devices, which we did not fully analyze yet. 3. Missing Input Validation RPS We have determined that RPS does not check whether the certificates configured for a server are actually certificates. The only check done is whether the file is smaller than 5 Mb and has an extension of ".pem". We have been able to upload random data to the RPS service. When contacting the RPS service this random data is returned. To our knowledge, this failed input validation is not directly exploitable. 4. RPS Serial Number Enumeration We have been able to enumerate the last 5 digits of the Yealink serial number. These last 5 digits (also referred to as PIN) have been implemented as a "2FA" since the last RPS vulnerability in 2020 [3]. After many hours of testing, we have not observed any rate limiting or brute-force protection in the RPS. We did not confirm that this vulnerability has been fixed after disclosure to the manufacturer. 5. RPS MAC Address Enumeration During our tests, we have been able to enumerate which MAC addresses are registered on the RPS platform using the RPS API. This does not only work for MAC addresses registered in our own organisation, but for all global organisations. This makes finding vulnerable device configurations a lot faster. During our tests, we have not observed any rate limiting or brute-force protection in the RPS API. 6. RPS Authentication Bypass During our last research into Yealink security [4], our RPS account got banned by Yealink. As it turned out, this mechanism only worked for the web interface. The RPS API was still available for blocked entities. 7. Mitigation According to the statement released by Yealink, all vulnerabilities have been mitigated and mostly only work on EOL devices. As some of these statements are provably incorrect, we strongly feel we need to disclose to Yealink customers that additional mitigation steps are needed. We strongly feel that security is an onion where each layer adds extra security. In this particular case, layer after layer of security have been peeled away and this makes the compounded severity higher than the individual vulnerabilities. Without providing a complete mitigation path, we feel the following mitigations would complicate exploiting these vulnerabilities immensely: * Where possible, lock down provisioning server documents to an IP subnet or ASN. Additionally, we think that the manufacturer should employ additional mitigations: * Use an extra factor to provision a device, such as a code that is sent to the customer by email. * Limiting RPS API to only be able to add MAC addresses that have not been previously provisioned. After provisioning, the device has its actual provisioning URL and no longer needs RPS. Removing the MAC address from RPS should then not impact provisioning functionality. Please note that this also increases the risk of a MAC address being claimed by a bad actor. Adding already provisioned devices to a "dummy" server also mitigates this risk. * Use a one-time provisioning URL in RPS. This one-time provisioning URL provisions the device with the actual provisioning URL and credentials. As this is a one-time provisioning an attacker cannot use RPS anymore to gain access to a customer provisioning server. Device provisioning will keep working though. * Use the RPS API to check all "servers" in RPS for certificates and whether these certificates are valid certificates. We are happy to discuss mitigations options with you in order to make the attack surface for your company and customers as little as possible. Please contact us for any questions on the dedicated email address below. We can be reached in English, German and Dutch. Kind regards,         Stefan Gloor (https://stefan-gloor.ch/)         Jeroen Hermans (Cloudaware.eu)         yealinkcvd@cloudaware.eu [1] https://www.yealink.com/en/onepage/yealink-rps-issue-statement [2] https://www.yealink.com/en/product-list/eol-products [3] https://www.heise.de/news/Grave-Vulnerabilities-Discovered-in-Yealink-s-VoIP-Services-4654617.html [4] https://cloudaware.eu/yealink/