Message-ID: <44FF7791.1010106@metatrontech.com>
Date: Wed, 06 Sep 2006 18:36:17 -0700
From: Chris Travers <chris@...atrontech.com>
To: bugtraq@...urityfocus.com, sql-ledger-users@...ts.sourceforge.net
Subject: Full Disclosure for SQL-Ledger vulnerability CVE-2006-4244

Hi all;

I have received many requests from security professions responsible for the
security of Linux distros to move the full disclosure ahead.  Now that I am
reasonably sure that the full scope of the problem is known and fixed in
the fix that Chris Murtagh and myself put together, it has been released. 
Also, the maintainer of the software has reacted in an extremely hostile
manner even to the notion that this is a problem.  He has not fixed the
matter when we brought it up privately, nor has he fixed it when we alerted
the public to the existence of a problem.  Nor has he even expressed a substantive willingness to work with us to fix the problem.

All versions of SQL-Ledger from 2.4.4 to the present (2.6.17 as of this
writing) are vulnerable.  Versions prior to 2.4.4 are vulnerable to browser
history exploits as the password is stored in the query string but these
are not as serious as the current problem.

The Problem:
SQL-Ledger uses a fundamentally flawed approach to session authentication. 
When a user logs in, the password is checked, and if it matches what was in
the users/members file, a session id is generated and handed to the web
browser.  The requirements for authenticating are simply that a cookie in
the name of "sql-ledger-[username]" and the value of [timestamp], and that
this value matches the "sessionid" value passed via the Get or POST
operation.   [username] is the username of the logged in user, and
[timestamp] is the unix epoch timestamp.

Additionally, a timeout value is set per user, and this is used to timeout
sessions.  The session id is not stored on the server, nor is it further
checked for validity.  However, at least in theory, it is required that the
user be logged in (though some versions do not remove the user
configuration files properly to make this a requirement). 

The Exploit:
Therefore, for the main program, the following steps are required to gain
access as any logged in user:

1)	Create a cookie referencing the host running SQL-Ledger, the / path, the
name of sql-ledger-[username], and the value of the unix epoch timestamp.
2)	Go to a URL in a web browser such as:
http://[hostname]/sql-ledger/menu.pl?path=bin/mozilla&action=display&level=N
ew%20Window&login=[username]&timeout=10800&sessionid=[timestamp]&js=1&duplic
ate=1&main=company_logo  In this example, [hostname] is the machine running
SQL-Ledger, [timestamp] is the value from your cookie, and [username] is
the desired username.
3)	That's it.

If that were the only flaw, the situation would be bad enough.  However,
the administrative interface contains a similar flaw (most easily exploited
by typing the http request directly into telnet) which can be used to list
usernames.  For this reason, anybody can list login names and attempt to
log in as other users.  One can also create new users with the ability to
access the confidential accounting data in the database, and other
administrative tasks. One could even delete the accounting databases.

Impact:
Malicious users could pin transactions on other users, so that embezzlement
could be pinned on others, accounting data could be tampered with, and
more.  This problem essentially means that audit trails logins, and
security controls cannot be trusted with this application.

The Fix:
Metatron Technology Consulting, along with Chris Murtagh have released a
fix for this problem available at http://www.metatrontech.com/downloads/sql-ledger-fix-CVE-2006-4244.tar.gz.  However, there does
not appear to be a strong commitment from the software maintainer to ensure
that this is upgrade safe and should be considered temporary.  For this
reason, we have also decided to offer a fork of this popular open source software from
http://sourceforge.net/projects/ledger-smb/ which does come with that
commitment.  The fix involves the following things:
1)	A new table is created in the database which tracks session ids. 
Session ids are tracked by login name, time issued, and value.  The value
is an md5 sum of a random number.  A new cookie handles this session value
transparently to the user.
2)	Every page load checks the session cookie against the value stored in
the database.
3)	The administrative interface uses a similar process with a file-based
server-side tracking system.

Installing this fix requires modifying the database schema.  Please see the
documentation contained in it for further instructions.  Also note that although the fix ought to affect all versions from 2.4.4 to the present, this was only tested on 2.6.15 and 2.6.17.

Best Wishes,
Chris Travers
Metatron Technology Consulting



View attachment "chris.vcf" of type "text/x-vcard" (172 bytes)

Powered by blists - more mailing lists