[26841] in bugtraq
Re: SAP R/3 default password vulnerability
daemon@ATHENA.MIT.EDU (John Eisenschmidt)
Tue Aug 27 16:05:43 2002
Date: Tue, 27 Aug 2002 14:01:00 +0000
From: John Eisenschmidt <jweisen@eisenschmidt.org>
To: bugtraq@securityfocus.com
Message-ID: <20020827140100.A492@eisenschmidt.org>
Mail-Followup-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline
In-Reply-To: <20020825235533.16270.qmail@mail.securityfocus.com>; from shoelzner@cityweb.de on Sun, Aug 25, 2002 at 11:55:33PM -0000
--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
If I might be so bold, but this seems to go on all the time.
We use a Contact Relationship Management (CRM) packare from e.Piphany calle=
d ActiveSales (or e.Piphany Sales or eSales, whatever it is this week) that=
has a front end client and a repository independant back end database (Acc=
ess, SQL Server, Oracle, DB2, anything that is ODBC compliant). The app log=
s into the database as a single super user. While you *can* change the out =
of the box password, it's a pain, and my guess is that 90%+ of their client=
s have not.
The same goes for Lawson Financials. Although it does support using the emb=
edded database security, we've found that support is more difficult to get =
from them since the CIA is the only other customer that seems to be using i=
t this way.
Most business applications these days rely on a 3rd party RDBMS to store th=
eir data, and most of them (even SQL Server, if done correctly) have securi=
ty models that are sound, clean, and granular. However, what most developer=
s seem to do is create a single users with dba rights that owns and operate=
s on all their data, so they only have to deal with the implications of the=
ir code, and now what the database might and might not let them do.=20
One could argue that the use of a directory service can make this simpler, =
and it does, but not much. In Oracle, one can identify a user externally, m=
eaning that their account information is stored outside Oracle, but their r=
ights are still in the data dictionary. That means that I still need to giv=
e them the appropriate rights to objects in the database.
In my opinion (and we know how much that counts), all the mid-tier apps I'v=
e seen take little or no advantage of the database engine people pay to sto=
re their data. Security (and performance) can best be served though stored =
procedures and embedded database security.=20
Thoughts?
Thanks,
John
Unless the Voices are Mistaken, Stefan Hoelzner (shoelzner@cityweb.de) Wrot=
e:
>=20
>=20
> SAP R/3 default password vulnerability
>=20
> Summary
> =3D=3D=3D=3D=3D=3D=3D
> SAP R/3 ships with four default user accounts that are protected with com=
monly known passwords. These user accounts are equipped with super- or powe=
r user access rights.=20
--=20
John W. Eisenschmidt <jweisen@eisenschmidt.org>
Homepage URL | http://www.eisenschmidt.org/jweisen
GPG Public Key | http://www.eisenschmidt.org/jweisen/misc/jeisenschmidt.a=
sc
GPG Fingerprint | 5F9B F916 5AD1 3295 CF99 BC1E 1F97 E6A3 37E3 BEF2
This mail is an attachment? Read http://www.jensbenecke.de/misc/outlook.en.=
html
"The motto was 'We Eat Our Young'"=20
-Marc Benioff, former Oracle Salesperson
--tThc/1wpZn/ma/RB
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (OpenBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE9a4YcH5fmozfjvvIRAs8kAJsFka2e+bbs6bat00iKhgNwnmCFKwCdHiHa
FxztuxKwc2XQE2uWtsEIk84=
=GloK
-----END PGP SIGNATURE-----
--tThc/1wpZn/ma/RB--
