Online Finance Flaws: An Awareness Campaign

Here begins a series regarding web application security inadequacies in online financial service offerings. The services to be discussed will include banks, credit unions, credit card companies, and others. As the economy struggles profoundly, and much of the blame points at the financial sector, I believe it important to point out the false sense of security so many brand-name financial services wrongly instill in their customers.
Often this sense of security is coupled with a typical "security badge" provider, helping drive conversions rather than security, as we will also legitimize how often the badge providers miss the mark on their promises.
Accountability in loan making decisions and practices might have prevented the sub-prime market collapse and the subsequent credit crunch that has hogtied our economy.
Accountability with regard to web application security while providing online financial services is now all the more important as cybercrime will continue to increase at a pace proportionate to economic woes.
Each post relevant to this campaign will include Online Finance Flaw in its title for tracking purposes.
Look forward to surprising flaws in financial services brands you'll recognize.
Perhaps, the more attention we draw to services that should place security above all else, the more likely it is they'll commit to improving their security posture.
Feel free to comment or contribute; we'll begin in a day or two.

Mamma.com: Insider trading and XSS

Mamma.com's got issues other than Mark Cuban's insider trading allegations. As a point of reference for this conversation, Mamma.com is ranked 4064 on Alexa as of today.
I won't profess to following Mr. Cuban's public life and the occasional antics. Obviously, he's a colorful and popular figure; certainly in Dallas, if not nationally.
What follows is not a judgment of Mr. Cuban or his pending legal challenges. I'm sure the process will play itself out accordingly.
A quick summary and some reference material:
The SEC has filed insider trading charges against Mr. Cuban. "According to the SEC, Cuban dumped 600,000 shares, or all of his 6.3% stake, in the search engine Mamma.com (The Mother of All Search Engines), in June 2004 after learning about private financing that the company was proposing. By selling, he avoided losing $750,000, the SEC alleges."
The whole issue for Mr. Cuban was PIPE financing because it's "dilutive to existing shareholders’ stakes."
That's the long and the short of the current issue, and again, not my real interest here, with the exception of the bet I made with myself regarding the probable web application security posture of mamma.com.
All this talk about a popular site immediately sets off the little bell in my head (I hear it a lot).
"What's wrong with the site?" is always the first question I ask myself.

I was not disappointed.

Mamma.com exhibits the following issues:
1) XSS vulnerability in the utfout variable.



2) XSS vulnerability in the qtype variable.



3) XSS vulnerability in their Mammajobs site at the pid variable. This one's weirder still; if you drop an IFRAME in, it simply redirects to any URL you include in the IFRAME string.



4) The prospect of CSRF (rather pointless here given that its just a search engine, but but still defies best practices) appears likely given that mamma.com blindly accepts updates via GET and POST with no sign of a formkey (canary) in sight.

I figured it best to stop there, and have submitted all these to Copernic (the Momma parent company).
I am however truly disappointed that an enterprise as ambitious and motivated as Momma/Copernic seems to have thrown the baby out with the bath water when it comes to web application security.
With regard to Mark Cuban dumping his shares: maybe he was afraid of getting pwned. ;-) All kidding aside, it's a shame that the whimsical and pessimistic thoughts regarding web site security that bounce around in my head inevitably bear themselves out.

del.icio.us | digg | Submit to Slashdot

XSS Comedy III: Tax Cheats with Small Equipment

As part of an ongoing series, if I may I, the third in a series on the absurd, inane, and perhaps even funny. Lest you forget: the first and second in the series.
I don't know about you, but I enjoy occasionally watching offerings like the History Channel, AMC, or the Military Channel. I'm a 40ish, white male and as such I likely fit the general demographic as perceived by the marketing geniuses who buy the late evening advertising blocks on these channels.
That does NOT mean that I cheat on my taxes and thus need the services of a plethora of scam artists selling tax relief. Nor does it mean that I have any interest in "enhancement" opportunities like Enzyte or ExtenZe.
I just love people who choose to skip out on a primary obligation of citizenship that most of us choose to meet, and expect to magically turn $100,000 in tax debt into $999. Then there are the "businesses" who exploit these folks and willingly convince them of their "success" via the power of advertising, at which point my patience just snaps, as it did last night.
Thus, part one of this rant is a mighty bugger off to all the "tax relief" companies. To their patrons, may I suggest simply paying taxes like the rest of us?
Here's an XSS vulnerability in the Freedom Financial Network, "as seen on TV", designed to express precisely how I feel:

http://www.freedomfinancialnetwork.com/tax_debt.php?pid=ffn+go&key=%22%3E%3Cmarquee%3E%3Ch1%3ENOTHING_IS_FREE!%3C%2Fh1%3E%3C%2Fmarquee%3E

If and when they fix this issue, here's the video for posterity.

Part two of this rant will get you more bang for your buck, and I'm not talking enhancement.
Thanks to my utter disdain for the endlessly annoying advertising I went to the ExtenZe site to see what might be broken which immediately led me to discover an entire platform vulnerability in the ColdFusion application built by Internet Direct Response (IDR), the wankers who proudly bring you Maxoderm, Vivaxa, Vazomyne, Smoke Away, and Hydroxydrene; all such reputable products, and all repetitively wearing me out via DirectTV. At the ExtenZe site I spotted a variable that seemed worthy of building a Googledork from, and I soon discovered that it was a consistent variable in most of the sites pimping this crap; specifically, microppcsite. You can follow all the search results back to our friends at IDR.
A little experimentation and I quickly discovered that the similar microppcterm variable was vulnerable to entertaining XSS exploitation so I started with:

http://www.extenzeforlife.com/?microppcsite=googleµppcterm=%22%3E%3Cmarquee%3E%3Ch1%3EToo_short,_Morningwood?%3C%2Fh1%3E%3C%2Fmarquee%3E&gclid=CJ3T2NXH8JYCFQQCagod7xyBrA

Pick your poison, it works on most IDR gems.

http://www.enzyte-male-enhancement.com/google/?microppcsite=googleµppcterm=%22%3E%3Cmarquee%3E%3Ch1%3EBob_just_wants_your_money.%3C%2Fh1%3E%3C%2Fmarquee%3E

