FACEBOOK XSS ATTACKS

Discussion in 'Scripting' started by hackfreak, May 12, 2011.

  1. hackfreak

    hackfreak Guest

    Originaly posted in ma blog with image representation

    http://defendhackers.blogspot.com/2011/05/recent-facebook-xss-attacks-small..html


    A few weeks ago, three separate cross-site scripting (XSS)
    vulnerabilities on Facebook sites were uncovered within a period of
    about 10 days. At least two of these holes were used to launch viral
    links or attacks on users – and it’s clear that attacks against
    Facebook users are becoming increasingly sophisticated.



    The first issue came from a page on the mobile version of Facebook’s
    site. The interface was a prompt for posting stories to a user’s wall,
    and the parameter for the text of the prompt did not properly escape
    output. On March 28, a blogger identifying themselves as “Joy
    CrazyDaVinci” posted code that demonstrated how the vulnerability
    could be used to spread viral links:

    <iframe id=”CrazyDaVinci” style=”display:none;”
    src=”http://m.facebook.com/connect/prompt_feed.php?
    display=wap&user_message_prompt=’<script>window.onload=function()
    {document.forms[0].message.value=’Just visited http://y.ahoo.it/gajeBA
    Wow.. cool! nice page dude!!!‘;document.forms[0].submit();}</
    script>”></iframe>

    This bit of HTML would be included in a viral page. The code sets the
    content of the wall post to a message that includes a link to a viral
    page, then submits the prompt automatically. Anyone clicking the link
    would get the same code executed on their account. The viral page
    could be used for malware distribution or phishing attacks, but in
    most cases where I saw this trick used, the page simply loaded
    advertisements or “offer spam”.



    By the next day, several links were spreading virally and caught the
    attention of security researchers. Facebook moved quickly to patch the
    issue, and Crazy DaVinci issued an apology for the example code,
    explaining that versions of it had actually been circulating for
    several days prior and that the demonstration was intended to push
    Facebook for a fix.
    On April 3, another XSS problem came to light, this time with a
    Facebook “channel” page used for session management. Both another
    security researcher and I had previously looked at this interface and
    found it properly escaped, so it’s likely a code update mistakenly
    changed the page’s behavior. Facebook again patched the problem soon
    after news of it spread.
    I didn’t observe any viral exploitation of the second vulnerability in
    the wild, but after the first problem came to light, I noted that it
    was mostly used to submit a form already on the page for posting
    links. The payload made use of functionality within the vulnerable
    page, but XSS allows an attacker to do far more. I wondered when we
    might see a Facebook attack that made greater use of cross-site
    scripting’s potential.
    What a Difference a Space Makes
    I didn’t have to wait long. On April ,I got word via Twitter of a
    Facebook app that had live XSS, but the app had disappeared before I
    got to see it in action. At first, I thought this was yet another case
    of XSS within the context of a Facebook app. But I soon found other
    version of the app which were still online, and I quickly realized
    this was actually an XSS problem with the Facebook Platform. Also, the
    XSS payload being used did much more than submit a form.
    The attack used FBML-based Facebook apps, which render in the context
    of an apps.facebook.com page. Normally, Facebook filters code to
    prevent any scripts from directly modifying the page’s DOM, but the
    XSS problem gave attackers a bypass. When a user visited the app page,
    they would see what appeared to be a fairly benign page with a popular
    video.

    Unlike many Facebook page scams, the promised video actually works –
    if you click play, the video will load and nothing unusual seems to
    happen. But as the code screenshot below reveals, that click does much
    more than load the video.





    When the page first loads, the “video” is actually just an image
    placeholder with a link. Part of the href parameter for that link is
    shown above. Note the space after the opening quotation mark – that’s
    where the XSS comes in. Normally, Facebook would block a link to a
    javascript: URL. Adding the space worked around Facebook’s filters,
    but the browser would still execute the rest of parameter.


    According to Facebook, it turned out that some older code was using
    PHP’s built-in parse_url function to determine allowable URLs. For
    example, while parse_url(“javascript:alert(1)”) yields a scheme of
    “javascript” and a path of “alert(1)”, adding whitespace gives a
    different result: parse_url(” javascript:alert(1)”) does not return a
    scheme and has a path of “javascript:alert(1)”. Other PHP developers
    should take note of the difference if parse_url is being used in
    security-related code.
    A More Advanced Attack
    Clicking the link executed an inline script that in turn added a
    script element to the page. This loaded more code from a remote
    address and included several parameters in the GET request. The
    parameters set variables within the remote code that specified what
    video to load, what URLs to use for viral posts, and so on. Multiple
    Facebook apps and domains were used for the viral links, but the main
    script always came from the same host. This helped the attack persist,
    since blocking one site would not stop it and the central code was
    loaded dynamically.
    The remote code handled actually loading the video, but also included
    a number of functions which make use of having script access in a
    facebook.com context. The script would set the user as attending spam
    events, invite friends to those events, “like” a viral link, and even
    send IMs to friends using Facebook Chat.
    When I came across the attack, one block of code had been commented
    out, but one blogger discovered a version of the attack a few days
    prior and saw it in action. This part loaded a fake login form which
    actually sent the entered username and password to a log interface on
    the attacker’s server. (Remember, this phishing form would appear in
    the context of a page with typical Facebook chrome.) Since the attack
    page would load even if a user was not logged in to Facebook, this
    could have also been a way to make sure a session was available before
    launching the other functions.
    Fake videos and viral links are nothing new on Facebook, but most of
    these scams tend to be fairly simple. In fact, it’s not hard to find
    forums where people offer boilerplate code for launching such schemes
    – much like the first XSS worm above which simply submitted a form.
    But the April XSS attack involved multiple domains, multiple user
    accounts, and multiple methods for spreading and hijacking user
    accounts. And it still only scratched the surface of what’s possible
    with an XSS vulnerability. I expect we’ll see more XSS-based attacks
    and more powerful payloads in the future.
    Postscript on Real-Time Research
    I came across the April attack late one afternoon as I was preparing
    to leave work… so I could present on XSS at a local OWASP meeting!
    Those following me on Twitter saw a somewhat frantic stream of tweets
    as I tried to find live examples of the attack and sorted through the
    code while closely watching the clock and wrapping up last-minute
    presentation details. Earlier this week, I did some searching to
    review information for this post, and I came across this article from
    eWEEK: “Facebook Bully Video Actually an XSS Exploit“.



    I was a bit surprised by it, as I hadn’t known about it before and saw
    that it quoted me. I then realized it was quoting my tweets! I then
    read that I had “confirmed to eWEEK on Twitter” one aspect of the
    story. At first I was confused, but then remembered that during my
    flood of tweeting, another user had sent an @ reply asking about the
    very detail the story talked about. Checking that tweet again, I found
    out the question had come from the article’s author.
    I relate all this not because any of it bothered me, simply because
    (1) I found it somewhat fascinating that a few quick Twitter updates
    could become the primary source for a news article and

    (2) I was humbled to realize that a few quick Twitter updates could
    become the primary source for a news article! While it’s great that a
    story can spread so fast, it was certainly gave me a reminder to be
    careful when discussing topics of interest on a public forum.


    But I’m glad I can do my part in helping raise awareness of online
    dangers, particular the implications of XSS.
     
    hackfreak, May 12, 2011
    #1
    1. Advertisements

  2. David H. Lipman, May 13, 2011
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.