KeeneticOS weaknesses discovered

[AlperShal]

Related CVEs:

- CVE-2024-4021

- CVE-2024-4022

 

Affected devices:

- KN-1010

- KN-1410

- KN-1711

- KN-1810

- KN-1910

 

Affected versions:

- Up to 4.1.2.15

 

Description (4021):

A vulnerability was found in Keenetic KN-1010, KN-1410, KN-1711, KN-1810 and KN-1910 up to 4.1.2.15. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file /ndmComponents.js of the component Configuration Setting Handler. The manipulation leads to information disclosure. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-261673 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

[Luca Dametto]

Dear @AlperShal, 

As a Product Manager for Keenetic I'd like to inform you that a fix for the aforementioned issues has been planned before this was public and reassure you that we take security very seriously.

Due to the very low-risk nature of the reported issue we are going to patch that in our next update, with no urgent-version required for the fix.

 

We feel like explaining the issue is required in this case:

1. The CVE CVE-2024-4022 reported a "leak" of information that is meant to be known. Knowing the Model and the Firmware Version from the Web Interface does not consititute a vulnerability and is intended, so much that we write the Router model name in our UI. For the Firmware version, it is easy to recognize the approximate version due to our constant updates that will, inevitably, modify our front-end pages.
2. The CVE CVE-2024-4021 didn't allow any kind of remote access or control, nor private information leak, they only allowed an attacker to see which components (eg. WPA3-E, WireGuard, OpenVPN) have been installed on the system. This doesn't allow to know if a component is enabled, active or, in case a component is missing from the list, if the service is provided by another device that is not the Keenetic Router (eg. WireGuard may not be installed on the exposed Keenetic Router, but may be provided via Port Forwarding). After consulting with an uninvolved, third-party, Security Researcher, we identified the flaw as a category low, information disclosure. This means that the flaw in itself doesn't compromise anything on the product, but could make some flaws (we are not aware of any flaws that involve our products, as of now) easier to target due to being able to identify if the required components to possibly run the attack are installed on the system, even if the randomness explained before is present. 

 

19 hours ago, AlperShal said:

NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

I want to reassure all of our customers that this statement doesn't appear to be correct on our side: the reporter has been in touch with our team and we acknowledged the issue, mentioning that a fix was planned. 

 

That said, this confusion during the communications made us understand that we need to improve when dealing with these cases.

Starting from today I will start some processes to improve, starting from following RFC 9116, so that everyone that finds a security flaw in our system can go through our responsible-disclosure system and do the right thing.

 

In our complete interest to maintain and keep the trust of all of our loyal customers, I kindly thank you for this post.

Dametto Luca,

Product Manager for Keenetic

Edited April 23 by Luca Dametto

[PriSonerS61]

Reported to keenetic with ticket number #628989