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

[Daniel Dickinson]

On 2015-09-14 12:30 AM, Daniel Dickinson wrote:
> 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

Obviously I mean ...is not going to simply be a waste of my time...

> 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
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel