Sunday, May 31, 2009

MIR-ROR, for incident response

You can’t publish a cool tool without a cool name.
To that end, I am proud to present:
MIR-ROR: Motile Incident Response – Respond Objectively, Remediate.
If that doesn’t qualify me as an uber-dork (like that needed qualification), nothing will. ;-)
I was rooting about all my USB fobs and discovered one I received while at LE Tech last year. Hiding therein was a handy script that Microsoft forensics mastermind Troy Larson had written to gather investigative data from target machines using a USB stick. I reached out to Troy, and he graciously agreed to allow me to brand the script, as well as maintain and optimize it for your use during incident response engagements.

I consider MIR-ROR a specialized, command-line, RAPIER-like script that makes use of the all-important Windows Sysinternals tools, as well as some other useful tools. Further, as you will see, you can easily enhance the script to your liking with whatever command line tool tickles your fancy.

Incident responders and handlers, malware hunters, and system investigators will all find MIR-ROR useful with one caveat. MIR-ROR is noisy, if you need to maintain forensic integrity, take an image and investigate at your analysis station.

Download MIR-ROR at the project site.
For my complete toolsmith article, courtesy of the ISSA Journal, download it here.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Thursday, May 28, 2009

WhiteHat's trustmark program as a game changer

I am a trustmark hater, I admit it; this should surprise no one.
I have labored long and hard over this post, but I believe it to be relevant and important.

WhiteHat Security, the genesis of Jeremiah Grossman's vision for web application security, has instituted a trustmark program.

Carefully branded a Security Certification Program, this offering seeks to raise the bar on the trustmark concept, a game changer if you will.
On one hand, this won't be hard to do.
As I have in the past, I could rail against the dime a dozen, pseudo-fraud programs that are nothing but conversion gimmicks designed to drive sales through falsely gained consumer confidence. They can all take their Nessus scanners and bugger off.

Instead, I'd like to describe why I think WhiteHat Security can shed new light and standards on this concept.
1) Reputation: WhiteHat Security has always been a premier brand in the realm of web application security. This is indisputable. Their scanning engine, their business model, their personnel are all geared to the cause; they are expert in this field.
2) Value of the service: I know first hand how much WhiteHat labored over the process of offering a Security Certification Program, i.e. how to do so without falling into the same lameness all the others so readily exhibit. This program is not about conversions first, security second. The certification is only offered to WhiteHat Sentinel customers. While there are no guarantees, if you are Sentinel customer, the statistical likelihood of your exposure to web application security flaws goes down exponentially should you choose to fix the flaws they discover. I know this not due to whitepapers or marketing claims, but from experience.
3) Lack of arrogance or false claims: A trustmark that reads "Website Security by WhiteHat Security" is not claiming to be Hacker Safe, Hacker Proof, or Hacker Free. Clicking the trustmark leads you to the following:
"This site employs WhiteHat Sentinel, WhiteHat Security's industry-leading website security solution. To help address concerns about safeguarding your confidential data from security breaches and hacker attacks, the "Website Security by WhiteHat Security" mark appears only on sites that use the WhiteHat Sentinel Service."
No BS, no hype, no false claims of grandure or impenetrability, just simple facts.
4) Jeremiah Grossman: Jeremiah knows this business better than anyone. As a business man he was driven to consider adding a Security Certification Program by customer demand. Whether we like it or not, customers like trustmarks seals, and benefit from them, no matter how lame a trustmark program may be. Customers using Whitehat Sentinel are paying for the privilege, this is not $250 a year scam with no value other than false confidence. Jeremiah's reputation is inherent to the success of this program. He is well aware of the pitfalls, and I know he has the integrity to ensure its value as a real security-first offering.

I expect WhiteHat Security to manage this program from the perspective of an industry standard-bearer, as their first customer has indicated.
Should the rest of the wannabes and posers in the trustmark game raise their standard to this level, I'd have less to talk about.
Good luck and godspeed, WhiteHat, the industry needs your continued integrity in this space.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Wednesday, May 27, 2009

WebTuff checks for WebDAV vulnerability

The folks at Applicure, the dotDefender vendor, have created WebTuff, a free utility to check for the IIS 6 WebDAV vulnerability.
I occasionally run into dotDefender when I'm "analyzing" web application security issues on the Intarweb, and can say that I've been pleasantly surprised by its capabilities.
Please note: This is not an endorsement for Applicure products; simply consider it the suggestion that they are worthy of your consideration.
To that end, a free utility is always a great way generate interest; if your're concerned about exposure to the WebDAV vulnerability, give WebTuff a try.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Wednesday, May 20, 2009

