Facebook vulnerable to critical XSS, could lead to malware attacks

Facebook vulnerable to critical XSS, could lead to malware attacks

Summary: Facebook, the second most popular social networking site in the U.S according to Nielsen, is currently vulnerable to a critical XSS, allowing the injection and execution of malicious scripts within the popular site.


Facebook, the second most popular social networking site in the U.S according to Nielsen, is currently vulnerable to a critical XSS, allowing the injection and execution of malicious scripts within the popular site. As you can seen in the attached screenshot, the harmless injected scripts in the demonstration successfully load, making it possible to abuse the trust relationship between Facebook and its users, in order to use the site as an infection vector. What are the implications of the this vulnerability, and has this infection vector already been abused in the past?

Facebook XSS vulnerability

The most recent related incidents serving malware and live exploit URLs, due to vulnerable web applications, successfully targeted a great number of high profile targets, introducing Zlob trojans in the form of fake video codecs, and was initially traced back to infrastructure provided by the Russian Business Network. Consequently, the potential for abusing the XSS within Facebook is fully realistic. It's also important to emphasize on another perspective, what if there wasn't a working XSS within Facebook? How would the malicious parties adapt in order to achieve their objectives, and harness the traffic of a reputable high-trafficked site if there are no vulnerabilities within, that they could exploit? They'll simply emphasize on the long tail of SQL injection attacks, and target everyone, everyone, so that the traffic generated from the hundreds of thousands affected web sites, could at least theoretically match the traffic that could have been received from a major high-profile site.

The security folks at Facebook have been notified, live fix is pending.

UPDATE: The vulnerability has been fixed at 15:07 PM.

Topics: Social Enterprise, Malware

Dancho Danchev

About Dancho Danchev

Dancho Danchev is an independent security consultant and cyber threats analyst, with extensive experience in open source intelligence gathering, malware and cybercrime incident response.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Computer science at Cal Tech should be able to fix it

    Let's use our country's high minds to solve these problems that the software writers,manufacturers and Government can't.
  • What I think

    that you, Danchev, and others are completely misfocused adolescents, to distribute this sort of information _before_ the fix has been achieved.

    What is the excuse this time?

    I find a xss bug on your site. I tell the world. Then I tell you. Do you, or your site readers, like it?

    I would like to respect the work of the writers here. This kind of act makes a slight problem for that.

    I hope you think, and change the behaviour.

    Narr vi
    Narr vi
    • Re: What I think


      Thank you for the point, there's definitely a lot to explain here. First of all, if you go through milw0rm.com's vulnerabilities, and actually know the researchers who believe in responsible disclosure, you'll realize that adolescents are on the verge of extinction. Moreover, knowledge comes with responsibility, and age has nothing to do with this, but experience and realizing the impact of your actions aiming to serve the community as much as possible.

      As for this particular vulnerability, what I'm sure you're not aware of is the degree to which the community networks between itself, and what is commonly referred to as responsible disclosure. I keep in touch with a senior engineer at Facebook which was notified on the flaw once I came across it, just like another time regarding flaw that never even made it in the mainstream press as a news article.

      I would also like to live in the utopia that major and high profile sites are secure, given they have a HackerSafe logo next to them, or SSL encrypted logins, trouble is, reality is harsh enough not to anticipate it. The benefits provided by their complex web applications, are proportional with the vulnerabilities within. xssed.com is a public place where each and every visionary company should take a look from time time, in respect to XSS vulnerabilities only, if it is to keep up to date with the flaws already found by others. Just for the record, the window of opportunity for abuse once a vulnerability gets reported at such a public place is shorter, than it would have been if they didn't reported it, kept it private and abused it actively.

      Here are some related articles by the Register, and Informationweek, disclosing the flaw, and I really think the other people reporting this are not that much of adolescents :



      The excuse for disclosing such flaws lies in being objective, and possessing the necessary situational awareness to do quality threat analysis.

      And just for the record - despite that many other critical XSS vulnerabilities have already been reported to the affected parties by those who found them, over an year ago, they still remain exploitable, which speaks of itself. Would you like having your Ebanking provider's site vulnerable to XSS so the next time you receive a phishing email it will be actually loading from your Ebanking provider's site? I doubt so.

      Thanks and I hope that I've provided you with sufficient explanation on why keeping it realistic better serves the community if you're to consider the big picture.

      • realism and community

        Dancho, thank you for your polite and detailed reply. I was young (and advanced) once also, and therefore would clarify that I meant 'adolescent' as a mode, only. It indeed can strike at most ages ;).

        I would also say to you that I am not looking for a utopia, and surely not one where we just trust what we find on sites. It is one service you fellows have been giving, to alert the very high level of danger out there today, and at ordinary places.

        One thing that does not help this is the state of anti-driveby software. I tried LinkScanner Pro for a while, but it conflicts to the point of blue-screens with Norton NIS 2008. I had a lot of trouble with carelessness and more serious things with HauteSecure, if I would like to like that, and I particularly don't like Haute's attitude about user identified tag-backs for all your connections to sites. A lot of consciousness to grow there if they are to get anywhere.

        On this reporting at or before fix time. I think your words say to me that you are in a competitive journalistic or security logger community, where you feel compelled to report because someone else does or is about to.

        The inner key to at least this particular facebook situation is that apparently the fix was about to go in at about the same time you reported. I judge that from the patch notification, and think that is what you were probably talking over with your Facebook engineer. Well, all right, for this case, and I am glad to hear you were talking to him.

        I also notice that 'Mox' has posted 2 more Facebook xss vulnerabilities since. Where does it stop? Why is the reporting public, until the victim site has a chance to respond?

        That is the question of judgement here, of having good judgement. If it is my bank that has the discovery, to use your example, I and they would doubtless wish this to remain non-public until it is fixed. That is the time for the investigator to get the credit they are evidently quite hungry for. That is the responsible time.

        There is a much longer interval to judge by, in seeing the victim site themselves being irresponsible. I would think it essential to make the kind of contact you did with Facebook early, and follow on to see the progress. If the victim sits on it, they can know journalism will eventually expose that. The good face of the same relationship is that journalism should paint them in a good light so long as they respond quickly.

        A case somewhere in the middle might be Apple and Quicktime. I use it and need it, and also need my machine to be very clean. I don't buy the anti-fanboy hype about QT being some kind of poor design; rather, it is a type of service that is particularly vulnerable, handling so many protocols, and a bit old by the standards of coders who have finally woken up to the kinds of things that were done in quality software 2 decades ago, supported by the software advances like object technology which meant you could write once no-overflow buffers and use them everywhere.

        I am glad for attention on Quicktime, to get its vulnerabilities closed, but I am very unhappy when a notice goes out that guess what, there's another Zero-day on it. I finally have to set up my machine carefully (NoScript for Firefox, and plain ban on IE for the times I have to use it) so that Quicktime is there, but will not be exercisable unless I say so, each time. Most people won't do this, and will either deinstall QT or bluff the situation out. It is a very hard cut to Apple if they remove Quicktime, because then Itunes as well refuses to work. So there is a great deal of responsibility in what the security press publishes - both for the business of companies who are bringing our future, and for security itself when a wider community of bandits are told where to look to cause maximum difficulty.

        Dancho, I am sure you see the scope of balances and responsibilities laid out here. I appreciate it's not the easiest, and I think the best tactic of all is that call to the victim - that can help calibrate.

        In most cases, I feel the fair and effective path, which also gives an unmitigated kudos to whomever digs up the fault - since the are then not having to be ashamed and reviled for shouting before its time - is to publish after the fix is in.

        With regards,
        Clive (Narr vi)
        Narr vi