Flash Origin Attack FAQ

Okay, people are looking at this Flash issue. Neat. A lot of people don't fully understand it, which may be my fault. Here, I'm going to try to respond to some of the questions and comments that I've received from various parties.

This is not a single issue

While it is a single, basic issue that enables this exploit, it is the
intersection of that and several others that makes it critically bad.

Specifically, the fact that an uploaded file can attack a server is hardly news. As mentioned in my original post, Adobe has acknowledged this issue with advisories multiple times. If you were already aware of it, good on you. However, it still is new to most website administrators, and more importantly, these are the people that Adobe expects to fix it.

The part that is new, is the focus of this research, and admittedly could have been described better, is that the Flash player will execute any file it is asked to execute. The HTML <embed> tag is used to include objects that the browser may not be natively able to handle. Arguably, this may be a browser issue as well, as the content-type supplied by HTTP headers should take precedence over the type attribute specified in the HTML page, but the plugin itself should also verify that the proper content-type is sent in the server's response HTTP headers before executing the plugin. Flash's plugin does not do so.

If Flash's plugin did handle this correctly, the other issue documented here- that of overloading various filetypes, primarily ZIP, would be nearly useless. The point of that work was to demonstrate just how difficult it is for administrators to filter uploaded content by file validation, and to provide various examples of how to bypass such validation with 100% legal files, which are still potentially malicious. More on that in a moment.

This is not a cross-site scripting attack

The end result of the attack can indeed be XSS, as Actionscript may execute Javascript through the "ExternalInterface" method, but the source of this problem is not necessarily input sanitization. It is a core design flaw in Flash's same-origin policy, combined with the weak content ownership management that is already common on the majority of websites and prebuilt web applications on the internet.

Calling this attack XSS, when it involves no Javascript (arguably, not really a requirement), is not cross-site (again, not really a requirement, despite being in the name), and involves no HTML injection, is a stretch, but the similarity is certainly there, bringing me to the next point:

This attack abuses the user to attack the server

This is where it is very similar to XSS. The whole point is to hijack the user's browser and have the ability to issue requests to, and read the results from the server. In the context of a user's session, this can be a very bad thing. Neither the server itself nor the client's computer is being compromised directly; The web application, and any data or functionality within, is now accessible to the attacker.

Adobe does not intend to fix it

As they have made abundantly clear, Adobe considers this to be the web administrators' problem. Regardless of whether you agree with them or not on this, it is hard to dispute that Adobe's expectation of administrators to prevent this issue is unrealistic.

