Toolsmith Tidbit: XssPy

You've likely seen chatter recently regarding the pilot Hack the Pentagon bounty program that just wrapped up, as facilitated by HackerOne. It should come as no surprise that the most common vulnerability reported was cross-site scripting (XSS). I was invited to participate in the pilot, yes I found and submitted an XSS bug, but sadly, it was a duplicate finding to one already reported. Regardless, it was a great initiative by DoD, SecDef, and the Defense Digital Service, and I'm proud to have been asked to participate. I've spent my share of time finding XSS bugs and had some success, so I'm always happy when a new tool comes along to discover and help eliminate these bugs when responsibly reported.
XssPy is just such a tool.
A description as paraphrased from it's Github page:
XssPy is a Python tool for finding Cross Site Scripting vulnerabilities. XssPy traverses websites to find all the links and subdomains first, then scans each and every input on each and every page discovered during traversal.
XssPy uses small yet effective payloads to search for XSS vulnerabilities.
The tool has been tested in parallel with commercial vulnerability scanners, most of which failed to detect vulnerabilities that XssPy was able to find. While most paid tools typically scan only one site, XssPy first discovers sub-domains, then scans all links.
XssPy includes:
1) Short Scanning
2) Comprehensive Scanning
3) Subdomain discovery
4) Comprehensive input checking
XssPy has discovered cross-site scripting vulnerabilities in the websites of MIT, Stanford, Duke University, Informatica, Formassembly, ActiveCompaign, Volcanicpixels, Oxford, Motorola, Berkeley, and many more.

Install as follows:
git clone https://github.com/faizann24/XssPy/ /opt/xsspy
Python 2.7 is required and you should have mechanize installed. If mechanize is not installed, type pip install mechanize in the terminal.

Run as follows:
python XssPy.py website.com (no http:// or www).

Let me know what successes you have via email or Twitter and let me know if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next time.

Phorum Phixes Phast

I was paying a visit to the FreeBSD Diary reading Dan Langille's post grep, sed, and awk for fun and profit (a great read, worthy of your time) when my Spidey sense kicked in.
Specific to log messaging he'd created for captcha failures, Dan mentioned that "these messages are created by some custom code I have added to Phorum."
Oh...Phorum, CMS/BBS/forum/gallery software I'd not seen before.
I installed Phorum 5.2.16 in my test environment, ran it through my normal web application security testing regimen, and found a run-of-the-mill cross-site scripting (XSS) bug. There's no real story there, just another vuln in a realm where they are commonplace.
What is not commonplace in this tale though is the incredibly responsive, timely, and transparent nature with which the Phorum project's Thomas Seifert addressed this vulnerability. I truly appreciate devs and teams like this. He even kindly tolerated my completely misreading the Github commit's additions and deletions.

August 22nd - XSS vuln advisory submitted to security@phorum.org. Yay! They have a security alias, and they read what's submitted to it. :-)

August 25th - Thomas replies and says "Thanks for your report.
We fixed the issue in the git repository, https://github.com/Phorum/Core/commit/c1423ebfff91218a4c1b31047d6baf855603cc91, and will push out a new release in the next 2 days." Sweet, not only is the project responsive and transparent, they're open with their source and change management.

August 26th - Thomas replies again, Phorum 5.2.17 is live. "Release is out:
http://www.phorum.org/phorum5/read.php?64,149490,149490#msg-149490." Outstanding! And a day early than the suggested release window. Advisory published.

One need only read the changelog to see the level of dedication and commitment Thomas and team afford their project.

Nothing else to say but bloody well done. Thank you, Thomas and the Phorum team. More smiles and less middle finger make for happier security grunts.

Cheers.

toolsmith: SamuraiWTF

December's toolsmith covers SamuraiWTF.
I'll repeat myself as stated in the article:
SamuraiWTF rocks, plain and simple.
It’d be my 2010 Toolsmith Tool of the Year but alas, I am letting you, dear reader, make that “Tool of the Year” decision for 2010 (poll details to follow as 2010 draws to a close).

SamuraiWTF is a LiveCD Linux release designed to serve you for your web pen-testing needs. Kevin Johnson of Secure Ideas and Justin Searle of InGuardians included what they believe are the best of the open source and free tools that focus on testing and attacking websites, selections based on the tools they use as part of their job duties. SamuraiWTF includes tools useful in all four steps of a web pen-test:
• Reconnaissance – Fierce domain scanner, Maltego (be sure to check out the Shodan Maltego add-on)
• Mapping – WebScarab, ratproxy
• Discovery – w3af and burp
• Exploitation – BeEF, AJAXShell

The article walks through using SamuraiWTF for each phase, but as always, I had the most fun exemplifying exploit methodology with BeEF.
Browser zombies rule! ;-)



