|
FYI: Just in case it effects you... --phil -----Original Message----- From: John Eisenschmidt [mailto:jweisen@eisenschmidt.org] Subject: Advisory: Lawson Financials RDBMS Insecurity +-----------------------------------------------------------------------+ | Advisory: lawson001 | | Author(s): John Eisenschmidt <john.w@eisenschmidt.org> | | George Lewis <schvin@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: 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
