|
|
--GZVR6ND4mMseVXL/
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
===========================================||| 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 =E2=80=93 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@sit.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 =E2=80=93 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=C2=AE 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 =C2=BBlogin=C2=AB, though, which has to be specified correctly. An
attacker is thus required to know the login name =E2=80=93 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 =C2=BBtest=C2=AB user to =C2=BB1234=C2=AB, 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 =C2=BBCustomers=C2=AB =E2=86=92 =C2=BBAdd Customer=C2=AB menu
- name field of the =C2=BBVendor=C2=AB =E2=86=92 =C2=BBAdd Vendor=C2=AB 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 =C2=BBAccounts Receivables=C2=AB =E2=86=92 =C2=BBAdd Transaction=C2=AB menu
- Description field of the =C2=BBAccounts Payable=C2=AB =E2=86=92 =C2=BBAdd Transaction=C2=AB 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 =C2=BBVendors=C2=AB
=E2=86=92 =C2=BBReports=C2=AB =E2=86=92 =C2=BBSearch=C2=AB menu. Before submitting the form using the =C2=BBDelete=C2=AB button, the
hidden =C2=BBid=C2=AB form field is modified to =C2=BB1 OR 1=1=C2=AB. 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 =C2=BBdb=C2=AB form field, data from any database table which has an =C2=BBid=C2=AB 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 =E2=80=94 together with input filtering as a
defense in depth strategy =E2=80=94 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 =C2=BB.pl=C2=AB 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 =C2=BBPreferences=C2=AB menu entry to set the =C2=BBcountrycode=C2=AB field to (e.g.)
=C2=BB../../../../../../../../../../tmp=C2=AB. 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 =C2=BB.pl=C2=AB
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@sit.fraunhofer.de
http://www.sit.fraunhofer.de
--GZVR6ND4mMseVXL/
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFwDCC
BbwwggSkoAMCAQICCjiZgIoAAAAAh08wDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUx
EzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBL
STEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcwHhcNMDkxMDAxMTA0NjAxWhcN
MTUwOTMwMTA0NjAxWjBbMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEMMAoG
A1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxGDAWBgNVBAMTD0FsZXhhbmRlciBLbGluazCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJPfih53KAjOtOKPciNKYVXrHvZ33DWr
j870DP4p/H+J7aYIM4IiZgH/0b0wxstatpm6uLx9qJiNa41oUOkA97zTEGKVhin0Iela9vMu
195UzVMrhkKMsCrO0f0laH3j1I7e1SZtPJwNAoXbOKZsFw5mw2fixdXTwNkIce53xdHA1kdy
DVPGIr8vXV+oMhakRmO1McDpK+NXG/MCQcRZiwMPFccTrPhQaMnIquAkyc1IhuAGiAlypxPI
h/W/Wua4RRnZ5EDJYGO0DdXHrE4/hfvaYTvP/jy6BaOkTnRKvybWkAorhvoKsS0E7zNtLMZf
qbe/t1/jeLVccmDX6lvRjyUCAwEAAaOCAnQwggJwMA4GA1UdDwEB/wQEAwIHgDAyBgNVHREE
KzApoCcGCisGAQQBgjcUAgOgGQwXa2xpbmtAc2l0LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYE
FGdbzVaZvhPnk0MClC/FHfLlQ7VyMB8GA1UdIwQYMBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oL
MHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVz
ZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zlci1wa2kuZGUvZmhnLXVzZXIt
Y2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+BggrBgEFBQcwAoYyaHR0cDovL2Nl
cnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKG
Mmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsG
CCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5vY3NwLnBraS5mcmF1bmhvZmVy
LmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhv
ZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYIKwYBBQUHAwIGCisGAQQBgjcUAgIwRAYDVR0gBD0w
OzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtpLmZyYXVuaG9mZXIu
ZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQBCciH4j2xoGjugWl86rAPuEaO95mRomeIjPBqB
PpJL6Z8HNzzuUpmp+8c+6jwkslAOCY1p8erRGhzYTVFX/ZAFfK7WehC8EVXxphWWSb5ySrSz
eydMMq489fGY3uiPMyJE+0OYvB5Jsfz78DqBg10x911cDLaE3Q+e4uNZE4Nbp+Y4EON2Q40I
Y9jf99VKOYsU6aRPuZmoUrhgaByicsLVvACj0vxTVnIQ/5bXSkCErBGHp7OCNQ9DCvt7G4hr
Zj3Kh4l+L0WGj5GPO4eK9KmmL/GvdzYhNLUkGWa1gEv85PPyuvqzToTfTbQMToDppw7discB
rbq8y/w6Bs0qwBnFMYICJjCCAiICAQEwdTBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJh
dW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdG
cmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKOJmAigAAAACHTzAHBgUrDgMCGqCBizAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMjExNDE3MjBaMCMGCSqG
SIb3DQEJBDEWBBQBlHl6RB9ksoc+AKllVqiPPxuk7jAsBgkqhkiG9w0BCQ8xHzAdMA0GCWCG
SAFlAwQBAgUAMAwGCCqGSIb3DQMHBQAwCwYJKoZIhvcNAQEBBIIBABTMWOAeYc6dqbTi8oGp
EIkeUfhAfm1ZVsbCpQdyPjJigJowltxqRxokvX/lpCogLWhSrrG0gK8ifnr6Jj2991mmvV2T
3eqlvQ9WGTbjh/AWyhA0aW0jGsMtn8KZfz4S2PYNLQfYUawPLcSLliXtZuF4Tye5WAX9oojB
p/eXURZlLA1ye+DS5sDZe9L5iY9Nxyt5ojtCee95RnXaeetbhEMrQwAbaoKz1vreCirEETPj
ViPjDGuHagSowq/DcfwKWPRm+hNqIiu3s5SFJbdgJJ9pnRseXj+xNbY7zRagJOyY+Zk2ceVy
85122DxOj7NSrXXWZMRcPUjYTqmje1W82aAAAAAAAAA
--GZVR6ND4mMseVXL/--