Background

Facebook has a policy that you can change a group's name only once every 28 days if your group is big. This is to prevent abuse and maintain consistency. While joking about this on a post on that group, the conversation quickly turned to bug hunting and eventually triggering this.

My initial instinct to test this actually came from the outdated UI they had, which sort of indicated this thing hadn't been touched in a while. Immediately I headed to Charles Proxy to capture and modify the request this was sending upon changing the name.

I copied the curl command of the request, and kept replaying it again with different group names.

curl 'https://www.facebook.com/groups/<GROUP_ID>/edit/' \
--data-binary 'jazoest=<REDACTED>fb_dtsg=AQGfx9WwthQl&__a=1&group_purpose=social_learning_landing_tab&group_currency=USD&description=&topics=&name=testgroup0&group_members=&admin_post_approval=1&stories_post_permissions=1&nctr[_mod]=pagelet_group_edit&__user=<REDACTED>' \
--compressed

And to my surprise, the group name changed! A bunch of people on that group saw that happen which sparked quite a lot of laughter and a little bit of shock. To be fair, this bug isn't big - it's not an account takeover.

However, this gets even more interesting....

I tried sending <br /> as part of the name parameter. Yes, actual HTML tags as the name. And to my surprise, it seemed to not have parsed the HTML quotes but rather break something on the backend! So much so, that once you name a group <br /> without sanitization (that the frontend does), you can make a facebook group INACCESSIBLE and UNFIXABLE - even through the exploit!

Again, always sanitize everything on the backend – DO NOT trust your requests!

Anyway, I reported all of this to Facebook Security, and was awarded $500!

Timeline:

Finding the Vulnerability

Let’s start with the challenge now. This was the screen I was presented with.

Entering something random got us this.

This takes us to a 404 page, but now we have a parameter f in the field which probably takes in a file. Let's try /etc/passwd

http://mindreader.web.ctfcompetition.com/f=/etc/passwd

Wow, that was a little too easy, but we're quite a bit away from it. The flag was not in flag.txt, ../flag or flag.

But hold on... if I can read any file, it means I can read the source code too 😏 I tried a few guesses: “main.py”, “app.py”, “server.py” and voila, main.py was actually a file.

A flask webserver that reads the flag from OS environment. Also a regex that filters out the words proc, random, stdout and stderr so you can't read those. /proc/self/environ is typically the file that shows the environment variables but due to the regex we can't access that.

The challenge has now boiled down to finding a way to access that file by bypassing the regex. Let's see if there are any Symbolic Links that map to that. Tried to check this locally on my Mac and eventually, I did notice that /dev/fd links to /proc/self/fd. This means I could try /dev/fd/../environ to access /proc/self/environ.

And boom! Here's our flag.
http://mindreader.web.ctfcompetition.com/?f=/dev/fd/../environ

FLAG=CTF{ee02d9243ed6dfcf83b8d520af8502e1}

Typically, I just browse through the apps on my phone and start looking for my next target everytime I bug hunt. This time I thought it should be something different than the Facebook family of apps.

Instead of reverse engineering their app, I took different approach this time. I decided to take a look at their corp servers instead. I recently came across shodan.io which is a database of connected devices.

That's cool and all, but one of the coolest part about Shodan is that they also let you apply pretty specific filters. These filters even work to search for metadata within SSL certificates. I used this to filter by "Common Name" as *.shazam.com and shazam.com and happened to find a couple servers on their network.

My first instinct was to test these for heartbleed - one of the most trending vulnerabilities from 2014. To my surprise, they turned to be vulnerable to heartbleed - even in 2017!

I sent out this report to Shazam and within a couple days got a response from the team with the bug bounty notification.

Incredibly grateful to Shazam for this bug bounty, even though they didn't have an established bounty program at that time (this is all before the Apple acquisition).

Timeline:

Initial Report – Jan 23, 2017

Initial response from Shazam – Jan 24, 2017

Bounty Awarded – Jan 26, 2017