Message-ID: <9d144d1c-d569-4e85-bdbe-c2656e709376@cloudaware.eu>
Date: Sat, 21 Jun 2025 09:46:55 +0200
From: Jeroen Hermans via Fulldisclosure <fulldisclosure@...lists.org>
To: fulldisclosure@...lists.org
Subject: [FD] Disclosure Yealink Cloud vulnerabilities

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@...udaware.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/

Download attachment "OpenPGP_0x52DD23305307A27C.asc" of type "application/pgp-keys" (885 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Powered by blists - more mailing lists