Again, a video, should IDR choose to fix their app.

And now, the grand prize for pathetic: The ExtenZe site is McAfee Secure.

I couldn't make this stuff up if I tried.
You thought www stood for world wide web. Try wee willy wankers. *sigh*

del.icio.us | digg | Submit to Slashdot

Vulnerabilities quickly mitigated by security-conscious vendors

As you are likely aware, I spend a fair bit of time heckling those I believe deserving due to their shortcomings with regard to protecting online consumers.
I do, however, continue to seek opportunities to shed positive light as well, and recent responses from a number of vendor/developers warrant an opportunity to do just that.
In the last 30 days, I've discovered vulnerabilities in products from four different vendors, and advised them all immediately upon discovery. Usually, that's where the story ends, as sadly, my repeated requests for action are often ignored. The last 30 days have proven to be entirely different, with swift responses and action from ALL vendors to whom I reported vulnerabilities. In all cases I received replies within 24 hours or less, and patches/fixes/updates were typically released within 24-72 additional hours. These are exemplary responses, and reflect why I choose to conduct vulnerability research. I believe we, as web application professionals (both developers and security practitioners), are beholden to the greater public and must endeavor to protect the online safety of the Internet consumer.
To each of these vendors/developers I'd like to issue a hearty "well done" and issue public kudos for their diligence and security consciousness, on behalf of consumers and website operators.
To Lukas of PlanetLuc, Jasper and Eric of Infrae/Silva, Alexander of CompactCMS, and Peter from ActiveCampaign may I say that your efforts are greatly appreciated. Where too few choose to do the right thing, your responses leave us with the perception of caring and integrity.
Thank you.

del.icio.us | digg | Submit to Slashdot

Ticketmaster/Paciolan XSS: Thanks, but I'll buy at the stadium

Update: Just checked, and although I was never contacted by anyone from Ticketmaster/Paciolan, this vulnerability appears mitigated as of 11/6/08.

As if the extra Ticketmaster fees weren't enough, how about the prospect of your PII being stolen because they forgot to perform proper due diligence via a web application security assessment on recent acquisition Paciolan?
Consider the following Google search results. The server referenced therein hosts an "integrated ticketing system that enables venues to manage their own tickets."
Rutgers, University of Washington, Army, Air Force, Navy, Baylor, Notre Dame, even the American Museum of Natural History; all sell their tickets online through the Ticketmaster/Paciolan offering.
And they're all vulnerable as a result.
I've made multiple attempts to notify these folks, and have been ignored, so time for a scolding as my Gran used to say.
It's been awhile since I've brought video to bear and while I've nothing against the Arkansas Razorbacks, I had to utilize someone's instance of this service to prove my point, so away we go.
By the way, I just love the Verisign Secured badge (it's not going to help here).
Here's the full URL:
http://ev12.evenue.net/cgi-bin/ncommerce3/SEGetEventList?groupCode=FB&linkID=arkansas&shopperContext=&caller=&appCode=&RSRC=TM&RDAT=FB08SPLASH
The shopperContext (how ironic) variable is the parameter with issues. Mind you, this holds true for any university or venue using this service.

For your viewing pleasure, the video.

Yes, they take your credit card information, and conduct the ticket purchase transaction. If you've read my blog, you know by now the risks inherent to cross-site scripting vulnerabilities under circumstances like these. Verisign SSL certs are nice, but won't help the consumer if the web app is vulnerable.

Thanks, but I'll buy my tickets at the stadium. ;-)

Should Ticketmaster/Paciolan fix this issue, I'll update the post accordingly.

del.icio.us | digg | Submit to Slashdot

Open Redirects and Common Weakness Enumeration

Hopefully, you're more than familiar with CVE (Common Vulnerabilities and Exposures), but perhaps you're less familiar with CWE (Common Weaknesses Enumeration). Both are significant efforts, international in scope, and the excellent products of The MITRE Corporation, sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security.
Approximately six months ago I was discussing open redirect vulnerabilities with Steven Christey of MITRE, who mentioned that that CWE entry for open redirects was sparse and dated, with little reference material. In particular, he pointed out the lack of defining papers. I accepted this information as a challenge and produced an article that was published in (IN)SECURE Issue 17. Soon after Issue 17 went live, I also took note of an excellent academic paper specific to the topic of open redirect vulnerabilities; Shue, Kalafut and Gupta's Exploitable Redirects on the Web: Identification, Prevalence, and Defense. Complete with these two papers as references, as well as two current CVE identifiers for popular web applications suffering from open redirect vulnerabilities (discovered by yours truly), CVE-2008-2052 & 2951, CWE-601: URL Redirection to Untrusted Site (aka 'Open Redirect') is now current and complete.
As open redirects are undoubtedly one of my biggest pet peeves, I am pleased to no end. Hopefully CWE-601 will help drive more application vendors and site operators to put an end to this easily mitigated vulnerability.

CWE:
"International in scope and free for public use, CWE™ provides a unified, measurable set of software weaknesses that is enabling more effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems as well as better understanding and management of software weaknesses related to architecture and design."

del.icio.us | digg | Submit to Slashdot

Expanding Response: Deeper Analysis for Incident Handlers

To achieve my GCIH Gold, I recently completed a paper called Expanding Response: Deeper Analysis for Incident Handlers, now available in the SANS Reading Room. The premise was to further expand on the topics discussed in my Malware analysis tools post. This paper includes tools discussed at various times in my toolsmith column in the ISSA Journal, and includes details on Argus, HeX, NSM-Console, and NetworkMiner.

Abstract:
"The perspective embraced for this discussion is that of an analyst who is working a process to determine the exact nature of malicious software on his network. He is in receipt of the above mentioned .exe and .pcap files and seeks to further his understanding with the use of less typical tools. She begins the process with the network capture, and then takes a closer look at the binary to see what can be learned and what the impacts of an outbreak on her network might be."

del.icio.us | digg | Submit to Slashdot

The McAfee Secure Standard: Sort Of

I need your help.
I am in receipt of the McAfee Secure Standard, drafted to transparently describe the McAfee Secure service, as promised during my meeting with Joe Pierini and Kirk Lawrence of McAfee some weeks ago. I admit my attitude has soured since last I discussed it here, as the Standard is not yet ready for public release (I last said 2-3 weeks and that was five weeks ago), but bear with me. I can't publish exact quotes from the Standard, as I've promised not to, but let me give you insight on the upside, then the downside.

The upside includes all the transparency we'd hoped for. You'll read the McAfee Secure Standard and know exactly where they stand with regard as to what can be expected of the McAfee Secure Service. My discussions with Joe Pierini have been productive and respectful; he means well, and I believe he will try to drive the greater McAfee leadership to officially incorporate suggestions made in this blog.
I have even had the pleasure of reading a Researcher/Finder Policy that very succinctly describes what researchers can expect when they submit vulnerabilities found in McAfee Secure sites. That's all good stuff and to be applauded.

Now for the downside.

The McAfee Secure Standard will draw a clear distinction between "enterprise" customers and all the Ma & Pa websites who have so loved McAfee Secure / ScanAlert Hacker Safe for conversions.
The most glaring and painful distinction for me is this. While enterprise customers will have a clearly defined time line in which to remediate script injection vulnerabilities like XSS and open redirects, before losing their McAfee Secure badge, the Ma & Pa sites will have absolutely no requirement to fix their XSS issues. XSS vulnerabilities and the McAfee Secure badge will remain consistent on all those sites that care more about "convincing" their customers that they're secure with a McAfee Secure badge; a badge that, by its own pending standard, will contradict what we know to be truly secure.

My views are clear. I have made every effort to convince McAfee that this stance is counter intuitive to good web application security standards. I believe that, in their own way, they are listening. So here's your chance.
1) Is transparency enough?
2) Is holding only enterprise customers accountable acceptable?
3) Should ALL McAfee Secure customers be expected to fix their vulnerabilities, even if on different timelines?
4) What else do you want McAfee to hear, in the form of constructive feedback only?
I will publish all well written, thoughtful comments here. Let's keep it positive and see if we can help convince McAfee that script injection vulnerabilities and McAfee Secure can't exist in the same physical space. Like matter and anti-matter. ;-)
The floor is yours...

del.icio.us | digg | Submit to Slashdot

FileAdvisor: software file search engine

Troy Larson sent me a heads up on Bit9's FileAdvisor, a service they describe as "a comprehensive catalog of executables, drivers, and patches found in commercial Windows applications and software packages. Malware and other unauthorized software that affects Windows computers is also indexed."
I immediately checked the FileAdvisor db for malware results as well non-Windows binaries and was pleasantly surprised with immediate and comprehensive results. You do have to register, but I was further impressed with the fact that they offered the option for a short or full registration.
This appears to be worthy of a bookmark in your incident handler/malware researcher/forensic investigator toolkit.

del.icio.us | digg

Hype Alert: Internet Shopping Carts Are Secure

My blog reader fed me a nugget today that set off my hype monitor, specifically a post entitled Internet Shopping Carts are Secure.
OMG...really?
To be fair, I realize the author is speaking from the eCommerce perspective, rather than that of an information security practitioner, but here's where the trouble begins:
"Shopping cart service providers have developed secure ecommerce shopping cart solutions for any business owner looking to enhance their current online store, or create a new one. Some ecommerce shopping cart solution providers are even receiving PABP (Payment Application Best Practice) certification which supports PCI compliance requirements for all businesses accepting credit card payments online."
This may be true in part, but it is by no means an all-inclusive claim. Shopping carts continue to be sieve-like, even when apparently reviewed per PCI standards.
Allow me to elaborate.
We'll kick off our hype eliminating effort with a simple Google dork: inurl:"cart.cfm" (picking on ColdFusion again, but man, they make it easy)
GM Parts Direct: Your Shopping Cart jumped right out at me for a number of reasons.
First, I sensed XSS vulns lurking like a Geiger counter senses radiation. Sound effect for edification. :-)
Second, the page contained one of the growing number of aforementioned conversion-driving website security seals.



Tick, tick, click...the Gieger counter is getting louder.
Trustwave claims that the site operator "is enrolled in Trustwave's Trusted Commerce™ program to validate compliance with the Payment Card Industry Data Security Standard (PCI DSS) mandated by all the major credit card associations including: American Express, Diners Club, Discover, JCB, MasterCard Worldwide, Visa, Inc. and Visa Europe."
Methinks that Trustwave's Trusted Commerce program is missing a few fundamental security checks. Remember, XSS in PCI regulated sites, according to the PCI DSS, indicates that a site is not compliant (see section 6.5.4) if vulnerable to XSS.
Uh-oh.

All it takes is a fake login page, as opposed to our friends at XSSED.com, and...well, you get the point.
Simply, this is one of an endless number of shopping cart not secure, and not PCI compliant. For shame. You need only browse the Holisticinfosec.org Advisories page to find multiple ecommerce platforms and shopping carts that are missing the mark. Trust me, these are a fraction of the problem.
ecommerce<>security
ecommerce<>SDL
ecommerce<>PCI
website security seal<>security
russ=frustrated
Sigh.

del.icio.us | digg

XSF & XSS: Double your pleasure, double your fun

If you've read this blog, or those of my peers, you're likely quite familiar with cross-site scripting, and the problems associated with open redirect vulnerabilities. A vulnerability you may be less familiar with is cross-site framing, which largely couples the best of both above-mentioned vulnerabilities.
What then, if there's a cross-site framing vulnerability coupled with cross-site scripting in the content offered by the frame? All sorts of problems come to mind: phishing, malware, credential theft; all arguably twice removed from the attacker's source, tucked away in the context of two victim sites.
First, I'll discuss the original XSS issue that led to this finding.
Recently, I was investigating a flawed parameter in Openhire, a career posting vendor used by major companies like Crate&Barrel, Eileen Fisher, Enterprise, Benjamin Moore, Scottrade, and Getty Images.
Most of these sites simply link to the Openhire offering that hosts job postings on their behalf which, in turn, has been crafted to look like the referring site.
As an example, here's Scottrade's employment page hosted by Openhire.

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?version=1&company_id=15624

