DEFCON 17 Presentation and Videos Now Available

Mike and I presented CSRF: Yeah, It Still Works to a receptive DEFCON crowd, where we took specific platforms and vendors to task for failing to secure their offerings against cross-site request forgery (CSRF) attacks.

Dan Goodin from The Register did a nice write-up on the talk wherein he cleverly referred to some of the above mentioned as the Unholy Trinity. ;-) See if you can spot in the presentation slides why that reference is pretty funny.

For those of you who are interested in the talk but weren't able to attend, the presentation slides are here, and links to the associated videos are embedded in the appropriate slides. The videos are big AVI files so you'll be a lot happier downloading them.

I'll be following up on some very interesting questions that arose during Q&A after this talk, so stay tuned over the next few weeks for posts regarding sound token implementation, CSRF mitigation and Ruby, and the implications of CSRF attacks on forensic investigations.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

DEFCON preview: Netgear RP614 CSRF attack video

To give you a sense of what Mike Bailey and I will be covering at defcon 17 this Saturday at 11am, I thought I'd give you a little taste courtesy of a Netgear RP614v4 router that suffers from cross-site request forgery (CSRF) vulnerabilities, as well as persistent cross-site scripting (XSS) issues.
See OSVDB advisory 54885 for further specifics. BTW, please support OSVDB!

The short version:
The Netgear RP614v4 web-based administration interface allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. This can be exploited to perform administrative actions or conduct script insertion attacks e.g. when a logged-in administrator visits a malicious web site.
The sad truth of the matter is this, while I don't have access to the whole Netgear product line, the reuse the same firmware codebase across multiple devices.
Thus, in all likelihood, there are numerous Netgear devices vulnerable to this issue, if not all.
The same holds true with Linksys devices, which we'll cover in detail at DEFCON.

As you will see, the approach is simple, and too often effective.
1) Miscreant crafts email utilizing well proven social engineering methodology.
2) Victim follows orders and, while authenticated to vulnerable device, clicks on that damned link.
3) Vulnerable device does not perform any validity checks to verify the requests made via the attacker's web page lurking behind the link in the email.
4) Vulnerable device fails in whatever fashion it's told to.

As exhibited in the video I've created for your viewing pleasure, I force the admin session to enable remote management (disabled by default) and change the remote management access port to 6667 for old time's sake. If, as it so often is, the admin account is left to default password, game over. Or, in many cases, you can also force a password change via CSRF as well.
Any function the firmware provides can be forced via a victim admin's session; that which is exhibited here is but a single examplar.
Tokens, people...tokens!

The video, as promised:
Lo-fi (5.63 MB MP4)
Med-fi (53.9 MB WMV)
Hi-fi (73.4 MB AVI)

Hope to see you at DEFCON; please say hi if you're there on Saturday.
I'll be easily spotted in jeans and my white Certified Application Security Specialist (ASS) golf shirt.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Presenting at Defcon 17 with Mike Bailey

In case you didn't know, CSRF still works. ;-)
Mike Bailey and I will be discussing this sad fact via CSRF: Yeah, It Still Works at DEFCON 17 at the end of July. We do hope to see you there!
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

eWeek hypes "secure" SaaS without checking the facts

In an article called SaaS Proof Points, eWeek put on the blinders and jumped on the bandwagon declaring such SaaS wisdom as "not only have modern SAAS applications assuaged security concerns, but the SAAS model itself is seen by some as the most secure approach to handling data".
What!? Wow.
Add to that the well-intended declaration of SaaS neophyte Kimberly Rogers of Santander Consumer USA, while detailing her company's use of Service-now.com. Rogers, who had never worked with a SaaS-based application before, added that "security can be as tight as you want it to be." Noting such blind faith from a Service-now.com user I was motivated to take a closer look at the provider.
Kimberly, respectfully, you are making a dangerous assumption.
Putting on my bad guy hat for a second, if I can entice you to click a link in a targeted, specially crafted email (phishing), that in turn executes JavaScript in the context of Service-now.com (cross-site scripting) and returns the cookie you use for authentication to Service-now.com (credential theft), is it still reasonable to assume that "security can be as tight as you want it to be"?
I think not.
Service-now.com suffered from a cross-site scripting (XSS) vulnerability that allowed cookie theft and other XSS fun such as frame defacement.

Before XSS:


After XSS:


Please note that Service-now.com responded to my advisory and made repairs in a reasonable amount of time, all the while communicating admirably.
That said, if SaaS providers don't ratchet down hard on their basic web application security, silly yet valuable data spills such as described above will continue to prevail unabated.
If trade publications continue to publish hype rather than balanced facts I must assume that data breaches and provider shortcomings will continue to be commonplace as said providers won't be held to a higher standard.

When StrongWebmail fell so readily to an XSS vulnerability this past week (well done Lance, Mike, and Aviv), I simply shook my head in dismay. Are service providers so blind as to not consider the holistic security view before putting 10k on the line?
That was a rhetorical question.
Answer? Obviously.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

The McAfee Secure Double Standard

McAfee Secure claims to be McAfee Secure while not McAfee Secure

It's been a rough week for our McAfee Secure friends.
First, an XSS, Iframe injections, and XMLHTTP outing provided by XSSed.com, followed quickly by a CSRF browbeating from The Skeptikal One, Mike Bailey.
While these findings should not come as a surprise, I have no doubt McAfee moved as quickly as possible to resolve the issues.

What sadly should also not come as a surprise is that the entire time these numerous vulnerabilities were live, so too was the McAfee Secure trustmark.

I realize the odds of McAfee Secure removing the McAfee Secure trustmark when they are not McAfee Secure is highly unlikely, it nonetheless exemplifies a double standard.
The key question is this.
If the McAfee Secure customer portal is vulnerable to CSRF for 4-5 weeks while the portal code is under repair, should it declare itself McAfee Secure?

To further my point, language from the McAfee Secure Standard:
In the event that McAfee discovers a vulnerability that prevents a merchant’s website from complying with the McAfee SECURE standard, the merchant will have a 72-hour remediation window. In instances where McAfee believes confidential customer data is at immediate risk, or in those cases where McAfee has evidence of prior compromise, the McAfee SECURE trustmark may be removed before expiration of this 72-hour window.

While the McAfee Secure Standard does not indicate that CSRF by itself is worthy of pulling a trustmark, the fact remains that because Mike had demonstrated what could be done with this paricular vulnerability, such as a live weaponized attack script, McAfee was treating it like a high-priority critical issue.
I can therefore only hope that a McAfee Secure customer under the same circumstances would NOT have been displaying a McAfee Secure trustmark.

So there it, plain and simple, for your consideration.
A double standard?
You decide...comments welcome.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Recommendations for trustmark providers

I've been slow in responding to Pete Lindstrom's (Spire Security) prompt for recommendations and solutions for trustmark (security badge) providers, beyond my typical griping about same.
I appreciate Pete's candor and perspective, and shall endeavor to make amends.
Having repetitively taken issue with trustmarks, with McAfee Secure\Hackersafe facing the brunt of it, I propose the following to ALL trustmark providers, as I did during the creation of the McAfee Secure Standard.

1) Check the arrogance and sales hype at the door.
We have no doubt that you're in business to drive conversions first and security second, so just be honest about it.
We also have no doubt that there will be vulnerabilities in your customer's sites, so cut out the "we guarantee their security" angle and opt for the "we do the best we can to contribute to the security and well being of our customers, and their customers" approach.

2) Practice transparency.
How do you scan (very specifically)? If you simply run Nessus, say so. If you make use of custom algorithms and signatures, say so.

3) Publish your standard, most importantly inclusive of your intentions on how to enforce it.
If a customer's site is not compliant, how and when, if at all, will you pull down the trustmark badge?
I can't believe I'm about to say this but McAfee Secure really has set the standard for establishing a standard. While I believe it to be lacking in areas, at least they have one.

4) Actually enforce.
So often I've found websites in flagrant violation of any feasible security standards, and yet they display a trustmark. This simply should not be. It is misleading, dishonest, and deceptive.

5) Offer resources.
As an alleged security provider, offer your customers resources. Not just the "use SSL and all is well" bunk. Real resources: OWASP, SANS Top 25, SDL, how-to, the list goes on.

6) Provide an immediately evident point of contact for your trustmark program; an abuse@, security@, and/or info@ alias to which we can report sites we determine to be vulnerable.
I have found it difficult in the past to disclose vulnerabilities; it shouldn't be.

7) Offer incentives.
People often do well with incentive. A reward system for strong security practices demonstrated by your customers will reap benefits, and adversely, so too will a punishment system for non-performers.

Note: Keep a close eye on Skeptikal.org. Mike's of the same mindset, and has applied this spirit of thinking to PCI ASVs who themselves have missed the mark on security, while holding others to the embattled PCI DSS. Look for some interesting content next week.

Finally, dear trustmark provider, think integrity. Operating from that position should lead you down the right path.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: Visa responds quickly to reported vulnerabilities

The American Express online flaw I discussed last week led to two interesting sidebars.
First, a rather strong media response resulted with coverage in The Register, BetaNews, and Dark Reading, amongst others.
Second, aside from all the variant hunters, I received a number of interesting finds from friend-of-the-cause Mike Bailey over at skeptikal.org.
He'd been inspired by the fact that the PoC I issued for the AmEx bug included an IFRAME insertion pointing to Visa.com. Inspiration led to discovery (and whole lot less work for me) and immediate issues were noted in a few Visa sites.
To be fair, http://usa.visa.com itself appears to be sound; both Mike and I gave it a cursory glance and nothing popped up (XSS pun).
The same could not be said for http://empresarial.visa.com.
No need to rehash all the problems XSS issues in major credit card company sites might cause (PCI compliance, phishing, customer abuse, etc.); earlier posts speak for themselves.
As always, I reported the vulns per my terms of engagement.
Here's where the rather unexpected occurred.
I first reported the issues on December 17th at 1322 hours PST.
They were fixed no later than December 18th at 1916 hours PST.
In essence, Visa executed a 24 hour turn around for mitigation and repair.
Now, I have no doubt variant hunters will likely go digging about for other vulnerabilities, and if Visa hasn't issued global repairs, they might find some.
But, what's key here is how quickly Visa responded. I must admit, after the debacle born of the AmEx issue, I wondered if I'd be asked to report the vulns through Visa's PR department, a method recommended by AmEx to report vulns to them. ;-)
Not only was my disclosure responded to in a very timely fashion, I received the following feedback:
"We appreciate you bringing this situation to our attention. Visa takes security matters very seriously. All impacted pages have been taken down while we remediate the XSS coding. As always, feel free to report any future abuses to: abuse@visa.com."
Hard to argue with that.
My impression (unsubstantiated) is that the vulnerable sites were the product of a 3rd party development team, serving Spanish speaking customers, given the fact that the vulnerable code was PHP, not typical of English language Visa properties.
For posterity's sake one of the vulns appeared as follows. There were other similar issues with different variables, different sub-domains, and partner sites, but you get the point.

XSS in empresarial.visa.com/por/glossario.php:



I'd like to issue a "well done" to Visa and those who responded so quickly.
I can only hope that pending disclosures to all the other credit card vendors, banks, and brokerages in the Online Finance Flaws pipeline are handled as quickly and openly.
Thanks again to Mike Bailey (mckt) for his contributions to the cause. You'll see more of his work in future posts.

del.icio.us | digg | Submit to Slashdot