SQL-Ledger XSS / XSRF / SQL Injection / LFI

`============================================  
||| 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  
[email protected]  
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:[email protected]  
http://www.sit.fraunhofer.de  
`