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

SQL-Ledger XSS / XSRF / SQL Injection / LFI

SQL-Ledger XSS / XSRF / SQL Injection / LFI
Posted Dec 22, 2009
Authored by Alexander Klink

SQL-Ledger suffers from cross site scripting, cross site request forgery, local file inclusion, SQL injection, and various other security vulnerabilities.

tags | exploit, local, vulnerability, xss, sql injection, file inclusion, csrf
advisories | CVE-2009-3580, CVE-2009-3581, CVE-2009-3582, CVE-2009-3583, CVE-2009-3584
SHA-256 | 3829bdb05149d1bc7598b7a78e6ebb24bc4dda65fe6aa1226850034c3332a707

SQL-Ledger XSS / XSRF / SQL Injection / LFI

Change Mirror Download
||| Security Advisory AKLINK-SA-2009-001 |||
||| CVE-2009-3580 (CVE candidate) |||
||| CVE-2009-3581 (CVE candidate) |||
||| CVE-2009-3582 (CVE candidate) |||
||| CVE-2009-3583 (CVE candidate) |||
||| CVE-2009-3584 (CVE candidate) |||

SQL-Ledger – several issues

Date released: 21.12.2009
Date reported: 28.07.2009
$Revision: 1.1 $

by Alexander Klink
Fraunhofer Institute for Secure Information Technology

Vendor: DWS Systems, Inc.
Product: SQL-Ledger – an open source double entry accounting/ERP system
Website: http://www.sql-ledger.org
- no Cross-Site-Request-Forgery (XSRF) protection
- persistent cross site scripting
- SQL injections
- local file include
- secure cookie flag not set
Class: remote
Status: unpatched
Severity: moderate
Releases known to be affected: 2.8.24
Releases known NOT to be affected: none


Quoting http://www.sql-ledger.org/cgi-bin/nav.pl?page=about.html&title=About:
| SQL-Ledger® ERP is a double entry accounting/ERP system. Accounting data is
| stored in a SQL database server, for the display any text or GUI browser can be
| used. The entire system is linked through a chart of accounts. Each item in
| inventory is linked to income, expense, inventory and tax accounts. When items
| are sold and purchased the accounts are automatically updated.


Several issues have been found in SQL-Ledger which might lead to attacks
on the confidentiality and availability of business-critical data stored
within SQL-Ledger.

Fraunhofer SIT advises to use SQL-Ledger only in non-critical application
scenarios with low security requirements. Furthermore, risk mitigation in
the form of the following measures should be undertaken:

- Users shall be advised to use a seperate browser or browser profile
solely to access SQL-Ledger to counter XSRF attacks.
- Untrusted users should be given read-only access to the database to prevent
damage from SQL injection attacks.
- The server administrator shall restrict file creation rights on the
SQL-Ledger server in order to prevent the storing of arbitrary files which
may be used in local file include attacks later on.

Technical details:

* No Cross-Site-Request-Forgery (XSRF) protection (CVE-2009-3580)

The forms in SQL-Ledger are not protected against XSRF. They include the username
in the hidden field »login«, though, which has to be specified correctly. An
attacker is thus required to know the login name – it can be guessed, brute-forced
or retrieved using a Cross-Site-Scripting attack, though.

An example attack would be to send the following link to the user which unknowningly
changes his password to the application. Given network access to SQL-Ledger, the
attacker could then use the application with the user's account and the newly set

To set the password for the »test« user to »1234«, the following URL would need to
be retrieved by a victim:


As SQL-Ledger would typically run on an intranet server which is not directly accessible
to an outside attacker, the missing XSRF protection makes it much easier for an attacker
to exploit other weaknesses (such as the XSS or SQL injection vulnerabilities that were
found during this test).

* Persistent Cross-Site-Scripting (CVE-2009-3581)

An attacker which is logged into SQL-Ledger (or abuses the missing XSRF protection to execute
requests in the context of a logged-in victim) can inject arbitrary JavaScript code which
will then be run in the session context of other users.

XSS injection is possible (at least) in the following fields:
- name field of the »Customers« → »Add Customer« menu
- name field of the »Vendor« → »Add Vendor« menu
Any time the customer/vendor is shown (or can be selected in a form) on the
web interface, the JavaScript code is then executed in that user's context.

- DCN Description field of the »Accounts Receivables« → »Add Transaction« menu
- Description field of the »Accounts Payable« → »Add Transaction« menu
To trigger the JavaScript code, the victim would need to view a corresponding
report on the web interface

As session credentials are stored within cookies, an attacker can thus steal those
credentials or control the web application within the browser context of the victim.

There is no central filtering of input data within SQL-Ledger (input data is only
filtered for some select variables, apparently more for functional than security
reasons), so it is is likely that many more similar vulnerabilities exist.

* SQL Injection (CVE-2009-3582)

An attacker which is logged into SQL-Ledger (or abuses the missing XSRF protection to execute
requests in the context of a logged-in victim) can modify input variables to perform
SQL injection attacks. One attack is to search for an existing vendor using the »Vendors«
→ »Reports« → »Search« menu. Before submitting the form using the »Delete« button, the
hidden »id« form field is modified to »1 OR 1=1«. This will in turn delete not only one
vendor, but all vendors in the database. As the database table name is also passed in the
form as the hidden »db« form field, data from any database table which has an »id« key can
be deleted using this method.

