[NEWS] Lawson Financials RDBMS Insecurity
From: support@securiteam.com
Date: 12/08/02
- Previous message: support@securiteam.com: "[NT] Bypassing Pedestal Software Integrity Protection Driver (Time Vulnerability)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: 9 Dec 2002 00:05:39 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
Beyond Security would like to welcome Tiscali World Online
to our service provider team.
For more info on their service offering IP-Secure,
please visit http://www.worldonline.co.za/services/work_ip.asp
- - - - - - - - -
Lawson Financials RDBMS Insecurity
------------------------------------------------------------------------
SUMMARY
Due to a security vulnerability in Lawson Financials' system data is
adequately secured when it is held in third-party relational databases.
This would allow someone compromise this third party database server (not
the database itself) to easily compromise the Lawson Financials' database.
DETAILS
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:
1) Oracle database authentication
2) Operating system authentication with a single Lawson user name
3) 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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:john.w@eisenschmidt.org>
John Eisenschmidt and <mailto:schvin@schvin.net> George Lewis.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Next message: support@securiteam.com: "[NEWS] Directory Traversal Vulnerabilities in FTP Clients"
- Previous message: support@securiteam.com: "[NT] Bypassing Pedestal Software Integrity Protection Driver (Time Vulnerability)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