Standard stuff, looks nicely like the Scottrade site, so everything's cool, right?
Wrong? What if someone hosting a service on your behalf suffers a security gap?
You're only as strong as your weakest link!
Here's the posting for an Application Security Engineer (funny, eh?) at Scottrade as hosted on their behalf by Openhire:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=976367&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters%3B%3B%3BInformation%20Technology%3B%3B%3BSecurity&startflag=3&CFID=66851845&CFTOKEN=29a95-d12594d4-47d9-49e8-9067-1091bdf68e80

Now here the same job posting spewing massive cookie data:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3

Screen shot offered below, as the code above will likely be repaired very soon by Openhire. I notified them this past Thursday.



It's bad enough when there's an application security hole in code someone else is hosting on your behalf, but what if your method of displaying said code is also at risk? Enter the Getty Images Jobs page.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=careeropps&startflag=0&company_id=15531&version=2&CFID=12265212&CFTOKEN=60213778

Watch what happens when you pull the Openhire code. Can you say self-replicating frame loop from hell (in Firefox)? Trust me your browser will crash if you leave this running too long. This will likely be fixed soon, so if the URL doesn't work, the screen shot exemplifies the issue.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html



What if, instead of Openhire's Getty Images page, or nothing at all (which obviously creates its own issue), we drop in an arbitrary URL?
Yep, you guessed it.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://www.xssed.com/news/26/Cross-site_framed/



Now, bringing it all home for double the pleasure, double the fun, what if we coupled the original Openhire cross-site scripting vuln with Getty Images' cross-site frame vuln?

It hurts twice as much, in my book.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3



The lessons learned:
1) Ensure your partners are writing secure code on you behalf.
2) Ensure that the code you utilize to incorporate said partner's code is also well written. ;-)

Double the headache, double the dumb.

del.icio.us | digg

EstDomains & Intercage: A Perfect Couple in Crime

If you track malware issues as readily as I do, you're likely aware of the failings of clownpacks like EstDomains and their hosting buddies Atrivo/Intercage. You need only follow Sunbelt's take on the topic, or search Emergingthreats to come up to speed.
Yesterday, EstDomains posted the most inept, ridiculous response ever issued to the endless and worthy criticism, largely leveled by Brian Krebs at the Washington Post.
Not only can't these morons from EstDomains write, they're either so deeply clueless or flagrantly malicious (likely both), it's beyond laughable. This section sums it up best:
"The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality. But the outstanding performance of hosting services is not the sole reason why EstDomains, Inc appreciates this partnership so greatly. Intercage, Inc generously provides EstDomains, Inc specialists with reports regarding discovered malware vehicles. As the main database for additional domain name management services is located in Intercage Data Center, EstDomains, Inc has the perfect opportunity to get notifications of the slightest mark of malware presence in the shortest time and take measures in advance."
What? Really?
Again, aside from the absolute butchery of the language, did they just say "The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality."? SIGH...yes, they did.

Allow me to exemplify just how ridiculous a claim that is.
Following is content from a packet capture I took during a recent Storm worm analysis.

Using the ip2asn module included in NSM-console availabe in HeX, we find:
27595 | 216.255.189.211 | INTERCAGE - InterCage, Inc.

Using Etherape, also included in HeX, we see:



Using Eric Hjelmvik's NetworkMiner, we see:



See the recurring theme? Intercage, EstDomain's "reliable ally in its battle against malware".
Nice work, guys...keep it up.

I'm submitting this to The Daily WTF as we speak.

del.icio.us | digg

XSS fortune cookie

Forgive me in advance for an extremely bad joke, if you can even call it that, but I just can't help it.
Here's how to get an XSS fortune cookie:

1) Ask the mighty Google oracle who might be able to tell you your fortune.
http://www.google.com/search?hl=en&q=tell+my+fortune&btnG=Search&lr=lang_en

2) Select one of the sponsored links; in this case I chose SpritualExperts.com.

3) Pick a variable. I settled for banid.

4) Ask it if it has a cookie for you.
http://www.spiritualexperts.com/psychic_reading/psychic_reading.asp?banid=%22%3E%3CSCRIPT%3Ealert%28document%2Ecookie%29%3C%2FSCRIPT%3E

Voila...an XSS fortune cookie. Sorry. Really, I am.

The webmaster has been advised...play nice.

Screenshot for after they fix the issue.



del.icio.us | digg

McIrony: An unexpected response from McAfee

Irony: incongruity between what might be expected and what actually occurs.

