Message-ID: <20091221141721.GB10005@klink-desktop>
Date: Mon, 21 Dec 2009 15:17:21 +0100
From: Alexander Klink <alexander.klink@....fraunhofer.de>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: SQL-Ledger – several vulnerabilities

============================================
||| 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
   alexander.klink@....fraunhofer.de
   https://www.klink.name/security/aklink-sa-2009-001-sqledger-several-issues.txt
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3580
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3581
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3582
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3583
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3584
   
Vendor: DWS Systems, Inc.
Product: SQL-Ledger – an open source double entry accounting/ERP system
Website: http://www.sql-ledger.org
Vulnerabilities:
  - 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

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Background:

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. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Overview:

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
password.

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

http://sql-ledger-host/sql-ledger/am.pl?type=preferences&role=user&name=&email=&signature=&tel=&fax=&new_password=1234&confirm_password=1234&dateformat=mm-dd-yy&numberformat=1%2C000.00&vclimit=1000&menuwidth=155&countrycode=&timeout=10800&usestylesheet=sql-ledger.css&outputformat=html&printer=&old_password=te41jrt0ygm5k&path=bin%2Fmozilla&login=test&action=Save

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«
extension.

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
cookies.

* 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Communication:

* 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
              http://www.sql-ledger.org/cgi-bin/nav.pl?page=misc/faq.html&title=FAQ
* 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Solution:

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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Credits:

- Alexander Klink, Fraunhofer SIT (discovery)
-- 
Alexander Klink, Fraunhofer SIT
Forschungsbereich Anwendungs- und Prozesssicherheit
Rheinstr. 75, 64295 Darmstadt, Germany
Telefon: +49 6151 869-229
mailto:alexander.klink@....fraunhofer.de
http://www.sit.fraunhofer.de

Download attachment "smime.p7s" of type "application/pkcs7-signature" (2084 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists