what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Sep 8, 2006
Authored by Chris Travers

SQL-Ledger uses a fundamentally flawed approach to session authentication. All versions of SQL-Ledger from 2.4.4 to the present (2.6.17 as of this writing) are vulnerable.

tags | exploit
SHA-256 | 37e1d7c4d55623267b9bade8f69db530dbaa4628327b91a0dec29a95800e68df


Change Mirror Download
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:
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.

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

Login or Register to add favorites

File Archive:

August 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Aug 1st
    20 Files
  • 2
    Aug 2nd
    4 Files
  • 3
    Aug 3rd
    6 Files
  • 4
    Aug 4th
    55 Files
  • 5
    Aug 5th
    16 Files
  • 6
    Aug 6th
    0 Files
  • 7
    Aug 7th
    0 Files
  • 8
    Aug 8th
    13 Files
  • 9
    Aug 9th
    13 Files
  • 10
    Aug 10th
    34 Files
  • 11
    Aug 11th
    16 Files
  • 12
    Aug 12th
    5 Files
  • 13
    Aug 13th
    0 Files
  • 14
    Aug 14th
    0 Files
  • 15
    Aug 15th
    0 Files
  • 16
    Aug 16th
    0 Files
  • 17
    Aug 17th
    0 Files
  • 18
    Aug 18th
    0 Files
  • 19
    Aug 19th
    0 Files
  • 20
    Aug 20th
    0 Files
  • 21
    Aug 21st
    0 Files
  • 22
    Aug 22nd
    0 Files
  • 23
    Aug 23rd
    0 Files
  • 24
    Aug 24th
    0 Files
  • 25
    Aug 25th
    0 Files
  • 26
    Aug 26th
    0 Files
  • 27
    Aug 27th
    0 Files
  • 28
    Aug 28th
    0 Files
  • 29
    Aug 29th
    0 Files
  • 30
    Aug 30th
    0 Files
  • 31
    Aug 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By