If you seek to learn a ton about web application security testing, or consolidate all the tools you’ll likely need on one system, SamuraiWTF is for you.
As Kevin indicated for the article, you can use SamuraiWTF as your base install, then enhance with Burp Suite Pro if you happen to be a commercial Burp user.
Stay tuned for the SamuraiWTF 1.0 release, and contribute to the project if so motivated.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Online finance flaw: Ameriprise FAIL...again

Here we go again.
The cross-site scripting (XSS) issues on the Ameriprise advisor locator site were fixed, even if temporarily, back when Dan Goodin reported on the issue in August.
A little bird whispered in my ear the other day and told me a sad tale:
they're baaaaack.
Regression testing anyone?
Regression testing (from the Wikipedia entry recommends that:
"in most software development situations it is considered good practice that when a bug is located and fixed, a test that exposes the bug is recorded and regularly retested after subsequent changes to the program.
What a grand idea! Ensure that you don't reintroduce old flaws when you roll old code.
Really? I have to say it?
Apparently.



Dan & El Reg have covered the issue again given that, in order to have it fixed again, I had to ask him to ping the Ameriprise PR department.

*sigh*

BTW...the issue is fixed, for now. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

XSSing Bob: At least GoDaddy got this one right

Fair warning: This posting has a social agenda, born of my views, and will likely spark discussion. Flame all you want, but no anonymous comments accepted for this one.

I'll come right out and say it. I'm not a GoDaddy fan...at all.
I've long shared Fyodor's perspective (NoDaddy.com) and as a SecLists/nmap loyalist must swear my fealty.
And don't get me wrong, I appreciate beautiful women as much as the next guy, but they're people, not things. The level of objectification that Bob Parsons and GoDaddy have maintained during their relentless ad campaign (ramping up again for football season) is sadly archaic, exploitative, and not in keeping with a modern mindset I've hoped would be embraced more broadly.

I know I am in the minority. This is simply my opinion; I'm sure that vast majority of men who read this blog will fervently disagree with me. So be it, I honor your choices, may this free country remain ever so.

But I hate it. Women aren't objects. Believe me, I've been guilty of thinking and acting otherwise, but damn it, I'm trying. In my world women are wives and daughters, peers and managers, teachers and friends; all worthy of respect.
So when the latest GoDaddy ad harshed my football mellow this past weekend during the defensive debacle that was the Packers/Cardinals game, I found myself pissed.
Ask McAfee, neglectful credit card companies, and lame online providers what happens when I get pissed.
Yep, I got all huffy and went looking for web application issues to use to further my point.
Bobparsons.me coughed up easy fodder in short order.



Then my conscience got the best of me, and I reported the issue immediately via privacy at bobparsons.me.
I always take this step with low expectations, but was rewarded with a rapid and thoughtful response.
I reported the issue at 1910 hours, 11 January and received a call from the CISO himself, Neil Warner, who left me a VM indicating that the issue had been received, validated, and repaired by the security and development teams, all before 1200 12 January; less than 24 hours. Impressive to say the least.

So, while I heartily disagree with GoDaddy marketing tactics and shake my head when I read the endless stream of horror stories on NoDaddy, I must applaud Neil and his team for a job well done. He even used the term "human IDS." ;-)
Nicely done, Neil, nicely done.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Pligg pluggs holes: vulnerability remediation done right

Part 1 of 2 of Vulnerability remediation done *

Often, when I disclose web application vulnerabilities to Secunia, who in turn works with vendors to drive mitigation and remediation, we are met with vendors who don't reply, don't care, or don't fix.
Yet, once in a rare while a vendor chooses the righteous path.
Such is the case with Pligg.
Pligg posted a detailed, transparent, candid writeup regarding the disclosure and their response prior to the scheduled release date (12/2/09) for the advisory. In addition their new release (1.0.3) addressing the issues in now available.
As I am too often prone to complaining, I relish the opportunity to say "well done."
To Pligg, a hearty thank you; you are now amongst the standard bearing few who swiftly address vulnerabilities, do so with candor and transparency, and care about your user base.
When the advisories go live as scheduled tomorrow they will be found here and here.
Again to Pligg: well done.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Watcher: Spotting dubious webishness

November's toolsmith features Watcher, a great passive security auditor from Chris Weber of Casaba Security, that detects web application security issues as well as operational configuration concerns. Watcher plugs neatly into Fiddler, an indispensable proxy that should be an inherent part of your web application assessment tool kit.
The toolsmith article covers using Watcher to detect "dubious" comments, unset HTTPOnly flags, open redirects, and bad cross domain flash policy, so I won't repeat myself here.
Watcher is also excellent for detecting likely XSS vulnerabilities, and will passively detect prospective parameters while you browse.
As an example, a visit to a site that shall remain anonymous only to those without fundamental Google skills results in Figure 1, seen by Watcher as it passively reviews a site with 37 different checks.


Figure 1

Note that Watcher spots what it declares is a potentially high severity user controllable HTML element attribute. Watcher further indicates that the fourth input tag value attribute is specific to the keyword variable. A quick "active" test by the author quickly validates Watcher's assumptions as seen in Figure 2.


Figure 2

Passive security auditing indeed; no effort required!
Results are easily exported as well.
Browse a client site while enjoying a good sandwich and coffee, dump the results, and build your work list as a preliminary recon step for your next penetration testing engagement.
Enjoy this excellent tool; use it in good stead.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Amex II: Ameriprise mishandles disclosure too

Yet another online finance flaw for your consideration.
Remember the American Express issue?
Apparently the negligence and ignorance of the parent has been inherited by the child.
It took me pinging Dan Goodin at The Register and asking him to shake Ameriprise out of their slumber to address the most commonplace, simple, web application bug of all: XSS. Really? Still?
Dan did a bang up job of the task at hand; it was fixed within hours. Ameriprise had ignored my multiple attempts to disclose over five months. Power of the press, eh?
The story is here.
I also owe Laura Wilson at Information Security Resources for alerting me to likely issues with Ameriprise.
I'm tired of having to say it. It's even gotten to the place where readers get pissed at me because I keep stressing the point. But I shouldn't have to.
Major financial providers should not be ignoring reports of common web application vulnerabilities sent in via all their available channels.
Major financial providers should be reviewing their web sites and their code at regular intervals, proactively preventing these issues.
Blah, blah, blah...you can't hack a server with XSS.
If you attended BlackHat or Defcon a few weeks ago, you may realize how much less relevant that argument is.
Check out the XAB, Firefox extensions, and evasion discussions.
You can be pwned through XSS.
Do I need to stress compliance again? Amex touts itself as a founding PCI partner, yet here we go again.
Vendors and developers need to get smarter, faster, and more responsive to security related notifications, particularly with regard to their websites.
To that end, keep an eye on the Data Security Podcast. Ira Victor and I have hatched a scheme to promote the use of proper disclosure handling by website operators such as major financial services providers. He'll also be posting podcasted discussions we've had regarding the disclosure issues, as well as the forensic challenges presented by CSRF attacks (another easily avoided, common web application vulnerability).
I'll also be talking about a pending ISO standard for disclosure that I hope will begin to drive enterprise adoption of improved disclosure handling.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

AppRiver: SaaS security provider sets standard for rapid response

On July 28th I was happily catching up on my RSS feeds before getting ready to head of to Las Vegas for DEFCON when a Dark Reading headline caught my eye.
Tim Wilson's piece, After Years Of Struggle, SaaS Security Market Finally Catches Fire, drew me in for two reasons.
I'm a fan of certain SaaS Security products (SecureWorks), but I also like to pick on SaaS/cloud offerings for not shoring up their security as much as they should.
The second page of Tim's article described AppRiver, the "Messaging Experts" as one of some smaller service providers who have created a dizzying array of offerings to choose from.
That was more than enough impetus to go sniffing about, and sure enough, your basic, run-of-the-mill XSS vulnerabilities popped up almost immediately.

Before...


After...


Not likely an issue a SaaS security provider wants to leave unresolved, and here's where the story brightens up in an extraordinarily refreshing way.
If I tried, in my wildest imagination, I couldn't realize a better disclosure response than what follows as conducted by AppRiver AND SmarterTools.
Simply stunning.

Let me provide the exact time line for you:
1) July 28, 9:49pm: Received automated response from support at appriver.com after disclosing vulnerability via their online form.

