[OpenWrt-Devel] OpenWRT www version banner a security risk

[Daniel Dickinson]

On 2015-09-13 11:39 PM, Florian Fainelli wrote:
> On Sep 13, 2015 2:00 PM, "Etienne Champetier"
> <champetier.etienne at gmail.com <mailto:champetier.etienne at gmail.com>> wrote:
>  >
>  > Hi Daniel,
>  >
>  > Le 13 sept. 2015 22:04, "Daniel Dickinson"
> <openwrt at daniel.thecshore.com <mailto:openwrt at daniel.thecshore.com>> a
> écrit :
>  > >
>  > > I do think allowing to choose to disable the banner is a minor
> benefit, however, as I've said, there are much more effective means of
> preventing accidential exposure, and quite frankly if the user is
> *choosing* to open the web interface I think an warning and disabling
> the banner if the user foolishly insists on opening the interface
> despite the warning is more useful thank disabling the banner by default.
>  > >
>  > > If you're going to argue it prevents against internal threats than
> I would argue that if your internal network is hostile enough that you
> need to worry about attacks on openwrt from your internal network AND
> you're not skilled enough to limit access to LuCI (or better, build an
> image without LuCI and just use SSH) to the specific trusted hosts
> (preferably by combination of MAC address and IP address) in the
> firewall, or (better) to use a 'management' VPN or VLAN that only
> trusted hosts can get on, then you're in a lot more trouble than
> eliminating the banner for LuCI will solve.
>  > >
>  > >
>  > > Regards,
>  > >
>  > > Daniel
>  > >
>  > > On 2015-09-13 10:21 AM, MauritsVB wrote:
>  > >>
>  > >> At the moment the OpenWRT www login screen provides *very*
> detailed version information before anyone has even entered a password.
> It displays not just “15.05” or “Chaos Calmer” but even the exact git
> version on the banner.
>  > >>
>  > >> While it’s not advised to open this login screen to the world,
> fact is that it does happen intentionally or accidentally. Just a Google
> search for “Powered by LuCI Master (git-“ will provide many accessible
> OpenWRT login screens, including exact version information.
>  > >>
>  > >> As soon as someone discovers a vulnerability in a OpenWRT version
> all an attacker needs to do is perform a Google search to find many
> installations with versions that are vulnerable (even if a patch is
> already available).
>  > >>
>  > >> In the interest of hardening the default OpenWRT install, can I
> suggest that by default OpenWRT doesn’t disclose the version (not even
> 15.05 or “Chaos Calmer”) on the login screen? For extra safety I would
> even suggest to leave “OpenWRT” off the login screen, the only people
> who should use this screen already know it’s running OpenWRT.
>  > >>
>  > >> Any thoughts?
>  > >>
>  > >> Maurits
>  > >>
>  >
>  > For me listenning only on lan will break all my setups (15+):
>  > - On most of my openwrt there is no lan, it's management, or
> 'name-of-the-site' ...
>  > - on some of them i can access from multiple interface (VPNs + ...)
>  >
>  > You can't prevent people from shooting themselves in the foot (maybe
> port openning was on purpose),
>  > but you can:
>  > -Put a huge warning in luci when you set firewall default to 'ACCEPT'
>  > -add robots.txt (i think the router will still end up on shodan)
>  > -add a big warning if robots.txt is accessed (reliable way to know
> that you're open on the internet)
>  >
>  > Also you are talking about luci but what about dropbear (ssh)? There
> is no anti brute force, and maybe there is a banner (on my phone, can't
> check)
>
> For that you could setup different things ranging from using iptables'
> mlimit match per protocol all the way to having something like fail2ban
> (written in python though) which can do more complex
> blacklisting/blackholing.
>
> All of that is more of a security policy that you deploy rather than
> want it by default, even though it may seem very sensible for a default
> use case.
>
> The bottom line is that if you are exposed to the wild internet, just
> brace yourself, it is only a matter of time before your host gets
> scanned, brute forced or even penetrated.

Hence my suggestion to make the default configuration luci and ssh on 
lan only.  If that doesn't work because you're changing the network 
config then you're already making configuration changes, it's not that 
much harder to also change the ssh and luci config (although perhaps it 
would be useful for this, and for other 'tied' configs (sorry can't 
think of an example right now, but there are a few times where I've 
thought it would have been convenient) to have some sort of unified 
interface for changing all relevant sections at once; I'm not sure that 
kind of thing is worth the effor though).

Also, if the user really wants to enable wan access to ssh and/or luci 
and can't figure out out to change ssh and luci network config (once 
appropriate gui fields are added) then I'm not sure they're competent 
enough to be making that choice.

With one caveat - I think the uhttp config would need to have (e.g.) 
'http_listener' and 'https_listener' config sections with network and 
port options rather than specifying ip, and have the uhttpd initscript 
substitute the ip of the interface (so that it would work with dynamic 
ips (e.g. dhcp, pppoe, etc)) and use the procd interface triggers for 
when the address changes (and of course the option to have 'custom' 
network option where you can specify the ip instead the network).

If this concept is simply going to be a waste of my time to create the 
necessary patches, I'd be happy to put that on my to-do list (along with 
new image makefile format for my powercloud patches, for which I am 
waiting for lynxis to give the promised time-saving info on how the new 
makefile format works, and which I've agreed to help with wiki pages).

Regards,

Daniel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel