How to get Facebook stored XSS

[alien]

This guy recently found a Stored XSS on Facebook worth 3500USD dollars. This is his story how he did it:

I was actually working on finding flaws on Dropbox to begin with. I noticed that when using their web interface there were some restrictions on what filenames that were allowed. If you tried to rename a file to for example:

'"><img src=x onerror=alert(document.domain)>.txt

it was not possible. You got this error:

The following character are not allowed: \/:?*<>"|

But, if you instead, connected a local directory, created a file there and synced it, you got it inside Dropbox without any problems. Using this method I was able to find two issues with their notification messages showing unescaped filenames. I reported these issues to Dropbox, they patched it really fast and I was placed on their Special Thanks page for the responsible disclosure.

It didn’t end here. As I was testing out this stuff on Dropbox, I also tried to figure out how this issue could be connected with other services. I noticed their Facebook-connection and got curious on how it worked. It turned out that they had a pretty nice function going on there:

“Dropbox has teamed up with Facebook so that you can do cool things like add files from Dropbox to your Facebook groups or send shared folder invitations to your Facebook friends.”

Nice! I created a group, and found the connection using the “Add File” icon on the Group wall:

I selected the file that I synced to Dropbox, it was called:

'"><img src=x onerror=alert(document.domain)>.txt

and shared it. Nothing awesome happened except the file being shared.

But then, I clicked the Share-link on the entry.

BAM! The title of the entry was not escaped correctly and I was able to get the Stored XSS triggered. By using the files in my Dropbox I could inject script code that was executed on Facebook.com.

I reported this to Facebook directly using their Whitehat Vulnerability Reporting system, told them it was an urgent issue and how I managed to get it executed. The issue was at that time only affecting the Share-popup inside the Group page and could only be triggered by user interaction, serious or not, it was clearly not affecting all users on Facebook.

At the same time I started looking on the URL of this Share-popup:

https://www.facebook.com/ajax/sharer/?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first

This URL did not work if you tried it stand-alone. That was good, the XSS issue looked like it could only be triggered by user interaction. But then I started googling and found that you were able to create a Share-URL by using this format:

https://www.facebook.com/sharer/sharer.php?

So I changed my URL to that format:

https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first

BAM again! If you were logged in into Facebook, the code was executed as soon as you visited the link. Bad. Really bad.

I emailed Facebook again, explaining that you could actually trigger the XSS by only visiting a link.

I was also trying out if I could get other services to behave in the same way. Dropbox and Facebook had this special connection, so I was curious if this issue was isolated or if I could reproduce it by using another service.

Went to Pinterest. Created a Pin named:

'"><img src=x onerror=alert(document.domain)>

and shared it on Facebook using my test account. I pressed the Share button on it.

I was amazed – it had the same issue.

Facebook replied to me, asking me how I was able to place the files on Dropbox with that filename. I explained how this was done and also told them that the service that you shared from didn’t matter, it was a general issue with the escaping that created a vulnerable vector on the Share-page.

They responded and said that it was indeed the same issue and they should look into it ASAP.

In the meantime, I tried the link on different devices. My iPhone could not get the XSS executed. As soon as I visited the page, I was redirected to https://m.facebook.com and that page did not have the same issue. But I also realized that you could force Facebook to skip the redirect by using a parameter called m2w, so if I appended that to the URL:

https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first&m2w

I was able to trigger the URL on both mobile devices and on desktop. Another email to Facebook.

One day after that I noticed that the POC-link did not work anymore, it was finally patched. I told them I could not reproduce it anymore and it looked like it was fixed.

One day later I got this email:

Source: Detectify Blog – How I got a $3,500 USD Facebook Bug Bounty

[eusimplu]

3,500 EURO, wtf

[Jimmy]

Trebuie sa ai rabdare mare pana gasesti unu...eu unu nu am avut norocul.

Nici dl. gogle nu mai vrea sa dea de o ciorba

[alien]

Si un gram de noroc

LE: dar oricum vulnerabilitatea este gasita recent, ceea ce demonstreaza ca inca se poate

Date range:

Initial report and the POC-link executing the XSS just by visiting: Dec 22
Explained the Dropbox-syncing and extended the scope regarding services and devices: Dec 27
Vulnerability fixed: Dec 28
Received message about the Bug Bounty: Dec 29

Edited January 9, 2013 by alien

[florin_darck]

Daca pui in search-ul de la google acel vector o sa vezi ca aceasta metoda a mai fost incercata pe mai multe site-uri mari

[abraxyss]

Facebook e incredibil de vulnerabil . Cam atat am dedus din ultimele 2 saptamani cand am vazut plin de flawuri

ba in /hacked ba in fb.com ba un xsrf care iti permitea sa trimiti mesaj cuiva sub un alt user facebook [ask em=))]

Deci mda ... fuck fb