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