Application Security Specialist: Don't Fall Behind

I've long supported certifications, in concert with experience, to be used as a measuring stick for the likely success of individuals in the information security field.
SANS, of course, offers significant value on this front,and what security professional is ever given due consideration without their CISSP?
When I was asked to participate in the Application Security Specialist pilot program, I jumped on the opportunity. And now, having become an ASS, my career has simply blossomed.
With the increased credibility it offers I've been able to demand more per hour for pen testing engagements.
I've even gained the respect of vendors and merchants alike; they're now less likely to blow me off when I tell them their apps are broken.
Given the pilot program I participated in, I can only say, now that its widely available, you should become a Certified ASS as soon as possible.
You can even join the LinkedIn group here.
Being an ASS is all it's cracked up to be!

Certified Application Security Specialist

The 100th post: Philosophy feeding action

As I was writing this I realized that this is my 100th post, and it therefore seemed somehow significant. With some interesting personal news to report it also provides me with the opportunity to declare a current philosophical mission statement:
No matter the activity, be it researching, advising, and disclosing ailing web applications, tracking malware attributes, or researching and documenting useful tools and methodology for incident responders and security professionals, I do it for one reason.
I simply believe it is our inherent responsibility to try to thwart miscreants in anyway possible. There are too many of them, and too few of us. Thus, the more we disclose and fix, the better we understand maliciousness, the stronger our implementations and investigations, the more secure we may become.

Two recent developments speak directly to this philosophy:
1) The Solutions Accelerators group at Microsoft, my employer, asked me to write the IT Infrastructure Threat Modeling Guide, born of an ISSA Journal toolsmith article I'd written on PTA (Practical Threat Analysis).
2) I was invited to join the APWG Internet Policy Committee, born of conversations with Dave Piscitello regarding the Anatomy of an XSS Attack.

First, with regard to the IT Infrastructure Threat Modeling Guide, this guide takes the SDL appproach to threat modeling and applies it specifically to infrastructure. When the beta goes this Friday, you can register and provide feedback here.
One can consider threats to IT infrastructure from four specific perspectives:

1) Re-architect and re-implement to eliminate them.
2) Apply well understood mitigations.
3) Invent new mitigations.
4) Accept the risk.

These are entirely viable perspectives, but the practice of threat modeling your infrastructure must precede these considerations.
To that end, the IT Infrastructure Threat Modeling Guide is designed to help IT professionals accomplish the following:

• Identify threats that could affect their organizations’ IT infrastructures
  
• Discover and mitigate design and implementation issues that could put IT. infrastructures at risk.
  
• Prioritize budget and planning efforts to address the most significant threats.
  
• Conduct security efforts for both new and existing IT infrastructure components in a more proactive and cost-effective manner.

Second, with regard to the APWG Internet Policy Committee, my intended focus here is to participate in guidance to help harden web services in defense against the dark arts...cybercrime, phishing, fraud, etc.
To get a better sense of what the APWG IPC is all about, see see Co-Chair Laura Mather's series on online fraud here.

As pertinent to either of these recent developments, I invite feedback and participation. Please feel free to contact me via comments here or email.
This work, this blog, my philosophy, my mission, are all carried out with you in mind, dear reader.
I thank you for your support and readership, and I look forward to the next 100 posts.

del.icio.us | digg | Submit to Slashdot

Why trust marks can't be trusted

Trustmarks & security badges don't provide security, just false confidence.

