oss-sec mailing list archives

Re: Re: FreeNAS default blank password


From: Pierre Schweitzer <pierre () reactos org>
Date: Tue, 19 Aug 2014 11:41:19 +0200


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In such situation, we can then also wonder about other software such as
Icinga-web, where installation comes with default username and password
(properly documented). Be it using packages or "mainstream"
installation:
https://wiki.icinga.org/display/howtos/Setting+up+Icinga+Web+on+Ubuntu.
Such credentials give full access (root access) to the installation.

If Icinga wasn't configured yet, it's not such a drama, but otherwise,
it can become rather critical:
- -> Access to the whole infrastructure schema
- -> Possibility to submit checks which can help to harass a host/service
- -> Possibility to disable all the checks around to shut monitoring down
- -> Possibility to overload the master host by issuing too many checks
(master needs to handle them - MySQL dump, pnp4nagios, perf data
analysis, and so on)

On 19/08/2014 10:46, cve-assign () mitre org wrote:
My understanding is default/blank admin credentials now == CVE

There isn't a precise rule of this type. For example, there may be
situations in which the blank credentials can only be entered over a
trusted interface (for some definition of "trusted" that is consistent
with the vendor's security policy and otherwise reasonable for the
product's context).

So an attacker can easily race the admin to the WebGUI, set a new
password

Similarly, "race the admin to the WebGUI" situations don't always
qualify for CVE IDs. There are many products in which the full
functionality of install.php is available to the first client who
visits install.php. A product can have a design constraint that
installation must not require the person to have any ability to use a
command line (or other non-browser method) for any part of the initial
product setup. This design constraint was historically reasonable for
some types of shared web hosting, for example.

For this FreeNAS case, the blank password seems unreasonable because

  -- the requirement for a reboot implies that the product is not
     intended for use in constrained scenarios such as shared web
     hosting

  -- the web interface exposes a root shell. This is quite different
     from a case where use of install.php has a consequence limited to
     "the machine ends up with a web application that wasn't supposed
     to be there, and maybe some disk consumption or other minor
     resource consumption."

Use CVE-2014-5334.


- -- 
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJT8xu+AAoJEHVFVWw9WFsLa6cP/RIPZmZF7FU0cfSpfPjf4mlR
5RcLNefjBlOGQrQE+0se77UOvkOPU8AHgD9jSFkDaqYrn2M/kNQb6/3hvSA34kcx
Ew2vHJ3skfEo0upSwuEvb34FEZ3FeQOwTqeRy7cizCqIUojmN1mSHWPWFlADWEWY
ALbVbnrFEYCfbco1T0JKMIe85OnjKXAstCnrJaahw0eefv7nYqBv/Lf0TBWRcfHF
UO3+n2yk/W+TaVR4PTL/Rz/jNGvQOk9obfMEPRZQ6gqBTFlJO5EaN9DSrCwN2/Qw
FNSstXMoAeFEokv1Og9/Pct0eucR11GzxwO+COkCKm3/5laFgzuEOLc3KnRBdHop
a/jSDTMcrhWI3uUCQBodvRu09TWw4fSOBMGpPLe8KsNFFTQUdoMGNxIpCkVpEmOF
cpJJ7yc1zREp7RoHJrvimw+OBa82Lprffvnqu4MKsyIu57i8jpaE9tsY0WdVqa1c
WRbtlykhKW1dwRxtRZHSrCTJm3HMEYW7j/qdKDjmxtydDuJ+G7cjHCkypGA0sRPZ
3/p5gkl8QSt5nv9Gk5uFS3zQHou8ramg46R3TNOA4oeQwEIGjGpjCA7jQDyW4Cs9
9D9WVAg0qHES/wbSI6CsA7hOayCAPRMKgsiPx5Q6DrnOzeOs50w3XIVBjwo7JLNf
pvhelZjoKp+1WhXHBQnP
=b+iT
-----END PGP SIGNATURE-----


Current thread: