Oracle-L: Advisory: Lawson Financials RDBMS Insecurity

From: <Jared.Still_at_radisys.com>
Date: Mon, 02 Dec 2002 17:43:59 -0800
Message-ID: <F001.00510574.20021202174359@fatcity.com>

This may be of interest to some. I believe there are a number of folks on the list with Lawson systems.

jared

Forwarded by Jared Still/Radisys_Corporation/US on 12/02/2002 05:42 PM -----

John Eisenschmidt <jweisen_at_eisenschmidt.org> 12/02/2002 08:28 AM

        To:     bugtraq_at_securityfocus.com, lawtech_at_topica.com, law_secadmin_at_topica.com
        cc: 
        Subject:        Advisory: Lawson Financials RDBMS Insecurity




+-----------------------------------------------------------------------+

|             Advisory: lawson001                                |
|            Author(s): John Eisenschmidt <john.w_at_eisenschmidt.org>  |
|                       George Lewis <schvin_at_schvin.net>         |
|         Release Date: December 02, 2002                        |
|               Vendor: Lawson                                   |
|          Application: Financials (possibly others)             |
|    Affected Versions: 8.x Environment                                  |
|   Affected Platforms: Solaris (possibly others)                |
|   Affected Databases: Oracle (possibly others)                 |


+-----------------------------------------------------------------------+

Summary

Lawson Financials does not adequately secure data held in third-party relational databases.

Background

Lawson Software was founded in 1975 by Richard Lawson to develop turn-key accounting and business systems. Depending on the platform, Financials was originally written in either RPG or COBOL. All data was stored in a proprietary flat file database called LADB.

The Lawson Applications (including Financials) run in an abstraction layer called "the environment". The purpose of the environment is to present information in a uniform manner regardless of the host operating system. The current 8.0 environment supports the following operating systems:

        -AIX
        -Digital Unix/Tru64
        -HP-UX
        -Sun Solaris
        -Windows NT/2000

Several years ago, the environment was retrofitted to integrate with popular third-party relational database. These include:

        -IBM DB2/UDB
        -Informix
        -Microsoft SQL Server
        -Oracle
        -Sybase

As of the release of the 8.0 environment, Lawson only supports the use of a third-party relational database for production systems.

For the sake of brevity, this paper will only make specific reference to a Lawson 8.0 environment installation on Sun Solaris with Oracle as the repository. It is likely, however, that the issues raised here will more than likely pose the same risks to other Unix variants and Windows.

Detailed Description

There are three standard ways to configure Lawson to work with a third-party RDBMS:

Oracle database authentication
Operating system authentication with a single Lawson user name
Operating system authentication with multiple Lawson user names

Setup #1 employs a single username and password for all transactions within the database. This username and password are stored in a world-readable text file called the "capital <database> file":

        bash-2.03$ ls -l [A-Z]*
        -rw-rw-rw-   1 lawson   lawson       106 Jun 11 12:10 IBM
        -rw-rw-rw-   1 lawson   lawson       123 Jun 11 12:10 INFORMIX
        -rw-rw-rw-   1 lawson   lawson       272 Jun 13 08:40 ORACLE
        -rw-rw-rw-   1 lawson   lawson       124 Jun 11 12:10 SYBASE

As you can see, the default permission is 666 (world readable), and ownership defaults to group lawson. All users of Financials must be a primary member of group lawson, which means any user with shell access can see the contents of this file. Shell access is required for using the Lawson.Insight Desktop (LID) interface. Please note: the default permissions on this file can be changed to 400, and ownership of the file given to root, however this is not suggested anywhere in the install documents, nor is it mentioned by the Lawson certified installer required to certify your installation.

Once an unprivileged user obtains this password, they can easily establish a connection to the database through a connector like ODBC or JDBC. Since the lawson user is the database owner, these credentials make it possible to read, alter, or destroy the database.

Setup #1 tends to be the preferred configuration method by Lawson installers, despite the fact that the Lawson "Oracle Setup and Tools Guide" (version 8.0.2, published May 2002) reflects that this is not a good method to use (page 41). NOTE: The text is not reproduced here due to Lawson's copyright.

Setup #2 requires that Oracle is setup to use the operating systems' authentication mechanism. This method utilizes a single account, which still reflects the lack of database auditing and logging as mentioned above. This method is more secure than the previous #1 because the password to the single account is not available in the world-readable text file. If this single password is compromised, the system remains vulnerable.

Setup #3 has an advantage because user level auditing and logging is actually viable since users would have unique accounts. It has a disadvantage because the user, by knowing their own username and password, can connect to the database via a connector with these credential.

Financials requires that each user account has full DML rights (SELECT, INSERT, UPDATE, DELETE) to all objects in the Lawson schema. In effect, the database is left wide open to any of these users. The upside is that the audit trails in the database should have record of any malicious user activities, which Financials' internal auditing does not provide.

Several important facts should be noted about setup #3:

        -More time is required to setup this configuration, since
        accounts must be created both in the OS and the database.
        -Lawson's Global Support Center freely admits their lack of
        experience with this configuration.
        -This configuration requires that the Lawson Transaction Manager 
                 (LATM) is disabled--mitigating the connection pooling 
feature.
        -Database licensing fees are the same as setup #1 and setup #2.

Recommendation

Any system acting as Lawson Financials database server must be properly protected due to flaws in Financials' security architecture. The system should be configured to only allow appropriate hosts like IOS Remote (Lawson's web front-end), or database administrators to connect.
Accomplishing this may vary by platform, but could include a firewall, virtual private network, or ACLs in the database itself.

Since the username and password are stored as plain text in setup #1, it is not recommended that this configuration be used under any circumstances, even after changing the permissions to 400.

While setup #2 will allow you to use LATM and perform connection pooling, from a security standpoint it is still highly recommended that setup #3 is implemented for production installations of Lawson Financials. The ability to perform granular auditing at the database level is critical to any financial system.

Finally, the authors do not feel that setup #3 goes far enough to protect critical financial data, but is simply a first step. Attempts to further secure the data at the database level are met with application errors from Financials. Only through additional development resources can many of these defects be corrected, and while Lawson has owned-up to many of these problems and promised they will be fixed in future releases, their remediation has not been forthcoming.

Vendor Response

This advisory was sent to Lawson on 25 November 2002, with an invitation for them to respond in writing by midnight of the release date. Any response made by them would be included in the published version of this paper.

The Lawson Global Support Center did acknowledge receipt of our invitation the same day it was sent, but did not choose to respond.

Since most of the issues contained in this paper can be found in Lawson documentation, or have been reported to the Lawson Global Support Center and not remediated in a timely manner, the authors felt that giving the vendor one week to respond was sufficient.

Acknowledgments

Several Lawson experts were asked to review a draft of this paper and comment on it. The authors would like to thank them for volunteering their time, and for providing such useful feedback:

        Mike Corbet
        Rory Flood
        John Henley
        Jason Largen
        Chris Martin
        Kwane McNeal
        Yatrik Shah
        A special thanks to Eddi Staffini, who works too much.

Legal Notice

Disclaimer

The information in this advisory is believed to be true. The opinions expressed here are those of the authors, and not their respective employers. The authors are not liable for any damages caused by direct or indirect use of the information contained herein. The authors bear no responsibility for the content or misuse of this advisory or any derivatives.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Jared.Still_at_radisys.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Received on Mon Dec 02 2002 - 19:43:59 CST