============================================ ||| 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 (at) sit.fraunhofer (dot) de [email concealed] https://www.klink.name/security/aklink-sa-2009-001-sqledger-several-issu es.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&dat eformat=mm-dd-yy&numberformat=1%2C000.00&vclimit=1000&menuwidth=155&coun trycode=&timeout=10800&usestylesheet=sql-ledger.css&outputformat=html&pr inter=&old_password=te41jrt0ygm5k&path=bin%2Fmozilla&login=test&action=S ave 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 (at) sit.fraunhofer (dot) de [email concealed] http://www.sit.fraunhofer.de