SUBSUBTITLE: "I can't test what I obviously don't understand, and don't care to."
So often code goes live (or stays live) just as defined in this post's title: production in lieu of testing.
Put this thinking together with vendor/developers who clearly don't understand security risks, and you end up with a spectacular FUBAR.
First, a rhetorical question:
Why is testing (security and QA) so often neglected, overlooked, ignored, or poorly conducted?
The answers we've all heard:
We have to get product to market, we can't waste time.
We're so resource limited, we don't have enough time and people to test properly.
Second, what happens when a vendor/developer combines bad testing practices with carelessness?
Let's use AgoraCart as an example. I reported an AgoraCart CSRF vulnerability via Secunia, that is now live with an advisory.
NOTE: I am discussing this in full detail given that the vendor clearly indicated the issue as a "won't fix", or perhaps more succinctly, "no clear understanding of why to fix", as seen below.
Let me summarize the vendor's response; you tell me if it sounds like a pilot program under our above definition. ;-)
"...they'd also need to know the exact location according to this... plus it would have to have no other security measures installed. So it's very obscure and relies on being tricked form outside sources such as infiltration via PHP weaknesses etc, then the outside source would have to have the exact path AND still have a session active (which would only target one site). Too much "IF" in this one. I'm finding this bug too speculative and too dependent upon things found only in a lab.
The last time we had a bug like this come to our attention, it was the same scenario, but we had it verified to be the opposite of the claims. So I'm doubtful on this one unless we can actually verify it in a wild situation that is standard for implementation.
So I'll need more time to find this so we can fix it or show that it's minimal or whatever needs to be done. But so far we have been unsuccessful on our live servers and looking for others to do testing on."
Er, what? Really?
Oh boy.
I'll address these one by one.
1) "They'd also need to know the exact location".
Sure, that the nature of exploiting web application vulnerabilities. A little spidering, a snippet of tampering, play a little fuzz the parameter or pass the unchecked request and the game is afoot.
2) "plus it would have to have no other security measures installed."
Uh, no. If your web app doesn't prevent forced administrative requests made by the authenticated user on behalf of the attacker, no other security measures will prevent this attack.
3) "it's very obscure and relies on being tricked from outside sources such as infiltration via PHP weaknesses etc"
Man, it's getting thick now. The only trickery required here is that someone clicks a link in an email, or if the attack is GET based, simply visit a malicious GIF. Being tricked from outside sources such as infiltration via PHP weaknesses? That doesn't even make sense. Are you kidding me? The only weakness here can be found in your responses. Ask the CEO of StrongWebmail about being tricked from outside sources. He can tell you all about it.
4) "then the outside source would have to have the exact path AND still have a session active (which would only target one site)."
Yes, but again, PATH as you define it, is incredibly easy to determine. And social engineering never worked to exploit someone with an active session, right?
5) "I'm finding this bug too speculative and too dependent upon things found only in a lab."
I simply don't know what to say to this one. Wow.
5) "I'll need more time to find this so we can fix it or show that it's minimal or whatever needs to be done. But so far we have been unsuccessful on our live servers and looking for others to do testing on."
Come on, man, I sent you a clear cut example with source code via Secunia; they even added another one to try and help you understand.
IT WORKS ON ANY VERSION OF AGORACART...ANYTIME, ANYWHERE.
Here's how easy it is in a nutshell. The exceedingly simple PoC below will change htaccess settings for AgoraCart via CSRF, via POST request when a victim clicks a link for this page:
Secunia's example showed how to change the AgoraCart admin password.
Perhaps a video of a similar weakness in the osCommerce shopping cart may help convince AgoraCart to revisit this.
As shown at DEFCON, this video shows a CSRF vulnerability that leads to immediate credit card compromise via an admin account creation (one click, one account, done deal).
So if PoC code and multiple communications with clearly stated risks associated with this vulnerability aren't enough for AgoraCart, and a video explanation of the weakness in a similar product doesn't provide sufficient motive, I'm not sure what will do the trick.
Perhaps this lax attitude explains why BlueHost decided to drop AgoraCart all together. ;-)
FIRST TIME SALES QUESTION [5:36:33 PM]: Did you folks get rid of AgoraCart as a shared server offering?
Corbin [5:36:45 PM]: We did yes
FIRST TIME SALES QUESTION [5:37:47 PM]: Ok. Thanks. No worries, but any idea why?
Corbin [5:38:10 PM]: fewer then 5% of people were using it so we decided it was not worth keeping
FIRST TIME SALES QUESTION [5:38:28 PM]: Good call. Buggy anyway. Thanks, Corbin. G'nite
So that's it: no need to fix what no one uses. ;-)
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
No comments:
Post a Comment