security: information disclosure to unauthenticated guest

[ghost]

Recent openwrt builds show the administration menu to unauthenticated guests: an attacker would be able to know the presence of installed packages and services on the box.

version banner: Powered by LuCI Master (git-20.078.22902-0ed0d42) / OpenWrt SNAPSHOT r12643-213250b56b

[jow-]

It is trivial to probe installed packages by checking http://routerip/luci-static/resources/view/ or by checking the strings contained in the translation feed, therefor there is no security benefit in hiding the menu tree.

[ghost]

It is trivial to probe installed packages by checking http://routerip/luci-static/resources/view/ or by checking the strings contained in the translation feed

Doesn't seem that way, i just double-checked with Adblock plugin installed:

therefor there is no security benefit in hiding the menu tree.

We are not discussing security through obscurity here: hidden or not the menu tree should not disclose this information to unauthenticated users.

[ghost]

I cannot ship new openwrt + LuCI builds until this issue gets addressed properly, i kindly ask you to reconsider and reopen this ticket.

[hnyman]

I cannot ship new openwrt + LuCI builds until this issue gets addressed properly

You can easily change it in your own builds "for shipping". Just revert 0130e2b08 in your local repo.

[ghost]

Thank you for pointing the faulty commit, i'm going to strip that patch from my builds until this gets addresses, though since it is such a small change it seems trivial to revert it on the master branch.

[hnyman]

Note that it is related to translation, as discussed in #3563

With normal untranslated English you should have not trouble with that reverted.

[ghost]

It is bad enough that the issue was already reported 2 months ago and hasn't been addressed yet but

eventually the entirety of LuCI will be moved to the client side and then this knowledge can be easily obtained by checking for specific files in /luci-static/ even when not authenticated.

is even more worrying.

[jow-]

If you need to hide static resources from the server for unauthenticated users, consider switching to HTTP basic authentication.

Hiding (as in not rendering) the menu tree for unauthenticated users is security by obscurity at its best. Also Adblock will be easily identifiable once https://forum.openwrt.org/t/adblock-4-pre-releases/57101 lands, even if menu rendering is disabled.

[ghost]

So this is, at the very least, the third issue pointing out the security implications regarding that commit. You have to acknowledge this fact.

I also don't buy the whole "Even if the menu is hidden you can still obtain that information easily, it provides zero security benefit" argument. This is not true at all for any product taking security seriously. I thought openwrt was one of those products, but maybe i was wrong.

[jow-]

You failed to point out the actual security implications. What are are the security implications of knowing which packages are installed?

[ghost]

You failed to point out the actual security implications. What are are the security implications of knowing which packages are installed?

https://cwe.mitre.org/data/definitions/200.html

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:

• private, personal information, such as personal messages, financial data, health records, geographic location, or contact details
• system status and environment, such as the operating system and installed packages
• business secrets and intellectual property
• network status and configuration
• the product's own code or internal state
• metadata, e.g. logging of connections or message headers
• indirect information, such as a discrepancy between two internal operations that can be observed by an outsider

Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Application Data

[ghost]

https://www.cvedetails.com/vulnerability-list/cweid-200/vulnerabilities.html for a list of CVEs assigned (spoiler alert: there are a lot)

[jow-]

If your threat profile requires you to hide that information, you need to switch HTTP basic authentication to prevent any access to static assets. You can also revert that commit if it increases your perceived security.

Note that any package installing static assets (CSS files, icons, JavaScript resources) will be easily identifiable, regardless of whether the menu is rendered or not. Further information can be obtained by checking the cache buster strings which reveal the version of LuCI running.

Further techniques are fingerprinting the translation feed or even the markup or CSS files themselves to deduce information.

[ghost]

If your thread profile requires you to hide that information, you need to switch HTTP basic authentication to prevent any access to static assets. You can also revert that commit if it increases your perceived security.

This hasn't been needed until now and is a clear POLA violation. This should be documented https://openwrt.org/docs/guide-user/luci/luci.secure.

Note that any package installing static assets (CSS files, icons, JavaScript resources) will be easily identifiable, regardless of whether the menu is rendered or not. Further information can be obtained by checking the cache buster strings which reveal the version of LuCI running.

If this is true (i did not find any traces of "adblock" in "/luci-static/") it should be documented https://openwrt.org/docs/guide-user/luci/luci.secure

Further techniques are fingerprinting the translation feed or even the markup or CSS files themselves to deduce information.

This is all true and things should be clearly improved to harden the system against fingerprinting but doesn't change the fact that commit introduced a security issue which was not present before. I kindly ask you to revert that commit.

[jow-]

I am not going to revert that commit.

[ghost]

I am going to ask MITRE for a CVE.

[jow-]

Feel free to.

[sanitariu]

I commented all other duplicated bugs. Yes this is bug. It is always better to have closed/unlocked door instead opened/unlocked. I hope you understand what i mean. There is nothing wrong to revert it and admit when something new is more bad than the old one. Sometimes upgrades are not good.

[ghost]

A CVE with a "medium" severity score has been assigned by MITRE:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-10871 https://nvd.nist.gov/vuln/detail/CVE-2020-10871

[sanitariu]

Good point. Bugs should be fixed. And some bugs are really UGLY like that commit.

[jaggzh]

1. I worked at a system where attackers scanned for thousands of different vulnerabilities, because the underlying platform was not recognizable/divulged. This took them days of time, and we were able to identify and block it. (Or not, but hopefully the other security provisions still functioned). Vulnerabilities can exist and do happen. Obscurity is an additional veil that can help. It doesn't decrease security, itself. It's only a weak-mind that confuses his camouflage, going into a gun-fight, thinking he's wearing a bullet-proof vest. It's a fool who goes into a gunfight with a vest with a target on it.
2. I have a list of open, but secured, OpenWRT networks. Some people were admins of them, and one admin was discussing a new package he was using in an online forum. I spent time driving around, and was able to locate the hotspots he maintained.
3. ...Or... I'm a greater power, with a popular app which examines local open hotspots, reporting the same back to me, and again build a database identifying which networks are using which software, and sometimes it also reveals version differences.
4. ...Or... I'm an IoT device dealer, able to build the database, and recognize potential targets, from within their own networks. They didn't have to be open.

I don't want to reveal anything unique or identifying about anyone. The less we share, in any way, the better.

Were it not useful for troublesome situations, and helpful to a network's admin/users, it'd be best to disguise the router software entirely. If someone hits a router and can't even identify it as OpenWRT, let alone using luci, or it if presented even another platform, one could mislead attackers -- that would be a benefit.

Make no mistake. The phrase "Security through obscurity is no security at all" is a misquoted and misleading catchphrase that gets into peoples' minds like a virus. Obscurity is another level of protection used across nature, military, etc. Were it a bad idea, nobody would ever use camouflage. The camouflaged tank is safer. The delicate router with the package with the Zero-day exploit, that is announcing it has that package, is Eve's easy target.

And remember, it's not just about the hardness of the security, but the divulging of unique characteristics. Bob, presenting his uniqueness, is more likely for Eve to recognize him amongst the crowd. You never know the creative and destructive ways information will be exploited.