Message-ID: <20020826233015.GA12417@challenger.home>
From: loki_ at softhome.net (loki_@...thome.net)
Subject: All Your ABAP Are Belong To Us (was: SAP R/3 default password vulnerability)

On Sun, Aug 25, 2002 at 11:55:33PM -0000, Stefan Hoelzner wrote on lametraq:

> SAP R/3 ships with four default user accounts that are protected with commonly known passwords.
> Although SAP AG recommends changing the default passwords (see [1])

where's the problem? if you don't follow the rules, you might get hurt.
a known fact since the stone age.

> You may say that exploiting default passwords is 14m3. Well, it is, indeed. 

who cares. still better than seeking fame on bugtraq with useless information.

> But having analysed the security of SAP systems for quite some years now I always thought how appalling 
> it is that so many companies are exposing their internal R/3's to unauthorized access through their own 
> employees by leaving all that default accounts untouched. 

this is commonly known as 'darwinism'. let nature have its way.

> horrific how many systems a malicious hacker could have compromised.

OH MY GAWD! YOU MUST NOTIFY ALL FORTUNE 500 CEOS IMMEDIATELY ABOUT THIS TO
SAVE THE GLOBAL ECONOMY. DOES GWB KNOW ABOUT THIS YET?

it is time to release ZS_HASSO, THE ABAP/4 CODE MORPHING VIRUS,
before everyone runs to change their passwords. it's been around
for a few years, and i bet others have writting similar things, too.

it does real funny things to your system and financial statements,
hiding deeply in the messiest code base this planet has ever seen.
by the way, one has to wonder whether those Walldorf drones have heard
about privilege separation yet. for those who don't know R/3:
all the application code in is stored in db tables, including all the business
logic that comes from from sap ag, and gets recompiled at run-time
(and thus almost transparently) when changed the proper way.
objects in the database are protected only programmatically, that is
by acl checks and the like in application code, and all code gets executed 
at the equivalent of root access privileges. this makes it pretty
easy for a developer to fuck up the system beyond repair or build some easter 
eggs into it. the patching mechanism doesn't look too good either. there are 
a few exceptions to the above, but the system as a whole is designed in 60's 
mainframe style, don't let the spiffy new sapgui trick you (looks fantastic 
in sales collateral though, doesn't it?). 

haqrz, this could be a fantastic new playground for you!! sap used to hand 
out 90-day trial cds at conferences. grab as many as you can and mail
them to your friendz! it is time for many of you to move beyond web servers 
and mail systems into the core of the enterprise.

anyone interested and willing to sign a legal disclaimer that no
commercial security work will be done based on it, won't be disclosed to sap ag
or a partner and so on (i have no intention of helping either sap ag or the
security industry) contact me at loki_@...thome.net, and i might give you 
access to ZS_HASSO.

i'd also be happy to give it to larry, so he can teach hasso a lesson.

--the real loki

p.s. drater, i seriously hope you are not behind those worldcom 
accounting "mistakes"!

moral defense for this posting: their security architecture is so
badly flawed that it cannot be fixed within the next few years
anyway. also, i dislike german people and sap "consultants"
in particular.

shoutz: R.I.P. gayh1tler, you will be greatly missed! PHC > *

Powered by blists - more mailing lists