Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

security: information disclosure to unauthenticated guest #3766

Closed
ghost opened this issue Mar 18, 2020 · 21 comments
Closed

security: information disclosure to unauthenticated guest #3766

ghost opened this issue Mar 18, 2020 · 21 comments

Comments

@ghost
Copy link

ghost commented Mar 18, 2020

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

image

@jow-
Copy link
Contributor

jow- commented Mar 20, 2020

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.

@jow- jow- closed this as completed Mar 20, 2020
@ghost
Copy link

ghost commented Mar 21, 2020

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:

image

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
Copy link

ghost commented Mar 21, 2020

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

@hnyman
Copy link
Contributor

hnyman commented Mar 21, 2020

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 0130e2b in your local repo.

@ghost
Copy link

ghost commented Mar 21, 2020

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
Copy link
Contributor

hnyman commented Mar 21, 2020

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

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

@ghost
Copy link

ghost commented Mar 21, 2020

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-
Copy link
Contributor

jow- commented Mar 21, 2020

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
Copy link

ghost commented Mar 21, 2020

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-
Copy link
Contributor

jow- commented Mar 21, 2020

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

@ghost
Copy link

ghost commented Mar 21, 2020

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
Copy link

ghost commented Mar 21, 2020

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

@jow-
Copy link
Contributor

jow- commented Mar 21, 2020

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
Copy link

ghost commented Mar 21, 2020

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-
Copy link
Contributor

jow- commented Mar 21, 2020

I am not going to revert that commit.

@ghost
Copy link

ghost commented Mar 21, 2020

I am going to ask MITRE for a CVE.

@jow-
Copy link
Contributor

jow- commented Mar 21, 2020

Feel free to.

@sanitariu
Copy link

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
Copy link

ghost commented Apr 11, 2020

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
Copy link

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

@jaggzh
Copy link

jaggzh commented Aug 22, 2021

  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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants