Slashdot Mirror


McAfee Sites Vulnerable To XSS Attack

An anonymous reader notes that this weekend, ReadWriteWeb discovered a security hole on several McAfee sites, which lets any attacker piggyback on the company's reputation and brand in order to distribute malware, Trojans, or anything else. The submitter adds an ironic coda to McAfee's epic fail: "In the 'how to HTML Injection' section, the author provided the four steps needed to execute a simple, no-brainer injection, but unfortunately, exposed a hole in NY Times website when they republished the article. While the author changed the offending text to an image, the Times is still using the original story which redirects directly to ReadWriteWeb [via XSS]." From the RWW post: "During tests this weekend, we discovered the company who claims to 'keep you safe from identity theft, credit card fraud...' has several cross-site scripting vulnerabilities and provides the bad guys with a brilliant — albeit ironic — launching pad from which to unleash their attacks."

19 of 84 comments (clear)

  1. Epic fail by xming · · Score: 2, Funny

    Horribly.

    1. Re:Epic fail by Lobster+Quadrille · · Score: 2, Informative

      A much more serious issue- in the control panel for their web application scanning service was published yesterday.

      http://skeptikal.org/2009/05/epic-failure-from-mcafee.html

      This XSS is cool, but it's not news. I've been documenting McAfee web vulnerabilities for a year now. Rest assured, there are many more, some of which will be published later this week.

      --
      "The cup is in turn designed for holding hot or cold liquids, and has an open rim and closed base." --US Patent #5425497
  2. Hmm. by Phroggy · · Score: 2, Interesting

    Yikes. I wonder if any of my code has that vulnerability. I don't think so. I try to make sure I run all user-submitted text through something to escape those kinds of characters before sending it back to the browser as HTML, but it's possible I could have missed something somewhere. The only time I don't do this is if the user-submitted input is first passed through an input validator that should reject anything containing dangerous characters (for example, a valid e-mail address cannot contain HTML tags, so if I reject all but a valid e-mail address, then I don't need to sanitize the e-mail address). But how can I be sure I haven't missed anything somewhere?

    The only way I could be sure is if I did a thorough audit of all my web site code, and I really don't want to go through that hassle. It's probably fine. I've never had an XSS attack used successfully against any site I've built. Certainly not one that was using SSL. So let's just assume that this trend will continue!

    Right?

    --
    $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
    $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    1. Re:Hmm. by 6Yankee · · Score: 4, Insightful

      The only time I don't do this is if the user-submitted input is first passed through an input validator that should reject anything containing dangerous characters (for example, a valid e-mail address cannot contain HTML tags, so if I reject all but a valid e-mail address, then I don't need to sanitize the e-mail address). But how can I be sure I haven't missed anything somewhere?

      Ouch. I can disable the client-side validation entirely. I can also write my own form and send you anything I like.

      Sanitize everything.

    2. Re:Hmm. by Swizec · · Score: 2, Insightful

      For the safety of your users, I do hope the sanitization happens on the server-side otherwise ... yikes. Then again, some clients simply don't pay enough for sanitization and I just dump anything someonen posts right back to the page. Easier spending an hour every two months deleting "spam" than spending time making sure everything gets properly sanitized.

      Yes I'm a lazy coder I know, but fuck it, you get what you pay for.

    3. Re:Hmm. by growse · · Score: 3, Interesting

      I find it easiest to not validate anything on input, because I don't know what my output is necessarily going to be - could be HTML, could be PDF (for example). If I am outputting to non-HTML I don't want to wade through HTML-encoded soup to get something sensible back out.

      If I'm outputting to web, I then always validate / encode *all* content, usually using something like the Microsoft AntiXSS library. This stops user-inputted markup from being rendered, but it also stops markup that's been maliciously inserted into your database from being remembered. Remember the SQL injection attack that appended a javascript snippet to every field it could find? It was looking to do an XSS attack.

      If you need to chuck out user-generated markup, make sure you contstruct your whitelist and ruleset very carefully.

      --
      There is nothing interesting going on at my blog
    4. Re:Hmm. by AlXtreme · · Score: 4, Insightful

      Yes I'm a lazy coder I know, but fuck it, you get what you pay for.

      Do it right, or don't do it at all.

      I'm all for cutting corners when dealing with stingy clients (which tend not to be clients for long) so I get your way of thinking, but basic security shouldn't be one of the corners to cut. In the end it will be worthwhile to simply add a bit of code to sanitize user input to avoid all the hassle you'll get in the long run.

      If you are spending an hour (of your own or billed) every two months for cleaning up crap, next time please spend two hours and add some validation. Keep on billing said client for spam cleanups for all I care.

      Every time a viewer sees spam it makes your work seem poor. Even a lazy coder knows when it will cost him more work in the long run.

      --
      This sig is intentionally left blank
    5. Re:Hmm. by galego · · Score: 4, Informative

      Hope you're not trying to "enumerate the bad" (i.e looking at $foo ~= /<script/i in the input ... or even '<'). There are lots of ways to escape such validators. A great resource on some is here: http://ha.ckers.org/xss.html I say, unescape everything back to the browser (even email addresses). OWASP has a good resource: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

      --

      Que Deus te de em dobro o que me desejas

      [May God give you double that which you wish for me]

  3. Eat their own dog food by agristin · · Score: 2, Insightful

    Either they don't use McAfee secure ( http://www.mcafeesecure.com/us/ Probably the right website, who knows really ), or their own dog food is garbage.

    Either way it is bad gaffe. XSS is pretty well known in security circles. And this mistake is a relatively simple one (output validation or output filtering? please. After you read the linked article, you'll be even more sad they didn't catch this.

  4. Syndicated version on NYT site by Anonymous Coward · · Score: 5, Informative

    http://www.nytimes.com/external/readwriteweb/2009/05/04/04readwriteweb-mcafee-enabling-malware-distribution-and-fr-12208.html

    executes the code and redirects to readwriteweb.com

  5. Distribute? by Haiyadragon · · Score: 2, Insightful

    Sure, I can use this to inject code into the html that is then processed by my webbrowser. But how I can use this type of XSS to distribute anything? The worst thing I can do is still only happening on my pc.

    1. Re:Distribute? by Hurricane78 · · Score: 4, Informative

      Well, it injects code that can change the download link to a trojan that wraps the original thing. In your webbrowser.

      In sites with logins and other user-private data, well, let me take Slashdot as an example.
      Imagine someone got some evil code into the site, that your browser would load and execute.
      That code could quickly put the entire page into a frameset, with the outside being the control channel.
      Then, while you were reading, it would load your unprotected profile in the background, and change your sig to that same evil code (or a link to it). So everybody else would get it too.
      Then it would do a complete scan of your internal network, possibly detecting your router, and its ports. (All possible with JavaScript. Been there, seen it.)
      You could click on a link in /., and the frameset would survive. You could even keep that tab open all day long, effectively making you a zombie host.
      In the process, it would accept arbitrary commands from the controlling system. If you happen to go on the site or your router, it could for example try things in there too, like set an external control IP to the controlling system, and gain full access to your own network. (Unlikely, but I've seen it happening.)

      And all this is just the tip of the iceberg.

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
  6. Sure, but the camel was already broken... by wild_quinine · · Score: 4, Interesting
    I found an old USB stick the other day with McAfee's superdat (definitions and engine update) file circa 2006. That's only two and a half years ago. It was a real wake-up call. The superdat was just over 6mb in size.

    These days you can't fit the application and latest superdat onto a 128mb stick - and when I tell you that the application in only 20mb in size, you'll realise what a change this is. Their updates been spiralling out of control for two years. Now, some may argue that there's a lot more malware out there now, and I won't disagree. But I will say this: McAfee hasn't been getting significantly better as far as I can tell, and none of the other major players seem to have experienced this definitions file explosion, ergo McAfee is doing something wrong.

    Furthermore, their version 8 enterprise has one of the worst failures I've ever seen for a virus scanner, which is hilariously related to the above. The application no longer knows how to handle its own virus defintions catalog: I'm not sure whether that's the sheer size, or the number of entries, but either way the update fails because of it. But get this: it says that the update has succeeded!

    Can you imagine a more epic fail for a virus scanner than saying it's up to date, but being wrong? Neither could I, till I read the news today.

    So long McAfee, I hope you enjoyed your time with the big players.

    1. Re:Sure, but the camel was already broken... by drinkypoo · · Score: 2, Interesting

      Furthermore, their version 8 enterprise has one of the worst failures I've ever seen for a virus scanner, which is hilariously related to the above. The application no longer knows how to handle its own virus defintions catalog: I'm not sure whether that's the sheer size, or the number of entries, but either way the update fails because of it. But get this: it says that the update has succeeded!

      They were just trying to catch up to Norton/Symantec Antivirus, which has had this feature since version 7 (I ran into it ENDLESSLY at Yuba College.) The fix was to reinstall windows (ever tried manually removing norton? heh heh) and run virus def updates manually. The problem remained at least until version 9, which is what they were running when I quit.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  7. Re:Antivirus on Windows by daveime · · Score: 4, Interesting

    It's a web page exploit, wtf does it have to do with Windows ?

    Redirects work in all browsers, and while I can't speak for Firefox, at least MSIE 8 will warn you of a possible cross domain phishing attempt.

    McAfee also make products for Linux and Apple you know.

    Just another anti-ms troll who can't wait to make his mark on /.

    Winslows is teh suxxors !!!

  8. Re:How do we thow... by daveime · · Score: 2, Funny

    Speaking of viruses, that's a nasty cold you've got there.

    How do we thow

  9. Wait one minute. by Lifyre · · Score: 3, Insightful

    Is it just me or was anyone else surprised that McAfee had any reputation or brand left to piggyback upon? I though McAfee was generally worse than most viruses...

    --
    I'll meet you at the intersection of "Should be" and "Reality"
  10. Re:Antivirus on Windows by Yvanhoe · · Score: 3, Insightful

    You have no reason to go to MacAfee pages if you don't use their products or plan to do so. You have no reason to use them if you are not on windows.

    --
    The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
  11. Re:Great idea. by Dark_Gravity · · Score: 2

    NoScript also kinda prevents nearly everything on the web from working as intended, and is not a solution. Please shut up about how much you think it rocks.

    You just aren't using it correctly.