SearchFinancialSecurity: The need for financial Web application security

The current lead story on SearchFinancialSecurity.com is my contribution Why financials must implement Web application security best practices.
This is a follow up piece, a summary if you will, on my Online Finance Flaws campaign, kindly solicited by TechTarget to drive home the point: Is there any one sector more than financial services who must take a stronger stance with regard to Web application security?
Answer: Not that I can think of.
Security hits to financial-services firms have far reaching impacts beyond individual victims, including economic implications that can contribute to global economic malaise.
This article offers examples of flaws noted in major financial-services websites, data from OWASP's Security Spending Benchmarks Project Report as well as best practices guidance derived from security development lifecycle (SDL) methodology.
I invite you to read the article at your earliest convenience.
As always, feedback is welcome.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Monday, May 18, 2009

Desktopsmiley: Annoying and insecure

Adware giant desktopsmiley.com annoys me in ways I can't repeat here (to protect the innocent and moral among you), so I'll keep this simple.

Some facts:
1) desktopsmiley.com is ranked 287 in the world according to Alexa.
This is simply stupefying to me, and testament to the fact that there are way too many oblivious people installing this crapware.
2) The geniuses at Desktopsmiley.com have wrestled long and hard with the antiviruse vendors such that their latest installer doesn't trip a single signature per Virustotal. Further ground for to be much annoyed...and perhaps impressed at their obvious negotiation skills.
3) Desktopsmiley.com has a privacy policy. Rejoice! Now we can all install it and know our data and our privacy is protected. Or not. Just read this dreck and you'll shudder at the clearly defined consequences of installing this "not spyware".

I am therefore inclined to point out that this spectacular product offering cares little for your privacy or your security.

Case in point 2x:
That privacy page? Not so private. It's vulnerable to XSS, and I'm sure this isn't the only example.
Explore for yourself: http://tinyurl.com/qv9zkw

Screen shot, if you prefer.



The next one is particularly fun as it is clearly indicative of bad Flash coding practices. The clickTag variable is wide open on smiley.swf.
Follow this URL, then click the super happy swf! Hurray!

http://download2.desktopsmiley.com/landing/images/tm106/smiley.swf?clickTag=http://cwe.mitre.org/data/definitions/601.html

Can you say arbitrary redirect? I knew you could, boys and girls.

I hereby declare the creation of a new Holisticinfosec award for just such occasions, the ID Ten C Award.
Don't get it? Spell it out and say it with me: ID 10 C...you should be able to handle it from there.
Desktopsmiley.com, consider yourselves awarded, for being both annoying and insecure.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Wednesday, May 13, 2009

WebCollab - Billy Goat security goodness

A quick shout-out to the WebCollab team for a transparent and quick turnaround on security fixes for vulnerabilities I reported through Secunia.
They were prompt, communicative, and thorough in their review, claiming that "this is the first publicly notified issue with WebCollab in more than six years of releases."
I truly appreciate teams who openly address their methodology, the change log, and the core issues.
Well done and thank you, WebCollab. Yours is a model I wish others would adopt.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Tuesday, May 05, 2009

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)

Sunday, May 03, 2009

Homebusinessinstitution.com: Probable fraud, definite XSS

While I've recently been trying to take a more positive tack in my exploration of online security issues, I must digress.
Cable viewers have again been endlessly inundated with Home Based Business advertisements claiming riches beyond your wildest dreams.
You know the one..."I made over $9000 last month working from home part-time."
Right...
Same message, different URL; they simply change the URL every so often. The current domain is 67gogreen.com, others have included crazyfox.com and 46homeworker.com.
All of this complete bulls**t is brought to you by LG Technologies of Temecula, CA, under the premise of Home Based Busines - As Seen on TV.

First, the fine print:
The incomes depicted are not typical and represent a small percentage of actual participants. There are no guarantees that participants will be able to achieve the income levels depicted.

Second, your privacy at risk:
We will maintain a record of your Personally Identifiable Information (PII) that will be sold or transferred to third parties that we believe offer products, services, and/or opportunities that are consistent with your expressed interests. Note that if you voluntarily provide us with Personally Identifiable Information, you consent to our sale, transfer, and use of your information.