Right before Black Hat, I put together what I believed was a pretty strong arguement against McAfee Secure - Hacker Safe, at a level heretofore unexplored. I believe it was more damaging than anything I've said to date, and as such, presented potential risk for me. So I ran it by some friends before publishing it. Then a most extraordinary thing happened. I had a long chat with Nate McFeters, who described an awakening he'd recently experienced. He shared with me the belief that a better approach to potentially negative security research might be to try to create a positive outcome, and worry less about press cycles or exposure, the 15 minutes of fame if you will. He pointed to people like Mark Dowd as an example of people who conduct crushingly good research, and steer clear of the petty, ego driven bulls**t.
There I sat, repose like the thinking man, frozen for minutes. "Nate", I said, "I think you're right."
What do I aspire to as an information security professional; more readership or street cred than the next guy, or the respect of my peers for contributing to the greater good? Attention, press cycles, 15 minutes...it all has its allure, trust me on this.
But at the end of the day, I really do want to contribute to the greater good.
So I did something different. I sent my findings to McAfee and offered them an opportunity to respond, rather than publish first, ask questions later.
Here's the real kicker.
They responded.
I had a three hour lunch this past Thursday with two gentlemen from McAfee, who flew up from the Bay Area to Seattle to have a face to face with me. This, all by itself, speaks volumes to me. In addition to meeting with Kirk Lawrence, the new Director of Product Management for McAfee Secure, there I sat with, of all people, Joe Pierini, the very guy who has suffered more than his share of abuse, up to and including the Pwnie. As I have been a direct contributor and participant in heckling Joe, you can imagine our meeting could have been uncomfortable. It was not.
I have had expectations of McAfee and Scan Alert that to date have not been met, or my (your) perception has been that they have not been met.
This meeting was designed as an opportunity to voice some of these expectations, and see if McAfee, in turn, believed there was any merit to them.
Surprisingly, at least as spoken, we weren't all that far apart.
While, as a naive idealist, I believe that security should come before conversions, I am also grounded enough of a realize that the most attainable goal can be a marriage of both. This premise frames my expectations of McAfee.
Can they not be more of a "thought leader" for all the Ma & Pa websites who rely on McAfee Secure, first for a higher conversion rate, then security?
Can they not hold merchants to a higher standard, without alienating them and losing business?
Can they not embrace the security research community in a fashion that McAfee, the security community, the merchants, and consumers can all benefit from?
Can they not be more transparent in their approach, providing more details and feedback about their methods, their findings, and their vision?
I know McAfee Secure - Hacker Safe scans can find vulnerabilities.
I know they report the vulnerabilities to merchants.
What happens thereafter is where things begin to break down.
Can the scan engine be improved to find more vulns? Sure. That's really not that big a deal; technology can always be improved.
But, regarding holding merchants to a higher standard; therein is the whole point of this debate.
Anyone can throw a badge on a site.
But what happens when the site proves vulnerable is the key. I'll be candid here: I don't give a damn about the merchant at that point; it's the consumer who is at risk and needs something better from McAfee and their peers.
So, here begins a different approach. I know that making changes at a company the size of McAfee can be likened to the three miles it takes to turn around an aircraft carrier. I'm willing to work with them, and allow for a positive outcome.
I have been told that, in two or three weeks, we can expect a published standard, that clearly defines exactly what the McAfee Secure product offering adheres to, inclusive of their expectations for merchant remediation timelines, potential badge downgrades for unresolved vulnerabilities, and hopefully even a more clear stance on XSS.
I have been told that I will have the opportunity to discuss this standard, and invite feedback. Any standard is better than no standard.
I have also been told that this is just the beginning of changes that will lead to more of what I have hoped for in my expectations, over the next 6 months or so.
I am hopeful that we can take McAfee at their word, and even if slowly, see a positive outcome.

del.icio.us | digg

ColdFusion: Hack Me or Help Me

For your consideration, the endless battle between security and convenience.
Front and center: ColdFusion.
I've been picking on ColdFusion-built apps again a bit lately, and one of my observations has been that consistently, if mismanaged, the verbose error reporting features in ColdFusion can be really problematic.

HIO-2008-0713 JOBBEX JobSite SQLi & XSS
HIO-2008-0729 BookMine SQLi & XSS

Recently, I stumbled on an example of way too much information disclosure in a few sites running a ColdFusion-built CMS. The error reporting was so verbose it included the base path, data source name, database username, and yes, the database password.
I've cleaned it up for the protection of all involved, but here's a screen shot of only 1/4 of the details this site coughed up when I tweaked the input to a calendar date variable.



When I reached out to the developers of this app (always and immediately responsive), they assured me that this was not due to a flaw in the app, but that the "information should be protected, and is by default for our installations" and that the client disabled the security check and turned debugging on. I accept this explanation entirely, but it leads to the classic debate around the dangers of mismanaged debugging features, be they developer added or ColdFusion feature driven. Stupid user tricks are always an issue, but how much rope should they be given to hang themselves? Does error reporting really need to include the database username and password?

Allow me to present a few different perspectives.
First, rvdh's take on Attacking ColdFusion. Developers can learn a lot from this post, if only in that it precisely points out attack vectors. Ronald sums up my concerns aptly:
"As we know, error messages are important. Especially error messages generated by database software we want to inject. This, is useful for obtaining information about table structures that can be a real time-saver for attackers. If the right information is available, attackers do not have to guess database tables and fields anymore, nor having to brute force them. I have never seen so much information regarding the site's structure, used database, table names, drivers, server setup and other information useful for attackers that those of ColdFusion. It almost says: Please Hack Me!"
As I can't presume to improve on this stance, I won't. Well said.

Next, a developer's take on the issue from Joshua Cyr, who has declared it Check Your Error Output Day. Joshua highlights two key points:
1) Do NOT enable the robust errors setting in CF Administrator.
2) Don't forget to remove debugging dump code.
Heed this advice, ColdFusion fans!

One destination that all "secure" ColdFusion paths should lead to is the use of cfqueryparam. Ronald spells it out well mid way through his discussion, and so do the following resources:
coldfusionjedi
Coldfusion Muse

Further excellent resources for ColdFusion security issues:
SQL Injection Part II (Make Sure You Are Sitting Down)
12Robots.com

In closing, security and convenience needn't always be at odds, but often allowing for both requires a higher state of awareness for developers and end-users. Let common sense prevail; perhaps it'll give me less to do in the way of research. ;-)

del.icio.us | digg

NIST revises SP800-60 Volume 1: Go forth and classify

According to GCN, NIST has released a revision to SP800-60 Vol 1 and Volume 2. The two-volume Special Publication 800-60 Revision 1, “Guide for Mapping Types of Information and Information Systems to Security Categories,” is a revision of guidelines published in 2004.
Asset and data classification is the keystone to building proper protective schemes. Simply, if you don't know what you have, you can't apply the appropriate levels of value and importance.
SP 800-60's intro reads:
"The identification of information processed on an information system is essential to the proper selection of security controls and ensuring the confidentiality, integrity, and availability of the system and its information. The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-60 has been developed to assist Federal government agencies to categorize information and information systems."
Give this document a read; while it is geared to a federal agency audience, it is entirely useful for baselining your own classification process.

Cross-site scripting CAN be used to hack a server

UPDATE: They won the Pwnie for this at Black Hat! More surprising is the fact that allegedly someone from McAfee showed up to accept. At least they have a sense of humor. More details soon.