Hopefully,a month or so ago, you noticed the headlines and have read that Geeks.com, via its parent company Genica Corp, has settled with the FTC and will allow "allow federal regulators to monitor its website security for 10 years to settle charges it violated federal laws requiring it to adequately safeguard sensitive customer data."
I'd be remiss in my duties if I didn't remind you, dear reader, that Geeks.com was a Hacker Safe (now McAfee Secure) site.
I'm certain that if you've ever read my blog before you know I've taken McAfee Secure to task numerous times, and consider my point well established.
It's all really part of a larger discussion that should come as no surprise.
The only value of a trust mark/security badge is to the merchant wielding it, often under false pretenses. I've not met a trust mark yet amongst whose customers I couldn't find web application security flaws.
Forget what this means for PCI compliance. Every one of the examples I'm about to present is likely beholden to PCI in some form or fashion.
The reality is, they all display a trust mark, and aren't worthy of that trust. Consumers are at risk, plain and simple.
Let's explore, shall we?
There's WebSafe Shield's Hacker Free Site, or Comodo's HackerProof, perhaps Security Metrics Credit Card Safe(more on them in the near future), and my new favorite in security hilarity, Control Scan.
Remember former Hacker Safe fangirl, Cresta Pillsbury, she of "we go in like a super hacker" fame? When she jumped ship with jaded judiciousness, she placed herself squarely in Control Scan's camp carte blanche. Talk about the blind leading the blind.
In the interest of protecting customers and merchants (who've ignored disclosure notices), I'm going to provide screen shots a variety of vulnerabilities, without indicating who sufferers from it specifically. Rather, we'll focus only the trust marks displayed handsomely next to the realized vulnerability.

We'll begin with WebSafe Shield's Hacker Free Site. Here's an example IFRAMEd with a real trust mark innovator, Scanless PCI:



Here's a ControlScan customer, IFRAMEd with XSSed.com:



Finally, this one's my favorite. This is a Comodo Hacker Proof site (you'll have to trust me on this (pun intended)), helpfully barfing database schema for the world to read:



Need I remind you that any merchant receiving customer PII and credit card data that is vulnerable to XSS, CSRF, or SQLi is not Hacker Proof, or Hacker Free, or Hacker Safe?
They should simply be labeled Hacker Ready.

*sigh*...now I'm depressed.

Thanks to Joe Pierini for participating with me in this conversation for some time now.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: At least AIG got this one right

As our economic conditions worsen, and the gloom and doom chatter intensifies, much attention has been paid to AIG. The crux of the AIG dilemma, to hear Ben Bernanke say it, is that they're too big to let go under, but most observations indicate they deserve to.
"I share your concern, I share your anger," Bernanke told the Senate Budget Committee. "It's a terrible situation, but we're not doing this to bail out AIG or their shareholders. We're doing this to protect our financial system and to avoid a much more severe crisis in our global economy."
Add to that this past week's disclosure that AIG will pay out $170 million in tax payer dollars as bonuses, and today's news that the $170 billion at large is basically already all gone.
Thus, the list of big finance companies becoming fodder for verbal abuse and regulatory oversight just keeps growing.
That said, I am neither an economist or even remotely intelligent enough to speak on these issues with authority, but there's one issue I know relatively well.

As part of the ongoing Online Finance Flaws series, AIG suffered from a cross-site scripting vulnerability in their search script.

I apologize in advance, I couldn't resist a little political, current events humor at AIG's expense as I chose to drop in an IFRAME with a relevant news story.

AIG before:



AIG after:



I initially took note of this vulnerability on sla.ckers.org. It occurred to me that, in all likelihood, no one had bothered to tell AIG. After pinging my circle of industry folks with good contact lists, to no avail, I decided to try winging my disclosure and advisory effort to see what might come of it.
I sent email to abuse@, as well as two other aliases I found on the AIG site security page; specifically, corporatelegalcompliance@ and aig.iaig@.
I received an almost immediate automated response with a ticket number (a good thing), a call from an AIG information security resource the next day (a really good thing), and a week later the issue was fixed (a great thing).

So, as I sit here watching my 401k and investment portfolio fall in value by 75%. due in large part to one group at AIG, I can rest comfortable that another group at AIG (information security) is doing its job well. ;-)

del.icio.us | digg | Submit to Slashdot

asSaaSsinated: more on SaaS & cloud risk

As previously discussed, SaaS represents frightening scenarios for well intended enterprises seeking to offload cost and resource demands. The same motives are driving businesses into the cloud like lemmings off a cliff.
Yet, these businesses/enterprises may not conduct best effort diligence when it comes to ensuring their vendor of choice is managing their security properly.
Under such circumstances, their well being in the SaaS realm could well be at risk.
Consider previous examples such as Online finance flaw: one flaw to rule them all, or the discussion regarding Sage Live.
Enter Baynote, whose offerings include Social Search.
Following the principles of one flaw to rule them all, a single validation error in the q variable found in http://[Insert customer here].com/socialsearch/query?cn=[customer]&cc=us&q= led to numerous Baynote customers falling prey to cross-site scripting.

