FACEBOOK XSSS ATTACKS

H

hackfreak

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.
 
R

RayLopez99

According to Facebook, it turned out that some older code was using
PHP’s built-in parse_url function to determine allowable URLs.

So this argues that Linux open source is the culprit.

RL
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Top