In fact, Adobe does not appear to be able to manage this issue on their own web properties. For example, photoshop.com is an interactive image library application. Uploaded images are not validated fully, and are stored on (and executable from) api.photoshop.com. This is indeed a separate domain from the rest of the application, and should be safe (though I'd point you to my paper on cross-subdomain attacks and say it is still poor practice), but www.photoshop.com's crossdomain.xml policy specifically allows access from *.photoshop.com.

Next, take a look at bugs.adobe.com. This third-party issue tracking system allows users to upload screenshots (or zip files of screenshots) of bugs. These files are hosted on bugs.adobe.com, and can be used to exploit not only bugs.adobe.com, but again through crossdomain policies, www.adobe.com, www.acrobat.com, www.photoshop.com, and other Adobe web properties.

You'll never guess where www.photographersdirectory.adobe.com keeps its uploaded images. Or where forums.adobe.com keeps users' uploaded avatars.

Clearly, expecting website administrators to understand, not to mention be able to fix this issue is ridiculous and unrealistic. I originally compared this to the GIFAR exploit, which uses very similar attack techniques against the Java plugin. Unlike Adobe, Sun took responsibility and fixed their plugin. Whether they are wrong or right, Adobe is uniquely in a position to create a client-side fix for the Flash users. Until they do so, many websites will remain vulnerable.

Parsing Quirk Causes bit.ly XSS

Fun fact: When your browser parses a document, it locates <script> and </script> tags before evaluating the javascript within. While this appears to make sense, it creates an interesting quirk- injected </script> tags, even within quoted javascript strings, will force it to end a block of javascript code and throw a parse error. It will also allow you to start a new block of unquoted (and therefore, executed) code.

I put together a basic demonstration of this quirk a while ago and bounced it off a few people. As it turns out, this is known behavior, and was even used in one of the first examples on RSnake's XSS Cheat Sheet.

Arguably, this is not really even a bug. It stems from the order in which the document is parsed- structure (tags) is handled before parsing javascript content. I looked into the various standards that apply and didn't see anything dictating how this behavior should be handled, but I confess I didn't look that hard.

At any rate, the reason I'm writing about it today is because I found an XSS hole in the popular URL shortener, bit.ly. This can be used to compromise browsing history, tamper with a user's bit.ly settings, and even abuse Twitter accounts (they have a Twitter API).

Due to the nature of the exploit the link only works once, so I can't send you directly there. However, if you take the following URL and make "CHANGEME" a unique string, it should work.

http://bit.ly/?url=http%3A%2F%2Fskeptikal.org&keyword=%22%3C/script%3E%3Cscript%3Ealert(1337)%3C/script%3ECHANGEME

While it's generally known that putting user-supplied input into executable code is a bad idea, many developers still do it, especially with javascript. Don't assume that just because the input is wrapped in quotes, it will not be XSS-able.

Most PCI Companies Are Insecure

The McAfee XSS got slashdotted. I think that all this attention is a good thing, putting a spotlight on XSS issues, but I have to say, I'm surprised by it. It's not like XSS attacks are news anymore, and it's not as if this is the first McAfee XSS to be published. Last night, I found an XSS hole in the verification script for their SiteAdvisor service (for extra irony).



But really, focusing on these XSS holes is missing the point. I never thought I'd say this, but in my experience, McAfee is one of the better ASVs out there. This isn't a compliment to them, it's an insult to the entire industry. Here are a few examples of other ASVs.

Until last week, atsec.com was vulnerable to XSS.

Until last week, secureconnect.com was vulnerable to XSS.

Until last week, ncircle.com was still vulnerable to XSS.

sungard.com is still vulnerable to XSS.

controlcase.com is still vulnerable to XSS.

support.foundstone.com (McAfee's premium brand) is still vulnerable to Cross-site Framing.

Up until a few weeks ago, there were also open redirects on the websites of Qualys, SecurityMetrics, and others. Is it any wonder I'm not at all shocked at a few XSS holes in McAfee's web site?

Some of these companies should be commended for handling the vulnerabilities correctly- nCircle, SecureConnect, Qualys, and even McAfee responded admirably- sometimes the issue was fixed within minutes of my vulnerability report. Others- Foundstone, ControlCase, and Sungard, belong in the doghouse- none of them even responded.

However, the glaring fact is that the entire PCI scanning industry is, frankly, bad at scanning for vulnerabilities. Most of these websites use their own scanning service on their own websites. While I still hold that in-depth audits for these sites should have taken place long ago, the scanners should have caught the problems as well. Some of these domains contain the portals for customers to manage their PCI compliance scans.

People, let's take the focus off of McAfee, and put it where it belongs. The PCI scanning industry as a whole is a joke, and across the board, these Web Security companies are themselves bad at security.

Edit 5-6-2009: nCircle was one of the fast-responders.
I mistakenly listed them as one of the "doghouse" ASVs.


Epic Failure from McAfee

When you outsource all your PCI scanning to another company, you'd expect that company to be careful with your data. First off, there's the fact that security is what they do- if that data were to get leaked, you'd expect the damage to reputation alone to be crippling.

Second, (and probably the least important, really), the PCI ASV validation requirements (section 4.5.1, if you're interested) make it pretty clear that client data should be kept very confidential.

Finally, the data contained on those servers- lists of vulnerabilities on all their clients' systems, along with security administrators' passwords and more, is pretty high on the list of Things You Don't Want Getting Out.

You know what's coming.

We've found problems with McAfee time and time again. I was saving this for a post later this week, but given recent events, I think the time is right.

Until last week, McAfee Secure was vulnerable to critical CSRF holes. Not little ones, or ones that were difficult to exploit- basic, zero-kowledge, classic GET-based total-account-compromise holes. I think the pictures tell the story:









I sent a vulnerability report to a contact at McAfee and they responded quickly, communicated with me, and fixed the issue. They also began reviewing their entire codebase for similar holes. I commend them for that, but I cannot overlook the fact that this vulnerability never should have existed in the first place.

It's not going to be a surprise to anybody, but this is solid proof that McAfee Secure is mis-named. Their failure here is on an epic scale:

• They did not comply with PCI requirements for ASVs


• They did not use a secure software development lifecycle in building this application


• An in-depth penetration test should catch an issue like this, so I presume that no such audit has taken place


• Until I reported it, they had never performed a full code review for web vulnerabilities


• As you can see in the 1st and 3rd screenshots, the application was itself certified as McAfee Secure when I performed this demonstration.


• At no point in five weeks from me finding the vulnerability and it being fixed was that McAfee Secure logo removed from their own website.

The ultimate and obvious irony, however, is that McAfee Secure is in the business of testing others' web applications. I'll be the first to say that they are not equipped to do so.

I have a lot more information coming on this and related issues. Try the veal, tip your waitress, I'll be here all week.

Mass Hosting && PCI: A Case Study

Just as a quick follow up to my earlier post, here is a prime example of a "PCI Compliant" company who is probably not.

I attempted responsible disclosure several weeks ago and received no response from this company, a New York based web hosting and development company. I'm not trying to get them in trouble, so I redacted the screenshots and won't refer to them by name, but I have no doubt that anybody who cared could find them quickly enough.

As part of my research, I made a phone call to this company. I inquired about the PCI compliance of their servers, and the sales associate assured me that their servers are scanned regularly and are compliant. He did not tell me who their ASV is, and while I have my theories, I won't speculate publicly.



Regardless, this company has a login portal on their main web site. I know one of their customers, so I can tell you that the credentials used to log into this portal are used for customer cPanel accounts, billing system, and webmail. Those credentials are probably pretty valuable, right?



How did this site ever pass any kind of PCI testing? It's only a theory, but I suspect this is because it's on a mass-hosted server. When you hit the server directly by IP, it brings up the default cPanel page.



But this company was, by their claim, 100% PCI compliant. They told me that some customers also get their sites tested and are in turn PCI compliant.

Full Disclosure: Terms of Engagement

As part of my research, I have been reporting a lot of web-based vulnerabilities lately. I've been using the following procedure to report those vulnerabilities, and I think that I should make this procedure known.

When I publish a vulnerability, I will make what I feel is a reasonable effort to inform a website or application's maintainer about it before making it public. I enjoy breaking websites, but I have no intention of causing any particular company or website harm. Having reported hundreds of issues over the past few years, I've found that often, they are only fixed when there is a threat of them being made public. My goal is to promote quick patching of holes, to fix what I see as widespread poor security practices, and to educate system maintainers about the risks that they face.

Before submitting a report, I will check several vulnerability tracking services. If unfixed issues that are over 1 month old exist, I will assume that the site's maintainers do not take these security issues seriously, and I will publish the vulnerability at my discretion. I may or may not attempt to contact the affected site's owner.

If no old vulnerabilities exist, I will check the website for a contact email address. I will not submit vulnerability reports through web-based contact forms, customer portals, or by speaking with a salesperson. If an email address is not available on the website, I will do a whois search for this information. Barring that, I will attempt to email the report to abuse@, info@, root@, security@, and webmaster@yourdomain.com.

Once a vulnerability report has been submitted, I will wait one week for a response before publishing at my discretion. If the website's maintainers are responsive, acknowledge the issue and keep me informed with regards to the patching process, I will attempt to coordinate my disclosure so that it is published after the issue has been fixed, and may postpone the publishing to do so.

I will note that I only provide notice as a courtesy, to give website maintainers an opportunity to address the issues before they go public. While no website is perfect, I expect website owners, particularly those with business-oriented websites, to act responsibly in handling these issues efficiently.

Some researchers are more generous with timeframes and will even attempt multiple contacts over several weeks. In my experience, a site owner that is unresponsive for the first week will rarely improve in the next. My own time is valuable and I have no intention of wasting it in contacting an unresponsive party.

When I do make a vulnerability public, I may choose to do so through a public vulnerability tracking service, on my own website, or in the form of other writing, speaking, or consulting engagements. If the response and interaction I recieve from the site owner is positive, I will generally attempt to make that known at the time of publishing. The corrollary is also true- if my report is met with disinterest, threats, or negative feedback, I will make every effort to ensure that it is publicly known. Frankly, you don't want to go there- controversy tends to make headlines.

As noted previously, I am here to help, but I'm not necessarily here to help you.

Photobucket Private Album Access via CSRF

I've been playing a lot with CSRF lately. As I find ways to manipulate more and more services with what is probably the most basic type of attack possible, I keep getting surprised by the insanely cool things that one can do with it.

Photobucket allows users to make albums either "Public" or "Private", the latter of which will enable access only with a guest password. While chatting with a friend online recently, I tried to view one of her private albums. Knowing what I do for a living, she gave me permission to do so, but said I'd have to find my way in without her help. So I did.

The form for setting a private album's password, as well as the one for making an album public, both are vulnerable to CSRF. In fact, both use GET parameters to do their magic, so it's actually pretty trivial to pull off a successful attack. I wrote a proof of concept, but it's really not that complicated.

Not only can users' albums be made public, but variations on this exploit can be used to change passwords on albums, delete photos, and compromise account passwords. This really is a serious issue- while Photobucket's TOS may protect them from liability (and may or may not hold up in court), there are a lot of extremely private photos stored there.

I emailed a vulnerability report to Photobucket on the morning of 4-9-2009, but have not received a response.

Cgiecho XSS and Information Disclosure

cgiecho is a test cgi script, usually packaged with a formmailer called cgiemail. It's found in the cgi-bin directory of a lot of sites, due to it being a default script in many cPanel installations. The script was written by somebody at MIT some time ago, and so is common on high-profile sites such as mit.edu and
xmission.com.

The script contains XSS and path disclosure holes, one example of which can found on mit.edu, but that's not really the emphasis of this report.

Basically, cgiemail allows a user to specify a template file from anywhere within the web root. When data is posted to it, substitutions are made based on the parameters posted and the content of the template file.

For example, if a template file "/templates/mail.txt" contains the following:

Hello [firstname] [lastname]!

When the parameters firstname=dr&lastname=evil are submitted to http://victim.com/cgi-bin/cgiecho/templates/mail.txt, the returned page will make those substitutions.

Many web scripting languages dereference array values using the [] characters, so the cgiecho script can be forced to return the contents of sensitive files if the index of any one array is known.

If a configuration file is located at /includes/config.php and contains the following:

define('HOME', $_SERVER['DOCUMENT_ROOT']);
define('USERNAME', 'victim');
define('PASSWORD', 'secret');

An attacker can post "%27DOCUMENT_ROOT%27=bork" to http://victim.com/cgi-bin/cgiecho/includes/config.php and read the contents of that file.

define('HOME', $_SERVER[bork]);
define('USERNAME', 'victim');
define('PASSWORD', 'secret');

For testing purposes, a form to generate correct attack parameters is located here.

Reporting Security Holes

With Russ's latest blog post came links to a few articles dealing with the recently exposed American Express XSS holes. In short, AmEx dealt with it badly- ignoring Russ's three attempts to contact them and only fixing the issue when it got posted publicly (after their PR watchdogs brought the post to their attention).

One of the more interesting articles was at BetaNews. Please read it.

I don't think that AmEx's web developers read my blog (at least I haven't seen many related IPs pop up in my logs), but maybe they should. Their primary excuse for not fixing the flaw is that it didn't get to the right people.

Now, exactly whose fault is that?

I wrote a few months ago, in my "Open Letter to The Internet" that website owners need to make it painless to report security issues. If they don't provide a simple process for doing so, I have a hard time feeling sorry for them. Russ's goal was to get the bug fixed, and contacting the company didn't do it. Once he posted it publicly, people actually started caring. (Unfortunately, the fix only lasted a day before getting broken by two more researchers, which makes me think that AmEx's programmers are inept to begin with).

Russ made a good-faith attempt to contact the company not one, but three times. He sent messages to two different entities and gave them two weeks to respond. If it had been me reporting the bugs, I certainly wouldn't have given them that much effort unless I was on their payroll.

As I wrote back in August, "We are here to help, but we aren't necessarily here to help you."

More McAfee Snake Oil

The McAfee Secure certification is useless.

Over at holisticinfosec.org, Russ McRee has been covering this in depth, but I've had the fortune to know the inside story.

Russ has been making snake oil vendors' deficiencies public for some time. A few weeks before Black Hat, he and I were talking about this, and he showed me a handful of "McAfee Secure" sites. All of them had XSS holes, and many had much worse- SQL injection and other serious issues. Over the next few weeks, we traded more vulnerabilities as we found them, and he amassed a pretty impressive list of weak, but certified secure sites. To top all of this off, we found XSS holes on McAfee's own domain.

We also got our hands on a PCAP dump of one of their scans, which revealed quite a bit of insight into the scanning process. We were able to prove that they do not revoke PCI compliance or McAfee Secure certifications for XSS, though the engine does indeed fuzz for (and occasionally even find) them.

While they were being awarded their Pwnie, Russ put together a paper detailing these findings. He sent the paper to McAfee before publishing, in order to give them a chance to address the issues before they were made public. They surprised us both by responding positively. Some of McAfee's top people spoke with Russ in person a few weeks later, resulting in him publishing this blog post.

That was some time ago, but we still haven't seen any progress. A published standard for what exactly "McAfee Secure" means was promised after 2-3 weeks, and we're now pushing five. The information that we have isn't encouraging- it appears that McAfee Secure will have a different set of standards for enterprise websites and the smaller "Ma and Pa" shops. The latter will not be required to fix XSS issues and the former will not have to do so until an arbitrary time period has expired. What this means is that, to a user looking for evidence that a site can be trusted, the "McAfee Secure" badge on a website will mean exactly what it does now: Absolutely nothing.

I suppose that anybody can offer their own meaningless certifications (and some people have), but as Rafal noted yesterday, calling these sites "McAfee Secure", "Hacker Safe" or anything of the sort is in poor taste at best- fraudulent on the other end of the spectrum.

This brings us to today.

It appears that McAfee intendes to leverage their brand recognition and captalize on the trust of the ill-informed. They have a new service advertised on parts of their website. Found at secureshopping.mcafee.com, it is basically a meta-search engine which will allow one to "shop with confidence at McAfee SECURE certified merchants", according to the text on the site. This actually doesn't strike me as a bad idea, provided the certification is worth something. Considering the certification isn't, the whole thing is rather laughable.

I first stumbled across this site just before Black Hat. The app was probably not intended to be public then, but I immediately (accidentally, actually) discovered an XSS hole in it (this was one of the holes on McAfee's domain mentioned above). While that hole has since been fixed, the situation really isn't any better now.

To begin with, the application doesn't use transport-layer encryption, and is therefore vulnerable to sniffing, tampering, and all the man-in-the-middle attacks that we already know and love. But who bothers with SSL these days?

The shopping application itself seems to be based on the same code as that of become.com. Actually, they appear to have partnered for this service, because when you click a link from McAfee's site to a particular product, you are given a 302 redirect to partner.become.com, then to stat.dealtime.com (whoever that is). From there you are 302-ed anywhere from one to three more times before landing on the requested product page, provided by a McAfee Secure merchant.

In theory, at least.

For the sake of breaking things, let's build a link that will take us through the McAfee Secure gateway to an uncertified website. We'll go to www.become.com, find a product, then deconstruct the link and pass its unique identifier to McAfee shopping center (which, being based on the same code, uses the same format for its links). Lo and behold, the following link will take you directly to the product on Amazon.com- which according to McAfee Secure, is not McAfee Secure.

Next, let's take a look at the app's session ID generation. Admittedly, sessions don't appear to be used for anything in the site (except maybe tracking user activity), but I have to assume that session functionality was added for some reason, and it nicely demonstrates their own lack of understanding of web application security. Can you find the pattern?

1223516988361-0-9IDB
1223516989602-0-gnpY
1223516990254-0-SZPR
1223516990913-0-F9jC

That's right folks, they're using timestamps as session IDs. Now, I've seen this practice used by banks, mortgage companies, and ecommerce sites, but I never expected to see such poor practices on the website of the "world's largest dedicated security technology company" (their boast, not mine).

Finally let's look at the partners, who we have to assume will help provides us "a secure online shopping experience with thousands of McAfee SECURE sites". The sites at become.com and dealtime.com are themselves riddled with XSS and open redirect holes (not to mention storing the answer to a CAPTCHA within the form to be submitted).

With such poor decisions being made, can we really expect McAfee Secure to live up to its name?

A Grain of Salt

From time to time, I'm asked to evaluate a particular application for use on my company our our customers' servers. This is often depressing, as most of the ready-built web apps out there are poorly written at best. This is pretty much the status quo, it would seem.

I evaluated V3 Chat, a web-based instant messenger service, about a year ago for a client. Based on the high number of XSS and other holes in the software, I strongly recommended against it. The client found another solution, and life went on.

Today I was asked to look at it again, as another client wanted to use it and a new version has since been released. Within seconds, I found the first of many holes in their demo.

Normally, this wouldn't irritate me so much- recommend that they not use it, move on with life, etc. But the vendor's web site states the following as a bullet point:

"New! - Improved User Security. Greater safety and security for private chat conversations. Increased protection against XSS and MySQL attacks."

The really irritating part to me here is the fact that they are using improved user security as a sales point, when not just the original, but the "improved" version of the software would not pass basic PCI compliance testing. They haven't even fixed the XSS hole that I emailed to the vendor several weeks before sending it to XSSed.com about a month ago (this was partially the inspiration for my Open Letter to the Internet at about the same time). While this software is, in my professional opinion, lousy, this is nothing new to the web. Unfortunately, there is a lot of broken software out there, and very few vendors, much less their customers, realize this.

What would it take to fix the web? A lot, I'm afraid. Bruce Schneier keeps telling people that it starts with legal accountability on the vendor's part, which I'm inclined to agree with. In the meantime, you can secure your own web services with a healthy dose of skepticism (hence, the title of my blog). It's common enough that it's not even news anymore, but I've seen far too many instances of encrypted, unbreakable, or "improved" software turning out to be insecure.

Whenever my company is looking to use some commercial software, they run it by me first. I talk to the sales representative and am always told that the product is perfectly secure, will solve all my problems and whiten my teeth while I sleep. Invariably, I get a demo copy and find holes in the software.

This in itself isn't always enough to get a negative recommendation; I send the vendor my findings, and watch how quickly the issues are resolved. After evaluating the vendor's response to the problems, I can finally make a recommendation. Usually, we end up building whatever we needed in-house. The times that we don't, we usually wish we had.

Often, the vendor is the most surprised to find out that their magical software is full of holes. At least, they act surprised. Don't trust the marketing, don't trust the reviews in ad-supported-magazine weekly. If it's going to be used somewhere important, it's worth your time to look for yourself. If the vendor won't let you demo a copy, move on. If you haven't the time or the knowledge to evaluate it, I have both, but less money than I would prefer.

That's my rant for the day.

An Open Letter to the Internet

In my day-to-day activities, I often find security vulnerabilities in websites, software, and services.

When I find these issues, I make an effort to contact the affected parties to disclose the vulnerabilities responsibly. Unfortunately, many vendors and website owners do not supply contact information on their site, or make it needlessly difficult to contact.

Back when I built my first website in the mid-90s, it was common practice to supply a webmaster's email address at the bottom of every page, or on a 'contact' page. I don't know why this practice seems to have died out, but it needs to come back.

Website Owners: Please put an email address or at least a contact form on your website for users to contact you regarding technical issues, problems with your website, or other concerns. It is in your best interest to communicate with your audience.

Vendors: Because your service is more complicated than a simple exchange of information with your clients, you have a higher responsibility (believe it or not) to acknowledge and address found issues. Provide a communication channel for users and non-users alike. Allow them to contact you anonymously if they wish. Do not require that they register, have an account, or log in to your website in order to contact you. And please, when you are alerted to an issue, thank the party in question, publicly acknowledge the issue, and fix it. Do not shoot the messenger; fix the problem.

Once a good-faith attempt has been made to disclose the issue, many of us will then make it public. This is bad for you. Don't get caught with your pants down. If you communicate with those who are trying to help, most will wait until you have fixed the issue to make it public.

We are here to help, but we aren't necessarily here to help you.