2) July 28, 9:55pm: Received a human response from support team lead Nicky F. seeking more information "so we can look into this".
(SIX MINUTES AFTER MY DISCLOSURE)

3) July 28, 10:27pm: Received a phone call from Scott at AppRiver to make sure they clearly understand the issue for proper escalation.
(NOW SHAKING MY HEAD IN AMAZEMENT)

4) July 29, 6:35am: Received an email from Scottie, an AppRiver server engineer, seeking yet more details.

5) July 29, 8:51 & 8:59am: Received a voicemail and email from Scottie to let me know that one of the vulnerabilities I'd discovered was part of 3rd party (SmarterTools) code AppRiver was using to track support requests.
(MORE ON THIS IN A BIT)

6) July 29, 2:08pm: Received email from Steve M., AppRiver software architect, who stated that:
a) "We deployed anti-XSS code today as a fix and are using scanning tools and tests to analyze our other web applications to ensure nothing else has slipped through the cracks. We do employ secure coding practices in our development department and take these matters seriously. We appreciate your help and are going to use this as an opportunity to focus our development teams on the necessity and best practices of secure coding."
b) "Regarding XSS vulnerabilities you detected in the SmarterTrack application (the above mentioned 3rd party tracking app) from SmarterTools, one of our lead Engineers and myself called them this morning explaining the vulnerability and requesting an update to fix the problem. We also relayed to them that a security professional had discovered the vulnerability and would be contacting them to discuss it further."
(I AM NOW SPEECHLESS WATCHING APPRIVER HANDLE THIS DISCLOSURE)

NOTE: Less than 24 hours after my initial report, the vulnerabilities that AppRiver had direct ownership of were repaired.

7) July 29, 4:17pm: Received an email from Andrew W at SmarterTools (3rd party tracking app vendor) who stated "thank you for pointing this out to us... we will be releasing a build within the next week to resolve these issues."
(CLEARLY STATED INTENTIONS)

8) August 4, 8:02am: Received another email from Andrew W at SmarterTools who stated "we plan to release our next build tomrrow morning. (Wednesday GMT + 7) I will let you know as soon as it becomes available for download on our site."
(CLARIFYING EXACTLY WHAT THEY SAID THEY WERE GOING TO DO)

9) August 5, 9:37am: Received another email from Andrew W at SmarterTools stating that "a new version of SmarterTrack is now available via our website. (v 4.0.3504) This version includes a fix to the security issues you reported."
(DID EXACTLY WHAT THEY SAID THEY WERE GOING TO DO)

10) The resulting SmarterTools SmarterTrack vulnerability advisory was released yesterday on my Research pages: HIO-2009-0728

I must reiterate.
This is quite simply the new bar for response to vulnerability disclosures.
It is further amazing that such a process was followed by not one, but two vendors.
I am not a customer of either of these vendors but can clearly state this: if I required services offered by AppRiver and SmarterTools, I would sign up without hesitation.

AppRiver and SmarterTools, yours is the standard to be met by others. Should other vendors utilize even a modicum of your response and engagement process, the Internet at large would be a safer place.
Well done to you both.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

DEFCON preview: Netgear RP614 CSRF attack video

To give you a sense of what Mike Bailey and I will be covering at defcon 17 this Saturday at 11am, I thought I'd give you a little taste courtesy of a Netgear RP614v4 router that suffers from cross-site request forgery (CSRF) vulnerabilities, as well as persistent cross-site scripting (XSS) issues.
See OSVDB advisory 54885 for further specifics. BTW, please support OSVDB!

The short version:
The Netgear RP614v4 web-based administration interface allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. This can be exploited to perform administrative actions or conduct script insertion attacks e.g. when a logged-in administrator visits a malicious web site.
The sad truth of the matter is this, while I don't have access to the whole Netgear product line, the reuse the same firmware codebase across multiple devices.
Thus, in all likelihood, there are numerous Netgear devices vulnerable to this issue, if not all.
The same holds true with Linksys devices, which we'll cover in detail at DEFCON.

As you will see, the approach is simple, and too often effective.
1) Miscreant crafts email utilizing well proven social engineering methodology.
2) Victim follows orders and, while authenticated to vulnerable device, clicks on that damned link.
3) Vulnerable device does not perform any validity checks to verify the requests made via the attacker's web page lurking behind the link in the email.
4) Vulnerable device fails in whatever fashion it's told to.

As exhibited in the video I've created for your viewing pleasure, I force the admin session to enable remote management (disabled by default) and change the remote management access port to 6667 for old time's sake. If, as it so often is, the admin account is left to default password, game over. Or, in many cases, you can also force a password change via CSRF as well.
Any function the firmware provides can be forced via a victim admin's session; that which is exhibited here is but a single examplar.
Tokens, people...tokens!

The video, as promised:
Lo-fi (5.63 MB MP4)
Med-fi (53.9 MB WMV)
Hi-fi (73.4 MB AVI)

Hope to see you at DEFCON; please say hi if you're there on Saturday.
I'll be easily spotted in jeans and my white Certified Application Security Specialist (ASS) golf shirt.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

steekR security steenkS

My RSS reader continues to provide me subject matter for analysis, and the recent F-Secure purchase of steekR, “Your Secured Online Space”, was no exception.
The purchase was described by El Reg as follows:

F-Secure grabs online storage firm in cloud security push
Steek's technology is designed to allow users to upload data from either PCs or mobile phones. Bordeaux-based Steek already partners with mobile telcos (including Virgin Media, SFR in France and SingTel), a factor which F-Secure hopes will increase its ability to sell Software as a Service (SaaS) technology packages through operators.

Oh boy, here we go again.
I want to create a new line of Bobbleheads for Cloud and SaaS. They’ll talk as well, bobbling and blathering the latest buzz words:
“We’ll give you the best ROI in the cloud!”
“Our SaaS offering relieves you of any responsibility, we’ll do it all!”
I digress.
I understand the business model, and F-Secure’s motives for the purchase; it’s hard to find fault there.
But as I’ve indicated time and time again, when you purchase or integrate another vendor’s offerings, you immediately inherit their shortcomings as well.

I propose a blamestorming session. I’d like to start with steekR.
steekR suffers from persistent cross-site scripting (XSS) flaws.
They further suffer from a complete inability to respond to responsible disclosures (multiple attempts over two weeks).
Thus, I struggle with their “Your Secured Online Space” claim. As in…not so much.
Imagine this scenario:
1) An attacker creates a steekR account.
2) The attacker embeds malicious JavaScript.
3) The attacker then shares steekR content in a manner that exposes it to any victim who errantly clicks through.
4) You receive email notification of the share and given your use of steekR (you and 2,405,935 other customers), you click the URL.
5) Your browser is directed to a steekR share with a malware-laden IFRAME embedded.
6) You’re pwned.

I'll walk you through it.

Here's the email...


Here's the URL in the email (no, I'm not trying to pwn you):
http://www.steekr.com/n/50-2/share/LNK32784a66232b7baaf/
Click My Documents in the left pane and you'll see the IFRAME in the right pane when you mouse over the folder.

Here's the result when you click said URL...


That IFRAME could easily be something nasty.
Similar scenarios can easily lead to data breach, account compromise; pick your poison.
Lest you forget, persistent XSS issues are far uglier than their reflected kin.

Lesson for companies like F-Secure on the venture integration path:
Review the acquisitions security-related practices, or lack thereof, and conduct a thorough assessment of the product driving the decision to purchase them.

Lesson for users of SaaS offerings:
Assume no privacy, and no guarantee of security. A trusted resource may not be trustworthy.

Steek and you might stumble. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

eWeek hypes "secure" SaaS without checking the facts

In an article called SaaS Proof Points, eWeek put on the blinders and jumped on the bandwagon declaring such SaaS wisdom as "not only have modern SAAS applications assuaged security concerns, but the SAAS model itself is seen by some as the most secure approach to handling data".
What!? Wow.
Add to that the well-intended declaration of SaaS neophyte Kimberly Rogers of Santander Consumer USA, while detailing her company's use of Service-now.com. Rogers, who had never worked with a SaaS-based application before, added that "security can be as tight as you want it to be." Noting such blind faith from a Service-now.com user I was motivated to take a closer look at the provider.
Kimberly, respectfully, you are making a dangerous assumption.
Putting on my bad guy hat for a second, if I can entice you to click a link in a targeted, specially crafted email (phishing), that in turn executes JavaScript in the context of Service-now.com (cross-site scripting) and returns the cookie you use for authentication to Service-now.com (credential theft), is it still reasonable to assume that "security can be as tight as you want it to be"?
I think not.
Service-now.com suffered from a cross-site scripting (XSS) vulnerability that allowed cookie theft and other XSS fun such as frame defacement.

Before XSS:


After XSS:


