CSRF on the increase per two reports

As I've spent almost all of my research time this past year focusing on finding and disclosing (coordinated) CSRF vulnerabilities, it was with some amusement that I read CSRF Vulnerabilities Rise, Overall Vulnerability Disclosures Dip from Kelly Jackson Higgins last week.

Therein she states that "overall, the number of vulnerability disclosures for the year is gradually declining to around 4,500 from nearly 7,000 last year, with the exception of CSRF, which had 155 vulnerabilities as of the first half of the year." This article is ultimately referring to TippingPoint DV Lab's Top Risks report.
Wolfgang Kandek, CTO at Qualys, follows with "CSRF is difficult ... and complex."
I must respectfully disagree, it's really not, but I'll discuss that in a minute.

I was pleased to run into Jeremiah Grossman at the ISSA International Conference last week, and he stated that CSRF has moved up on the imminently pending 10th WhiteHat Security Statistics Report. He was careful to pointy out however that its not because sites are more vulnerable to CSRF; rather, WhiteHat Security customers are more interested in having the issue reported combined with better Sentinel detection.
The point about better detection on WhiteHat's part ties back to my disagreement over the claim that CSRF is difficult and complex.
Exploiting CSRF is really not complicated at all, but it has been historically difficult to discover via automated scanning (sorry, Kevin ;-). There are nuances that require fairly significant manual interaction with a potentially vulnerable application; enumeration and parameter reconnaissance is required, followed by building forms specific to various POST requests. Consider Tamper Data your bff for this effort. Most importantly, noting the lack of a token/formkey/canary is generally the first, best step to determining CSRF vulnerability with targeted manipulation thereafter.

Of the 155 CSRF disclosures mentioned in Kelly's article for the first half of 2010, 14 are advisories I submitted through Secunia and are widely varied in their scope.
You'll note the expected vulnerable CMS platforms, but you'll also find HP printers, server logging agents, system management interfaces, and web mail providers.

My point is this, CSRF is not hard to find, is easy to exploit, and often remains unrepaired in web applications long after the other OWASP Top 10 biggies have been fixed.
Token up, people!

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Everybody Loves REMnux

A quick read of the SANS Forensics blog, courtesy of Gregory Pendergast, and you'll get a feel for all the positive feedback for Lenny Zeltser's REMnux.
Lenny has dedicated himself to furthering the malware reverse engineering cause, both as a teacher and analyst; his SANS courses are popular for good reason.

September's toolsmith covers REMnux and offers some detail specific to its use.

One area I often use REMnux for is malicious Flash analysis.
Evil Flash, distributed in particular via online advertising platforms, is a constant concern for online providers. Suffice it to say that my team has encountered such problem children more than once. ;-)
As an example, an older sample (MD5: 525445764564B34070CF2F9DCC6C2DAA) makes for a great test case. You can grab the sample for your own testing at OffensiveComputing.net.
Imagine you've grabbed the sample via wget from your REMnux VM, after proxy-based analysis of the malicious URL.
A simple check for interesting results might be the likes of
flasm 525445764564b34070cf2f9dcc6c2daa.swf, which would result in a .flm file named identically for SWF file analyzed. Figure 1 shows the concatenated results.


Figure 1

While flasm is convenient, the preferred method would be
swfdump -Ddu 525445764564b34070cf2f9dcc6c2daa.swf
The -D switch provides full (everything) output, the -d switch prints the hex output, and -u shows the Tag IDs.
Figure 2 offers the results.


Figure 2

Note that that the DEFINEBUTTON2 config for Tag ID 4 grabs an URL then issues the ActionScript FSCommand:exec to execute arquivo.scr (never a good thing).
Tag ID 4 was conveniently named "bot" by its creator; why bother hiding, right?

With a modicum of effort, maliciousness confirmed, you're ready to take action: report the malicious SWF to the provider, or remove it you are the provider.

You'll enjoy REMnux; it's an excellent collection of useful tools gathered in a simple but functional distro.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)