Re: Security Advisory Update (XSRF issues)

[John Locke <..hidden..>]

Hi, Chris,

Wow, that sounds like a pretty sophisticated attack. I would tend to
think it would be much easier to trick the sysadmin with the root pw
into granting sudo rights that let you into the database itself... how
much prevention is really necessary?

I do see the need for good CSRF protection, and I think Drupal has a
pretty solid approach built into their form API that does something
similar--stores a session and form identifier while a user has a form
open, changing it on each request. It also has an easy way of bypassing
this check if you're interacting with the form api directly (bypassing
the browser). It's fairly convoluted but seems like a pretty well-tested
approach that might be worth borrowing.

But I'd tend to echo Michael's comment about a good audit logging
system, that the best way of addressing the type of attack you outline
below is through a separate control, making it so that each transaction
has some extra verification log that could be scanned to find discrepancies.

After all, the attack you describe could be done by the CPA or any
bookkeeper with appropriate access level, without additional technical
help, no need for a CSRF attack. Isn't that the whole point of controls,
to make it so that you can easily detect malicious activity of insiders?

I guess I'm just suggesting that after doing the easy stuff to block
CSRF attacks, I'd rather see a really good audit log that's very
difficult to forge and easy to understand, rather than a whole lot of
work protecting privilege-escalation attacks that are already quite
difficult to exploit. For most of the businesses likely to use
LedgerSMB, the more significant/damaging attacks are likely to come from
those who already have the privileges!



Cheers,
John Locke
http://freelock.com




-------- Original Message  --------
Subject: [Ledger-smb-users] Security Advisory Update (XSRF issues)
From: Chris Travers <..hidden..>
To: LedgerSMB <..hidden..>, Development
discussion for LedgerSMB <..hidden..>,
LedgerSMB Users <..hidden..>
Date: Thu 28 Jan 2010 09:08:57 AM PST
> Hi all:
>
> Secunia has listed the XSRF issues (which are systematic in the legacy
> codebase) as "partially fixed."  I want to take a moment to explain
> what their concern is, what mitigating measures can be taken in
> production versions, and what the risks are.  I will also explain what
> we are doing in the future to address the issue.
>
> Status:
>  * Easily exploited cases are fixed in latest patch.
>  * Very complex to attack
>  * Successful attack is fairly severe
>  * Risk can be mitigated to a large extent.
>
> XSRF is a type of attack where a third party web page fools a browser
> into making requests to the application that appear to be valid.
>
> The general risk is that an individual in a bookkeeping department,
> colluding with someone with substantial technical knowledge and either
> working on a company intranet site OR compromising an important third
> party web site could use this to falsify financial data by tricking
> other users into entering information for them.  This could then be
> used to cover embezzlement activities and the like.  Any
> vulnerabilities that are of this nature we consider substantial given
> the nature of this program.  Unfortunately a fix isn't trivial and
> would probably break things.  Nevertheless, I will probably create a
> referrer-checking patch that can be optionally installed to prevent
> this sort of attack absent unusual circumstances.  I also expect we
> will make full fixes for the issue (described below) required for 1.3.
>
> The general requirements for an attack of this sort is to create a
> malicious web site that members of the accounting department come back
> to visit for an extended period of time.  It also requires deep
> insider knowledge of the internals of the accounting database (for
> example, which id numbers correspond to which entries).  For this
> reason, the complexity involved in a successful attack is really very
> high.  Web mail programs might provide some additional vectors, but
> even there, with proper configuration, the chance of such a sustained
> attack being both successful and undetected would be far lower.
>
> For this reason, we consider the vulnerability to be a substantial
> problem but not one sufficiently severe that everyone should be overly
> worried at this point.
>
> For versions of 1.2, my recommendation is to set the timeout value for
> each user to the minimum practical value (perhaps 60, 120, or 180,
> timing the session out after 1, 2, or 3 minutes respectively).  This
> can be done from the admin page or the psql prompt.  This is important
> because a successful attack would require many successful exploits of
> this vulnerability.  If any significant set fails, then, in all
> likelihood, routine accounting audits and reconciliation will pick up
> the misbehavior.  Please stay tuned for a referer-checking patch, as well.
>
> This is not (generally) an exploit that could be exploited by
> customers seeking to record bogus payments and would really require
> inside access to be a problem.
>
> Combined with standard accounting controls, a low timeout should be
> sufficient to prevent problems arising from this vulnerability.
>
> For versions of 1.3, we expect to resolve this issue the following way:
> 1)  All forms will have a 'form_id' attached which will be
> pseudo-randomly generated.
> 2)  When a form is submitted, the form_id will be checked against
> what's stored in the db for that user and if authenticated will be
> processed normally.  If the form can be double-submitted (for example,
> to print an invoice as opposed to posting it), the form will be left
> associated with the user.  If the form cannot be, it will be deleted
> from the db when the form is processed.  This will make XSRF
> impossible in a reliable way because it will require guessing the form
> value.
> 3)  When a session times out, the associated forms will be lost.
> 4)  If the form submitted is not associated in the db, a message is
> logged, and the form is updated with a new form_id and sent back to
> the browser.
>
> If anyone has specific concerns, feel free to email me.
>
> Best Wishes,
> Chris Travers
> !DSPAM:4b61c5b6209932788099809!
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
>
> !DSPAM:4b61c5b6209932788099809!
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ledger-smb-users mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
>
>
> !DSPAM:4b61c5b6209932788099809!
>