Third, security:
We treat your Personally Identifiable Information very carefully and use our best efforts to protect your Personally Identifiable Information against unauthorized access and disclosure.

Do you now? Let's investigate...

HomeBusinessInstitution claims to be VeriSign Secured and are indeed using a Verisign cert. Thereafter, they display badges claiming "100% Safe Secure" and "100% Privacy Verified". Too bad they're both utter crap.
All measures of security (there aren't any) falter drastically, as homebusinessinstitution.com falls immediately to cross-site scripting (XSS).
To exemplify both my dismay and the lack of secure input validation, I offer the following screen shot of customized Javascript executing in the context of homebusinessinstitution.com.



Companies such as this, who exploit the gullible and naive, infuriate me well before I endeavor to dissect their weak claims of securing your PII. To find that their victims are then at further risk leaves me blistering. It strikes me that only their vast disclaimer language serves to protect them from the likes of criminal prosecution or civil litigation.
There's an interesting study of LG Technology and their associates provided here.
I do hope someone finds a way of putting this likely fraud to an end.

del.icio.us | digg | Submit to Slashdot

Saturday, May 02, 2009

SUMO Linux: Security utilizing multiple options



May's toolsmith, in the ISSA Journal, features SUMO Linux: Security utilizing multiple options.

From the column:
SUMO Linux is the brain child of Marcus Carey of Sun Tzu Data in Washington, D.C area. As part of his DojoSec events and training program, Marcus found himself, and his students, frustrated with needing various tools from different Live CD distributions. Powering down, loading a new disc, and waiting until the new one comes up; annoying and troublesome to say the least.
SUMO Linux 1.0 is the genesis of that teaching experience – one DVD to rule them all. First released in November 2008, this young project represents a multi-boot DVD inclusive of five (that’s right, I said five) popular security-related Linux distributions. Bonus!


Sumo Linux includes Backtrack, Helix, Samurai Linux, dban, and DVL.

Grab the DVD ISO, pull down the article PDF, and make quick use of this excellent distribution.
Cheers.

del.icio.us | digg | Submit to Slashdot

Wednesday, April 29, 2009

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

Monday, April 27, 2009

Congratulations to the Open Security Foundation



I was thrilled when I read that the Open Security Foundation (OSF) was named as SC Magazine's 2009 Editor's Choice Award recipient.
I simply can't think of a more deserving bunch.
Congratulations and well done!
OSF is the parent organization for the OSVDB and the DataLossDB.
Their accolades reminded me that OSF is a a 501(c)3 nonprofit, public foundation and as such, benefits from donations. I've been a Network for Good user for a year or so, and it occurred to me that I'd rather have donations made to OSF via my badge than any other organization.
People occasionally try to pay me for helping them out via Holisticinfosec.org; I tell them I'm paid well enough at my day job and writing gigs, and that they should instead donate to my preferred organization.
OSF is that preferred organization, please donate via my badge or straight through OSVDB, if so motivated. I just did; I'd be honored if you'd do the same.
Again, congratulations OSF!

del.icio.us | digg | Submit to Slashdot

Sunday, April 26, 2009

Cloud security commentary falling down on the job

This one made me quite angry in February, but I chose to let it go, with the exception of posting a comment.
Then, recently, I stumbled across it again on Network World and PCWorld and, given that they've taken to regurgitating such inanity, I simply couldn't pass it by again.
Here's the crux of it.
At IDC's Cloud Computing Forum, much mention was made of how much security concerns in the cloud are overblown.
Really?
Brilliant commentary such as follows seemed to be in abundance:
"I think a lot of security objections to the cloud are emotional in nature, it's reflexive," said Joseph Tobolski, director for cloud computing at Accenture. "Some people create a list of requirements for security in the cloud that they don't even have for their own data center."
Yes, Joseph, but here's a secret for you. In their data center at least they can be responsible for security flaws and mitigate accordingly. In the cloud they depend on someone else to address security problems, and if that provider is slow to respond, who knows what mayhem may ensue.
Data breach anyone? Loss of customer confidence?
Yeah, go ahead and blindly trust your reputation to the cloud, complete with everyone at the IDC forum singing its praises and throwing all the key buzzwords around.
It'll be OK...good luck with with that.
Statements from Accenture such as "security objections to the cloud are emotional in nature, it's reflexive" leave me shaking my head in wonder.
Seems like Accenture is really falling down on the job here.
Wait, they really are falling down on the job here. ;-)
This Accenture swf should only load whitelisted, known good Accenture Flash video files.
But it doesn't. It loads any FLV you like, such as this one.
As I said, falling down on the job. ;-)
So, before consuming the wisdom Accenture seems to be throwing about so freely, perhaps suggest that they pay attention to their own security before telling us that cloud security fears are overblown.

