CSRF: Six Degrees of Kevin Beaver (or at least his printer)

Perhaps you followed the CSRF debate between RSnake and Kevin Beaver last month.
While I fall well on Robert's side of the tracks, Kevin made some interesting points.
I may take issue with some of them (ok, almost all of them) but Robert took him to task, and I'm pretty sure Kevin has done his penance ;-), so no need to beat that dead horse.
Except that scanner comment. Scanners <> CSRF detection; it's a largely manual check, and it actually does exist significantly more often than you might think (pretty much everywhere). Watch your Tamper Data or Burp sessions for requests made without tokens/formkeys/canaries, etc. and you'll soon know what I mean. There is no "high-quality vulnerability scanner" that will solve the CSRF challenge for you.

No matter your view or perspective, CSRF is pervasive, annoying to fix, and still lurking everywhere; it can be used to pwnzor your printer, your APC UPS, your website's shopping cart or CMS, or any other damned thing you expose to the Intarwebs that fails to check "exposure to unintended requests."
What value these targets? Depends on your motive.
Stealing printer resources? Probably not. ;-)
But a CSRF attack against a website operator who's using the likes of osCommerce, Zen Cart, or eclime (15 million+ at last check) and is foolish enough to be using one of them to manage credit card data? Game over.

Heck, CSRF vulns are so widespread that we could rate number 5 on the OWASP Top 10 like a video game...Rated E for Everyone, just like your Mom. Ohhh!

When I popped my new HP Photosmart C4700 on my home network and changed the admin password via CSRF with twenty second's worth of HTML, it all came to a head.
How do you patch that?
Vendors like HP and APC, who are extremely responsive to disclosures, no matter how low hanging the fruit, still can't easily update their software and expect all customers to apply the fix.
Then there all the vendors who do nothing (you know who you are).
Good code and responsible vendors are paramount, but so too is consumer awareness and understanding of risk.
What if a properly targeted "one click" attack turns off the power outlets on a UPS device with a hospital's ICU servers connected to it?
Is life in the balance?
Our "mysterious" web bug changes the nature of that very question.
Overly dramatic, sure, but you get the point.
Who'd be to blame under those circumstances?

So what's the solution (write secure code)?
I recognize that I'm asking more questions than providing answers (write secure code), but I'm at a loss as to how to solve poor coding practices easily (write secure code). Perhaps you, dear reader, have some ideas (write secure code).

Maybe RSnake should just CSRF Kevin Beaver's printer, force it to print a bunch of copies of OWASP's Development Guide, and we'll call it good. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Memory forensics with SIFT 2.0, Volatility, and PTK

May's toolsmith takes a close look at SIFT 2.0, the forensics workstation associated with the SANS 508 track.



SIFT 2.0 is best utilized as a VM via your preferred version of VMWare but can also be installed as a permanent standalone workstation.
I spend much of time touting memory analysis as a key component of incident response and forensics, and SIFT 2.0 offers two of the most capable memory analysis offerings available: Volatility and PTK. As I say in the article, I don't do either tool the justice it deserves but it should whet your appetite. I owe both Volatility and PTK their own write-ups, if not the MoonSols Memory Toolkit as well.
Regardless, SIFT 2.0 is extremely practical for forensic processing and case management. Assuming you have a decent storage footprint, you can opt to keep a unique virtual instance of SIFT for each case your handling.
For this article I used SIFT with Volatility and PTK to dig more deeply into a victim memory image of a Banload-infected host.
You'll quickly see how to get right to the bottom of an incident using only memory analysis.
The article is here.

Cheers and and enjoy.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)