Similarly to the XSS finding, the main cause of this vulnerability is the inadequate
filtering of user input. As this is present throughout the complete codebase, it is likely
that there are similar vulnerabilities in other places.

The README file of LedgerSMB, a fork of SQL-Ledger says the following about SQL injections
in SQL-Ledger:

| LedgerSMB 1.2 has been through a detailed SQL injection audit of the codebase
| inherited from SQL-Ledger. As a result several vulnerabilities which were known
| to be exploitable were corrected along with hundreds of places where
| vulnerabilities may have been exploitable but we didn't have time to verify the
| what was involved in exploiting it. We believe though that many or most of the
| issues were exploitable given a little time and effort.

SQL-Ledger uses SQL queries which are concatenated with user input which is rarely quoted.

For example, this is the code which is vulnerable to the attack detailed above

| sub delete {
| my ($self, $myconfig, $form) = @_;
| # connect to database
| my $dbh = $form->dbconnect_noauto($myconfig);
| # delete customer/vendor
| my $query = qq|DELETE FROM $form->{db}
| WHERE id = $form->{id}|;
| $dbh->do($query) || $form->dberror($query);

The values for $form->{db} and $form->{id} are supplied by the user and are not filtered or
quoted before using them in the SQL query.

Perl's DBI module offers prepared statements with bound parameter queries (e.g.
"DELETE FROM ? WHERE id = ?"), which should be used — together with input filtering as a
defense in depth strategy — to prevent this kind of attack.

* Local File Include (CVE-2009-3583)

For this attack to be successful, an attacker must be able to write files containing Perl
code to a file in an arbitrary directory on the filesystem of the server running SQL-Ledger.
These files need to have the name of a SQL-Ledger CGI script without the ».pl« extension.

The attacker also either needs an account on the system itself or can utilize the XSRF attack
to trigger the necessary request.

The attacker uses the »Preferences« menu entry to set the »countrycode« field to (e.g.)
»../../../../../../../../../../tmp«. Once the new countrycode is saved for the user,
SQL-Ledger executed the following code for every request to the application:

| if ($country && -d "locale/$country") {
| $self->{countrycode} = $country;
| eval { require "locale/$country/$NLS_file"; };
| }

Here, $country is the modified countrycode variable which is stored in the user's
preferences and $NLS_FILE is the name of the requested CGI script without the ».pl«

Using this attack, an attacker can execute arbitrary code using the privileges of
the webserver user. As the database credentials are stored unencrypted in a file
readable by the webserver user, this in turn means that the attacker is able to get
direct access to the database as well.

The code used for translating strings used in the application executes Perl code from
files whose location is provided by the user. From a design standpoint, executing code
when dealing with the translation of strings is unnecessary, reading data (for example
using the widely used GNU gettext library and its Perl bindings) should be enough.

* Secure cookie flag not set (CVE-2009-3584)

SQL-Ledger is normally deployed on a HTTP webserver. If the administrator deploys
the application on a HTTPS webserver (which would be highly recommended given the
sensitive nature of the transferred data), the secure flag is not set for session

* Default administrator password weakness

In the default configuration, the admin interface of SQL-Ledger can
be accessed using any password. If the user wants to protect the admin
interface from unauthorized users, he has to change the password manually
after installation. This is not enforced by the application and the
user is not informed that the password should be changed.


* 27.07.2009: Contacted Dieter Simader asking for a secure communication
method and communicating that vulnerabilities have been
found in SQL-Ledger
* 27.07.2009: D. S. replies pointing to the FAQ about security issues
* 27.07.2009: Replied with the note that not putting the server on
the internet is not enough, several vulnerabilities
are exploitable in an intranet scenario as well
* 27.07.2009: D. S. replies that they can take the issues under advisement
* 28.07.2009: preliminary vulnerability report sent to D. S.
* 29.07.2009: contacted D. S. asking whether he has had a chance to look
into the report. Set deadline for fixes to three months
* 29.07.2009: Sebastian Weitmann of Balans Incorporated Limited, the official
SQL-Ledger partner in Germany contacts me. He has been
sent the report by D. S. and asks if he can call me.
* 29.07.2009: Replied to S. W. with phone number.
* 30.07.2009: Talked to S. W. on the phone and sent hints on how the vulnerabilities
could be fixed to him.
* 03.08.2009: Martin Elmer of leanux.ch AG, Switzerland contacts me. Has has
also been sent the report by D. S. Has some question about the
report and offers a virtual SQL-Ledger server for testing.
* 04.08.2009: Answered questions of Martin Elmer and offered to also sent him
the hints on fixing the problems. Offer to penetrate a virtual
server has been declined.
* 13.08.2009: D. S. replies to vulnerability report without any indication
that the issues will be fixed.


No patch exists, so the only available options are risk mitigation
using the measures detailed above or migrating to a different product.

Fraunhofer SIT is able to offer support for mitigating the risks of
the security issues as well as doing a security analysis of alternative
products you might be interested in. We can also offer help with secure
software development to avoid vulnerabilities such as the ones mentioned
in this advisory.


- Alexander Klink, Fraunhofer SIT (discovery)
Alexander Klink, Fraunhofer SIT
Forschungsbereich Anwendungs- und Prozesssicherheit
Rheinstr. 75, 64295 Darmstadt, Germany
Telefon: +49 6151 869-229
Login or Register to add favorites

File Archive:

June 2024

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

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By