del.icio.us | digg | Submit to Slashdot

Tuesday, April 21, 2009

So long Zango, thanks for all the phish

Oh, the joy...trumpets on high, banners waving in the wind!
Zango has been declared dead.
Good riddance, bugger off, may the fleas of a thousand camels infest your...well, you get the point.
As I've been heckling Zango for years, it gives my real pleasure to fire a parting shot. Or two, perhaps three.
Zango, this is for you.
The rest, dear reader, are for your viewing pleasure.
You'll recall that Hotbar is a Zango "product"?

Enjoy...

Props to John Leyden of El Reg for the best title of the day, via a tidy IFRAME.
http://tinyurl.com/c22sxn

An end to SPAM, thanks to Zango and Hotbar...really, I mean it.
http://tinyurl.com/cxhm79

A nod to Maestro Grossman's excellent book via manipulated Hotbar Flash.
http://tinyurl.com/cg7uke

To quote the mighty Marcus Fenix, "Sucks to be them."

Cheers.

del.icio.us | digg | Submit to Slashdot

Tuesday, April 14, 2009

The IT Infrastructure Threat Modeling Guide

After reading a toolsmith article I'd written on PTA: Practical Threat Analysis, Frank Simorjay, a local ISSA chapter member, friend, and co-worker reached out to a peer team in the Microsoft Solutions Accelerators (SA) group and suggested the prospect of something similar to be added to the SA roster.
After meeting with the SA Security & Compliance team, and a couple months of excellent collaborative effort with the likes of SDL expert Adam Shostack, group PM Kelly Hengesteg, editor Steve Wacker, and contributor Jeff Sigman, I authored the IT Infrastructure Threat Modeling Guide, now released in beta on the Connect site.
Sign up for the beta program here, then bookmark this.

Threat modeling has been well applied during the software development process, but there has been a noteworthy, Internet-wide lack of documentation and guidance with regard to applying threat modeling methodology to infrastructure. While many people and organizations threat model infrastructure in some form or fashion, we believed it was time to create a unified process that anyone from a small, one person IT shop, to a major enterprise could follow, and thus improve their security posture.

The IT Infrastructure Threat Modeling Guide provides an easy-to-understand method that enables you to develop threat models for your environments and prioritize your investments in IT infrastructure security. This guide describes and considers the existing Microsoft Software Development Lifecycle (SDL) threat modeling process and uses it to establish a threat modeling process for IT infrastructure.

Please feel free to give it a close look and submit feedback, we really do welcome it.

It is the intent and hope of this guidance that the benefits of choosing to develop a threat model for your IT infrastructure will be many, and that a holistic state of security becomes commonplace for those who undertake the process.

del.icio.us | digg | Submit to Slashdot

Thursday, April 09, 2009

Online finance flaw: Recession humor at Citibank's expense

It should come as no surprise that Citibank would turn up in the Online Finance Flaws series.
Given their active role as root cause participant in our current economic downturn, Citibank has managed to invoke the ire of more than one critic.
The lesson I'll offer here is a simple one, unrelated to economics.
If you outsource development, and fail to manage the process, including the security development lifecycle (SDL), or lack thereof, you put your enterprise at risk.
I admit I am assuming outsourcing in this scenario, but I believe given that the vulnerability was found in a Citibank Hungary offering, I don't think I'm off the mark.
Citibank ignored me entirely so I decided to pass the findings off to the Microsoft Vulnerability Research (MSVR) program and see if the team could make contact with the right folks. The MSVR program is both very young, and in a current state of transition, but they obviously had success as the following vulnerability has been repaired. Hopefully I'll be able to provide more detail on this program in the future.
Citibank Hungary suffered from a cross-site scripting (XSS) vulnerability at the from variable as submitted to the form.jsp script.

It afforded me ample opportunity to inject a little humor (pun intended).
Here's the video if you'd like the long version; please note all the "security" references I capture prior to finding the site to be in complete contradiction to those references.

The following screen shot captures the essence of the message.



Here's the string resulting in the above screen shot, to give you injection context.