Please note that Service-now.com responded to my advisory and made repairs in a reasonable amount of time, all the while communicating admirably.
That said, if SaaS providers don't ratchet down hard on their basic web application security, silly yet valuable data spills such as described above will continue to prevail unabated.
If trade publications continue to publish hype rather than balanced facts I must assume that data breaches and provider shortcomings will continue to be commonplace as said providers won't be held to a higher standard.

When StrongWebmail fell so readily to an XSS vulnerability this past week (well done Lance, Mike, and Aviv), I simply shook my head in dismay. Are service providers so blind as to not consider the holistic security view before putting 10k on the line?
That was a rhetorical question.
Answer? Obviously.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

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

The McAfee Secure Standard has been published

McAfee has alerted me that the McAfee Secure Standard has been published on the McAfee Secure (formerly ScanAlert Hacker Safe) website.
The McAfee SECURE Standard
Joe Pierini and Kirk Lawrence started this process with me prior to their departure from McAfee, and work continued in their absence, largely at the hands of Will M., who's been communicative and inclusive in their stead.
I applaud McAfee for staying true to their commitment to publish the McAfee Secure Standard.
While I may not agree with everything in it, a standard is better than no standard.
That said, my concerns with the Standard as discussed earlier remain unaddressed.
First, you will find that remediation of what McAfee deftly refers to as Client Side Vulnerabilities is Optional. The Client Side Vulnerabilities category includes the entire family of script insertions.
Clarified, this means that merchants displaying the McAfee Secure trustmark are under no obligation to repair such vulnerabilities; the trustmark will remain displayed unabated by the truth.
My position here is clear.
If a website declaring itself secure via a McAfee Secure trustmark is vulnerable to cross-site scripting (XSS), I believe that declaration to be false and misleading. Further elaborated, the McAfee Secure Standard's Client Side Vulnerability category includes cross-site request forgery (CSRF).
While I choose not to out any site in particular at this time, I can assure you with all professional certainty that there are sites displaying a McAfee Secure trustmark that are vulnerable to CSRF. In the case of sites using one particular application, the CSRF vulnerability is so severe, an attacker can escalate privilege in short order.
This is a vulnerability that I've discovered and disclosed responsibly, so I won't discuss it further at this time.
But I ask you, should a site vulnerable to such an attack be labeled as McAfee Secure, per their freshly published Standard?
I think not.
Also Optional on the McAfee Secure Standard: SSL Encryption.
Should a website that conducts financial transactions, yet does not choose to encrypt transaction traffic, be allowed to display a McAfee Secure trustmark?
I think not.
Ironically, the McAfee Secure Standard directly compares itself to PCI DSS. None of the vulnerabilities listed as Optional, per the McAfee Secure Standard, are acceptable for PCI certification.
While the McAfee Secure Standard careful delineates the difference between the Secure trustmark program and their PCI Compliance program, it's not as black and white as they may think. McAfee is a PCI approved scanning vendor (ASV), and a provider of a popular PCI compliance service.
Should they really hold one set of customers to a different standard than the other?
I think not.
Again, I applaud McAfee for publishing the McAfee Secure Standard.
I never imagined we'd get this far, so I humbly ask McAfee to consider the following.
1) Don't bury the Standard. Announce it. Publicize it. Embrace discussion about it. Provide a link to it from the McAfee Secure website. While we may have differences over some of its content, the McAfee Secure Standard is a bold step. Let people know.
2) Disguising script insertions (XSS and CSRF) in the Client Side Vulnerabilities category is a disservice to your customers, and their customers. The "clients" in Client Side Vulnerabilities are consumers using these sites. I believe you are beholden to these consumers as much as you are your own.
Extend the timetable for merchant repair of these vulnerabilities if you must, but said repair should not be Optional.
3) A McAfee Secure site, with a McAfee Secure trustmark, without an SSL certificate is unfathomable. While many a vulnerability can be exploited under the umbrella of SSL protection, SSL encryption is nonetheless an industry standard that should not be Optional.
These things I ask of McAfee in the name of common sense and consumer well-being.
To quote the McAfee Secure website:
"When you display the McAfee Secure certification mark, you not only increase sales by increasing shopper confidence, you build your brand with the security seal seen on more top sites than any other."
Is "increasing confidence" at the expense of industry standards, and real web security a violation of good faith and the very trust you seek to build?
I think so.

As always, I welcome constructive and thoughtful comments and feedback.

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

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

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