+-----------------------------------------------------------------------+
| Advisory: lawson001 |
| Author(s): John Eisenschmidt <[EMAIL PROTECTED]> |
| George Lewis <[EMAIL PROTECTED]> |
| 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:
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.
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
------------
Copyright 2002 John Eisenschmidt and George Lewis.
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.