All security implications apply here: phishing, PCI, damage to brand and reputation, risk to consumers, etc.
That said, it appear that just a few of the kabillions of bailout dollars bestowed upon Citibank might have gone to a web application protection mechanism applied globally to all Citibank sites.
I'd love to say it came on the heels of this vulnerability being disclosed to them, but alas, I'll likely never know.
As I poked about to see what sort of results the old vulnerabilities generated, as well as poking for any other lapses, I universally received this URL.
It shows a 404, but the implications are something WAF-like is nailing common Javascript strings, given that the URL declares /domain/spoof/intercept.
Makes me feel good to see my tax dollars hard at work. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

Friday, April 03, 2009

A follow-up on SaaS & cloud risk

When I recently discussed SaaS & cloud risk, with particular regard to Baynote, it received some attention, both positive and negative.
Having made Dr. Deviant's list for “stating the bleedin’ obvious” ;-), I must say it's hard to disparage the man's view.
Yet, there is a key point that eludes those detractors of my view that SaaS and the cloud present enhanced risk.
Yes, lots of software, operating systems, browsers, wikis, yada yada yada, ad infinitum, exhibit flaws and put users at risk of compromise. But most often, those resources at risk are also under those user's near or immediate control.
Not so of SaaS or cloud offerings.
When you commit your enterprise to the cloud, you yield control, plain and simple.
To which I can only offer, ask the right questions before doing so.
A recent comment on the heels of El Reg's coverage of the Baynote flaw discussion was written as if from my own keyboard (I assure you it wasn't), and I will use it to close, with my compliments to Raife Edwards:
The difference is that... IF... you own, and run, your own servers, or systems/software... AND, a "common vulnerability" exists, and is exploited... You MAY be vulnerable... you MAY have a security issue... you MAY be targeted... you MAY not have adequately protected your system... you MAY be hit by the problem... you MAY have issues, and losses... possibly.
If, however, you are dependent upon any, EXTERNAL, single point-of-attack/vulnerable-point... then you WILL be hit... you WILL be affected... you WILL have losses... and you WILL be totally-dependent upon EXTERNAL-interests in "fixing", and recovering... based upon THEIR competence, and on THEIR time-table... and, to suit THEIR perception of THEIR interests.
In other words, ALL YOUR EGGS in [SOMEONE ELSES] basket.


Precisely.

del.icio.us | digg | Submit to Slashdot

Wednesday, April 01, 2009

Tamper Data: CSRF examined

I've been picking on web applications with CSRF vulnerabilities a great deal lately, and in so doing thought it timely to discuss one of my favorite tools for the task in a toolsmith article.
Tamper Data: CSRF Examined explores Adam Judson’s Tamper Data, the Firefox add-on, as one of the best tools for sniffing out CSRF holes. It allows you to quickly note the absence of token/formkey use, and uncover variables useful in crafting scripts to present vendors and vulnerability clearinghouses with proofs of concept.
Jeremiah Grossman referred to CSRF as the sleeping giant years ago but apparently no one's listened. ;-)
I can tell you, my research indicates that it remains a prevailing flaw. It's also difficult vulnerability to scan for, so most PCI ASVs miss it completely. If you have doubts about CSRF holes and PCI compliance (see PCI DSS 1.2 6.5.5) you need only read Mike Bailey's perspective over at skeptikal.org where he discussed the issue in cPanel almost a year ago and has since exposed the issue in Zen Cart, after a discussion we had regarding CSRF issues in osCommerce.
The following are all CSRF (and other vulnerabilities) discovered with Tamper Data, and disclosed via advisories employing responsible disclosure practices.
HIO-2008-1005 CompactCMS 1.1 XSS & CSRF
HIO-2008-1022-1 RateMe 1.3.3 XSS & CSRF
HIO-2009-0128 osCommerce CSRF
HIO-2009-0305 e107 Multiple e107_admin CSRF & XSS Vulnerabilities
HIO-2009-0308 dotProject 2.1.2 CSRF & multiple XSS
I also have many more similar vulnerabilities waiting in the pipeline for vendor repairs.

If you don't use it already, may I suggest installing Tamper Data at your earliest convenience?

del.icio.us | digg | Submit to Slashdot

Tuesday, March 31, 2009

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!

Monday, March 30, 2009

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

Tuesday, March 24, 2009

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

Moving blog to HolisticInfoSec.io

toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...