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