Likely you remember when Joseph Pierini at McAfee Secure / Hacker Safe said XSS wasn't important because "cross-site scripting can't be used to hack a server. You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly."
That gem has made McAfee Pwnie worthy (winners announced tomorrow!); may the Lamest Vendor win.
That said, anyone with a clue knows that XSS attacks are ideal for credential theft, and if you can steal credentials, you can hack a server.
Looking for a textbook example? Check out mckt's new blog, skeptikal.org.
Here's a highlight:
"Every cPanel user's account contains a file titled .contactemail in its home directory. This is used to tell the server and administrators who to email when things go south, and can be changed by the user through the cPanel interface, the file manager tool, FTP, or through local scripts. It's only a text file, after all. Assuming we set our email address to:
"onmouseover="alert(1337)
When the friendly system administrator tries to reset our email address (because we forgot our password, obviously), he will receive an alert box in his browser.
But an alert box doesn't really demonstrate anything. Fortunately the WHM (Web Hosting Manager) interface has enough functionality that we can perform just about any system-level task we want. This one will reset the root password to 'owned':
"onmouseover="f=document.forms[0];f.action='/scripts/passwd';f.user.value='root';
f.removeChild(f.domain);d=document.createElement('input');f.appendChild(d);
d.name='password';d.value='owned';d=document.createElement('input');f.appendChild(d);
d.name='password2';d.value='owned';f.submit()
Of course, the only limit is your imagination- WHM can set up cron jobs, add and delete users, send full backups to a server of your choice, and reformat hard drives."

Hmm...I'd say that would be a server hack. ;-)
Welcome, Mike...keep up the good work.

del.icio.us | digg

The Bitrix open redirect vulnerability: a lesson in the absurd

I try to limit my heckling to McYouKnowWho, but I just stumbled across an issue I couldn't leave alone.
If you've been keeping up on recent articles I've published, you know open redirect vulnerabilities really bother me; thus Open redirect vulnerabilities: definition and prevention in (IN)SECURE Issue 17.
Sidebar: I recently spotted a great academic paper on the same issue by Shue, Kalafut, and Gupta at Indian University. Definitive, to say the least.
Back to the issue at hand. It should have occurred to me to check for this earlier; write it off to being busy. Allow me to spell it out simply.

1) On May 2nd, 2008, I published a open redirect vulnerability in Bitrix Site Manager 6.5, specifically CVE-2008-2052.

2) The vulnerability is a simple one to reproduce, easily exploited by phishers and malware propagators. The issue is still unresolved by the vendor, so here's an example, still available, from their site:
http://www.bitrixsoft.com/bitrix/redirect.php?event1=demo_out&event2=
sm_demo&event3=pdemo&goto=http://www.xssed.com/news/29/
The_dangers_of_Redirect_vulnerabilities/
Obviously, the fact that I can send you to XSSed.com's fine explanation of the issue, in the context of the vendor's site, is a no-no in Web App Sec 101. In May, the vendor responded, saying they'd fix it, but I've not received the promised communication that they have. Their own site certainly hasn't been mitigated, so we'll see.

3) One of the sites I found exhibiting this vulnerability while researching the issue via Googledork is http://en.securitylab.ru.

4) The same day, en.securitylab.ru posts their version of the CVE vulnerability advisory for the Bitrix vulnerability.

5) As a reference, en.securitylab.ru links to my original advisory USING THE EXACT SAME VULNERABLE REDIRECT SCRIPT!
http://en.securitylab.ru/bitrix/redirect.php?event3=352513&
goto=http://holisticinfosec.org/content/view/62/45/

To this day, neither the vendor's site, nor Security Lab's site have been mitigated.
A malicious attacker could send a "security advisory" in a phishing email, supposedly from Security Lab, and redirect the victim to another web site, likely also somewhere in Russia, and laden with malware.
This could be a candidate for Pwnie Award 2009. ;-)

Common, people...fix it!

del.icio.us | digg

McAfee's Hacker Safe nominated for a Pwnie

Updated 7/22/08: The Pwnies have added Cresta Pillsbury's gem: "We go in like a super hacker." Bless McAfee | Scan Alert for lameness like this, it'd be hard to make this stuff up.
Mondays don't usually include such glorious highlights but I'll gladly pass on this exception. The Pwnie Awards 2008 nominations are out, and under Lamest Vendor Response we find McAfee's Hacker Safe, specifically Joesph Pierini's response to the findings XSSed.com and I gave to Thomas Claburn for publication in Information Week this past January.
Joseph Pierini, director of enterprise services for the "Hacker Safe" program, stepped in it when he said that XSS vulnerabilities can't be used to hack a server:
Cross-site scripting can't be used to hack a server. You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly.
As you can imagine, this one gets my vote.
Winners will be announced at the BlackHat USA reception at Caesar's Palace, Las Vegas on Wednesday, August 6th, 2008.
Should you wish further reading on the McAfee Secure / Hacker Safe fiasco, you need only utilize this query or refer to all of Nate's coverage on Zero Day.
I must admit, I'm curious who McAfee will have at Black Hat to receive this prestigious award should they win. I'm torn between suggesting Brett Oliphant or Pierini himself. ;-)
Cheers.

del.icio.us | digg

OSF DATA LOSS db a valuable resource

As a longtime reader of the The Data Breach Blog, I was pleased to learn that care and feeding of Attrition.org's Data Loss Database has been assumed by the Open Security Foundation. Check out the DATA LOSS db at your earliest convenience, join, and support.
From the site, the OSF Data Loss database is a "research project aimed at documenting known and reported data loss incidents world-wide. The effort is now a community one, with the move to OSF, and relies on the contributions of users like you to grow and prune the database."
Do your best not to find yourself an entry in this database. ;-)

Visualized Storm fireworks for your 4th of July

As expected, the Storm botnet maestros have queued up some pwnage for your 4th of July.
See the SANS diary for all the details.
Upon receipt of my first fireworks.exe sample this evening, I went through the standard routine and ran it through the analysis mill. Like the ISC said, not much new here, but if you'd like the nitty-gritty, I've put the analysis report here, the peers config list here, and the pcap here.
However, what I was really inspired to do this evening was visualize the pcap with Raffael Marty's AfterGlow. His new book, Applied Security Visualization, is coming out next month, so we can turn old Storm news into a celebration of the 4th and the pending release of Applied Security Visualization. By the way, Raffael's visualization workshop slides from the 20th Annual FIRST Conference in Vancouver, B.C. last week are here, and mine regarding Malcode Analysis for Incident Handlers are here.
So, a little AfterGlow magic,
tcpdump -vttttnnelr /home/rmcree/pcap/fireworks.pcap | ./tcpdump2csv.pl "sip dip ttl" | perl ../graph/afterglow.pl -c /home/rmcree/afterglow/src/perl/graph/color.properties -p 2 | neato -Tgif -o fireworks.gif, and the results look just like the fireworks we hoped they would.
Happy 4th of July everyone!
Except you Storm a$$hat$. ;-)



del.icio.us | digg

XSS Comedy at McAfee Secure's Expense

In celebration of the deadline for PCI Requirement 6.6 compliance as of June 30, 2008, I thought I'd share a little web app sec comedy at McAfee Secure's expense.
As well you should know by know, the existence of XSS vulnerabilities in a site that is required to meet PCI DSS standards means that the site IS NOT PCI COMPLIANT. Very simple, right?
Let's consider the McAfee Secure/Hacker Safe-branded site for Organize-It.
A seemingly handy site, perfect for your HGTV types, likely with healthy credit card limits. Uh-oh, here it comes. Oh yes, Organize-It handles credit cards and is thus beholden to PCI DSS.
Organize-It is also proudly displaying a current McAfee Secure badge, indicating that it's tested daily.
Given the focus of many a recent discussion it shouldn't shock you that Organize-It is vulnerable to XSS.
What's funny is what Organize-It does with regard to "handling" malformed requests.
Where a typical test string for XSS might be " script payload /script (characters removed or Blogger will let me XSS myself), you won't get much use from such a string via either direct form submittal or URL encoding. But when the site barfed up '; // LEAVE THIS VALUE var sli_cId = 90;, while under investigation, my ruh-roh meter went off.
I decided to play with my trusty marquee test and found interesting results. The actual search form field is limited to 41 characters (er?). So my complete string of " marquee message /marquee didn't fit for direct submittal BUT THE MARQUEE RENDERED ANYWAY! Basically, half the test string worked: " marquee h1 This_site_is_NOT_McAfee_S
Forget the marquee tag on the blacklist, did we?
But here's the real icing on the cake. The uber-intuitive search index reinterpreted my message with what I can only imagine are index keywords. Thus "This site is NOT McAfee Secure" scrolls across the Organize-It site as "this sit is not coffee secure".
OMG! My daily quad shot Americano has been pwn3d to the core!
Here's the URL if you don't believe me, or the video if you prefer.
Forget PCI compliance, bring on the Gong Show hook, Chuck!
Cheers.

del.icio.us | digg

PC Universe is shrinking thanks to McAfee Secure's cluelessness

My web app sec friends know exactly how to push my red buttons. "Heh-heh, send it to Russ, he'll go off." Yep. ;-) Thanks, Rafal. Now I'm all spun up. I was sent two moronic gems this morning; one on the merits of McAfee Secure / Hacker Safe and the 109% sales increase it resulted in for PC Universe, the other an interview with the Internet's single biggest dillweed, Cresta Pillsbury. These articles are both a bit dated, but they equally embrace the premise of "trust" logos as a predominant sales driver, rather than any actual motivation to secure a site and protect consumers.
An example:
"If you’re doing conversion marketing and statistical testing on your website and you haven’t explored trust logos yet, then you’re missing out."
I must be the most naive person in the world; this enrages me. When will the idiots who write this crap get a clue? They've bought right into the hype the snake oil salesmen hoped they would and are now complicit in their failures.
Case in point, as seen in the Internet Retailer piece. By the way, I realize that Internet Retailer and basic web application security practices are completely at odds (as proven here), but this one deserves direct abuse.
"PC Universe first tested Hacker Safe on its own site in an A/B split test in which half the visitors saw the Hacker Safe seal and half did not. During that test, 7.3% more orders came from Hacker Safe shoppers than from the control group. PC Universe, which operates on the web at PCUniverse.com, is No. 360 in the Internet Retailer Top 500 Guide."
Really? Let's see what McAfee Secure / Hacker Safe has done to actually provide any measurable security benefit.
How about absolutely nothing.
Here's PC Universe's very current, verified McAfee Hacker Safe cert.
Now, here are a few ridiculous examples of reality from the this universe as opposed to the McAfee-twisted alternate universe. Please note, this is the "accountid" variable, and the fact that the marquee is rendered no less than eight times.
1) Marquee Remediated 6/30/08
2) XSS Deface Remediated 6/30/08
3) Cookie Remediated 6/30/08
Kudos for the quick fix PC Universe.
If you rather just see a video of these vulns, it's here.
PC Universe, rather than lauding your sales increases thanks to some POS logo, try securing your site code. I guarantee you have other issues.
McAfee Secure, once more, you are simply fraudulent to the core.

del.icio.us | digg

Open redirect vulnerabilities article - (IN)SECURE Issue 17

I've written a comprehensive piece on the dangers of open redirects that's been published in Issue 17 of (IN)SECURE Magazine. Page 43 for your reading pleasure.
"An open redirect is a vulnerability that exists when a script allows redirection to an external site by directly calling a specific URL in an unfiltered, unmanaged fashion, which could be used to redirect victims to unintended, malicious web sites."
This issue is a giant pet peeve of mine; the article is intended to increase awareness of the dangers of this vulnerability and promote mitigation.

del.icio.us | digg

Live from the 20th Annual FIRST Conference

I've been at the FIRST conference in Vancouver, BC this week presenting, attending great presentations, and meeting a fantastic group of people.
I'd like to applaud some great presenters I've seen so far, including Par Osterberg Medina (Detecting Intrusions), Anton Chuvakin (Log Analysis), Raffael Marty (Applied Security Visualization), and Steve Mancini (RAPIER).
I've also been advised of some tools for your consideration, to aid in the security analysis / incident response cause, as well as possible topics for toolsmith.
Take a look at these, if you aren't already familiar with them:
BitBlaze - Binary Analysis for COTS Protection and Malicious Code Defense
F-Response - The First Truly Vendor Agnostic Solution for Remote Forensics and eDiscovery
Maltego - Maltego is an open source intelligence and forensics application. It allows for the mining and gathering of information as well as the representation of this information in a meaningful way.
The Volatility Framework - Volatile memory artifact extraction utility framework
Thanks to Richard Bejtlich for pointing out F-Response and Volatility and Steve Mancini for BitBlaze and Maltego.

On another front, in support of Eva Chen's (Trend Micro) recent claim that the anti-virus industry sucks, John Stewart of Cisco, in his keynote this morning, reiterated the premise that the fight against malware is a lost cause. The point he was really driving at is the downfall of blacklisting and that whitelisting is essential given that "the total good is smaller than the total unknown and bad". This, as his fourth postulate of many good postulates this morning, truly supports my own beliefs. I'm more focused on whitelisting in the web application security space, but the premise is the same. If the vast majority of requests to secured elements of your applications are bad, then simply deny all, and allow only that which you trust.

More to come...

del.icio.us | digg

CIAC Tech Bulletin on XSS a valuable reference

The only fault I could possibly find in the recently released CIAC Technical Bulletin, CIACTech08-003: Understanding Cross-Site Scripting (XSS), is that it should have been released a year ago or more. ;-)
But rather than nitpick, I'd like to applaud.
This is a fine effort, with a number of good resources cited.
You'll find content on the types of cross-site scripting, including DOM, non-persistent, persistent, and CSRF. Additionally, you'll note methods of protection and reference links to content on Htmlspecialchars, Htmlentities, and Giorgio Maone's NoScript.
This is a great starting point for enlightening vendors, developers, and IT folk who may not be as up to speed as you might like on the concerns caused by XSS vulnerabilities.
Given the fact that stories continue to surface on the shortcomings of major security vendors, and their utter lack of diligence with regard to XSS, as well as efforts to further enlighten the masses, this is a valiant effort.
Well done, CIAC.

del.icio.us | digg

SaaS Snake Oil Top Ten, with video

As I was happily sniffing about for more annoying vendor fodder a few nights ago, I found a true gem. I was actually investigating ControlScan's practices and came across some poor hapless site owner that had been manipulated into buying both the ControlScan service and McAfee Secure / Hacker Safe by not one, but two snake oil salesmen.
This site was bound to be secure, right? Wrong!
Here's a new video to detail the inadequacies of both these services, at the same time.
But, as my disdain for these con artists grew yet stronger, it occurred to me (with the suggestion of an unnamed accomplice) that we needed a Letterman-like Top Ten list.
In this case SaaS will denote scanning as a service, rather than software or security, as security is the last thing these daft gits offer. These are all real statements, claims or quotes from these so called services.

Top Ten 10 signs the SaaS sales guy in front of you if offering up snake oil.

10. We first scan for open ports.
9. If you're interested in increasing your conversions, I'd suggest you sign up for WebSafe Shield.
8. Al Gore is on our board.
7. We held a hacker contest to break our security, and no one did.
6. We want to be the trusted partner who’s at your side, day by day, year to year,to help your business grow.
5. Increase your conversion rate or double your money back!
4. Our Web-based PCI Compliance 1-2-3 solution includes everything you need.
3. The "Verified Secure" mark appears only when a web site's security meets the highest security scanning standards of the U.S. government.
2. Unfortunately, the automated scanning technology we use doesn’t have this XSS scanning.
1. We go in like a super hacker.

There will be no rest for their souls in the afterlife; the web app security gods have a special in hell for salesmen and companies like this. ;-)

del.icio.us | digg

Blue River's stance on Sava security stands out

It's been awhile since I've had something nice to say, and the golden opportunity to rectify that issue has presented itself in the discovery of some vulnerabilities in Sava CMS from the Blue River Interactive Group.
At 9:29pm May 19th, I sent a note to Blue River pointing out an XSS vulnerability. I received a reply from Malcolm at 9:46pm (yes, 17 minutes later), stating that the issue would be addressed immediately and asking if I had questions or suggestions.
Wow! Really?
The lonely life of security dork/vuln researcher sometimes has its rewards. I offered to take a deeper look at Sava, with their permission, which Malcolm immediately granted. After further inspection, I noted a SQLi issue as well, but the update they'd already released had fixed the issue on other sites where the update had been applied. So, in what really amounts to 48 hours, the Blue River team went after the issues with a vengeance, and addressed them appropriately (and obviously quickly).
It's no secret that I am giant open source proponent, and Sava fits that definition in every way, not just their application but their open communication, pride in their product, and concern for their users.
This is what we in the security community hope for...those rare occasions to feel good about well intended efforts being met by further well intended efforts, all to the benefit of the user and the consumer.
Well done, Blue River...go Sava!

Any Sava users who may be reading this, ensure that you are running Sava CMS 5.0.122 or later.
Advisory here: HIO-2008-0523 Sava CMS SQLi & XSS

del.icio.us | digg

McAfee Partner isn't McAfee Secure either

Winferno.com is an authorized distributor of McAfee Software. OK.
They use Verisign 128-bit SSL to secure your transaction. Can't take issue with that.
All good so far...but wait!
Shouldn't a McAfee Partner be McAfee Secure?
Apparently not, and being one wouldn't have cured the XSS blues anyway.
Next in our video series, a supposedly secure shopping cart that is far from.

Here's an IFRAME.
Here's the cookie.
As well we know, coughing up the cookie counts as a really bad thing for any shopping cart, let alone an SSL protected shopping cart that happens to be a McAfee Partner and authorized distributor of McAfee Software. But lest we forget, McAfee doesn't count XSS as concerning.
Here's the video.
Huge props to Ronald van den Heetkamp for starting this whole debate years ago, and for exposing Brett Oliphant for the fraud that he is.
Fraud is the key word here. Hacker Safe was fraudulent, McAfee Secure is fraudulent, and buying from Winferno puts consumers at risk for being defrauded, not only due to horrendous site code, but perhaps bad business practices as well.
I won't even ask if McAfee has any standards, we already know the answer.
Their standards have left the building.

del.icio.us | digg