VIDEO

To their credit, Baynote was responsive and fixed the issue quickly (well done!) but the issue exemplifies ongoing risks to customers and consumers.
To that end, I've offered some common sense guidelines for businesses (in particular finance, but applicable to all) regarding questions to be asked of SaaS provides.
The article is available at SearchFinancialSecurity.com.
This is an issue we all need to pay close attention to. SaaS vendors take on an entirely new level of responsibility with each customer they add. If they treat the process in the same manner that Sage did, trouble awaits in abundance.
Ask the right questions and expect clear, thoughtful concise answers.

del.icio.us | digg | Submit to Slashdot

Why PCI DSS is in a continued state of fail

Data breaches abound, half a million sites fall to SQL injection in 2008…the headlines are horrific and leave me to wonder.
Where does the PCI DSS fit in all this, if at all?
According to the WHID report about the rampant SQL injections, 11% of the sites were finance oriented and another 11% were retailers. According to my mad math skillz, that indicates that it is possible that 22% of 500,000 sites that fell to SQL injection attacks last year were beholden to PCI DSS. That’s 110,000 PCI sites that apparently failed to meet a very basic standard.
With my ear to the tracks for ongoing indiscretions, a delightful tidbit hit my radar, courtesy of a cheeky fellow in the UK named Michael Kemp of clappymonkey, who, whilst recently bored, was exploring the PCI Security Standards Council (PCI SSC) website, when lo, what did he find?
Yep…a lovely XSS vulnerability, in all places, the PCI QSA search script.



Mike indicates a swift fix on the part of PCI SSC on his blog, but I must say, this finding lends itself to some serious questions. I simply couldn’t let something this rare pass by unfettered.
1) Why isn’t the PCI SSC applying its own standard to itself? Fortunately, given no apparent forms oriented to taking payment card information on https://www.pcisecuritystandards.org, they’re not beholden to their own standard. But it would seem that a WAF or a review of site code per PCI DSS 1.2 Section 6.6 to prevent cross-site scripting as indicated in PCI DSS 1.2 Section 6.5.1 would be in order, yes?
2) Are we to believe, if PCI SSC doesn’t adhere to its own standard, that anyone else will, except during the annual audit? As there is little to no enforcement of PCI violations, it seems unlikely that PCI DSS will continue to be any more than a self-congratulatory security check list method with which enterprise can meet minimalist requirements once a year.

Allow me further the point.

CSRF falls under PCI DSS 1.2 Section 6.5.5. As part of my ongoing effort to cure the world of ailing web apps I recently disclosed a CSRF vuln in osCommerce. In discussing that vuln with Mike Bailey, he immediately found and disclosed a similar issue with Zen Cart. A couple of quick Google searches yield extraordinary numbers.
“powered by oscommerce” and “powered by zen cart” returned a combined 11,630,000 results!
Now let’s say for argument’s sake that just half of those results point to a legitimate site running the software (probably a low estimate) for a total of 5,815,000. Let’s further assume, because that both these vulns were disclosed recently, that a large majority of these sites are still running vulnerable code. How about half again? We can therefore surmise that 2,907,500 sites might currently be running code vulnerable to CSRF attacks. For our final assumption, how many of those sites are likely required to meets PCI DSS 1.2 standards. By my calculations…ALL OF THEM. You run osCommerce and Zen Cart to take online orders, paid for by credit cards.

So what then are we to say of PCI DSS in its current state of lax enforcement, double standards, and ill begotten data losses? I say, “For shame." PCI DSS could provide so much more, and offer better protection for the many, from the devious few. A standard is only as good as the extent to which it's enforced. The fact that the PCI SSC site didn't even meet its own standard indicates a significant credibility gap. It is my hope that they'll be reviewing their site regularly in the hopes of avoiding embarrassing and preventable flaws like this.

del.icio.us | digg | Submit to Slashdot