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

[Etienne Champetier]

Hi,

Le 14 sept. 2015 06:36, "Daniel Dickinson" <openwrt at daniel.thecshore.com> a
écrit :
>
> 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
>>

You are not fixing the root problem here.
If luci is open on the internet, it means that:
1) the user openned up port 80, nothing we can do about it
or
2) the user accidentaly put INPUT default = accept, this we can prevent

Your approche is "let's patch every service", i would prefer you use your
time to implement a generic one.

I will repeat my first email, *defaults are safe*, so we just have to
prevent noobs from changing the defaults

When you climb, you have one rope, here we have one iptables, and it's
enough

what can happen now is someone open port 80, it's not working, so he open
everything, still not working, then he find about your config and forgot to
undo the open everything part, we need to educate people, not put redundant
safety.

If you do go forward with your patch, don't forget to handle dynamic IP
change and uci network name.

Regards
Etienne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150914/af39c07c/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel