Cuberk

Hello World ❤️,

Facebook is the largest social networking site in the world and one of the most widely used. I have always been interested in testing the security of Facebook. During the sub domain enumeration, I’ve got a sub domain which is “https://m-nexus.thefacebook.com/". It redirects me to “https://m-nexus.thefacebook.com/servlet/mstrWebAdmin" observe below screenshot:

I quickly Google keyword mstrWebAdmin and I observed that this is the Business Intelligence Portal that is built on MicroStrategy’s tools:

I confirmed it with a blog:

From the official configuration document for MicroStrategy, I found there are two endpoints which are publicly accessible:

Going further in official configuration document for MicroStrategy, I found that by default, HTTP basic authentication was enabled on Business Intelligence Portal (URL: “https://m-nexus.thefacebook.com/servlet/mstrWeb"), then I observed that “https://m-nexus.thefacebook.com/servlet/taskProc" does not require authentication.

It takes value from “taskId” parameter to perform some custom data collection and content generation. By enumerating pre-built tasks (Using Intruder), I found that each pre-built task checks for a valid authentication session parameter, but “shortURL” task which processes short URL and does not check for a valid authentication session. An attacker can use this observation to access this service without any authentication.

I started fuzzing on all the parameters mentioned in official document but I didn’t find anything. 😔 Every time it gives me an error message “The source URL is not valid” with status code 500. Then I thought, let’s download the hosted web application and start the source code review. I downloaded an application package of more than 400 MB. There were several scripts and jar files in the package.

Simply I decompiled that jar files using jd-gui tool and started reviewing code. My main target was shortURL task which processes short URL and does not check for a valid authentication session. Finally I found that Java class from a jar file.

Then I came to know why it gives the same error message every time, “srcURL” parameter of the “shortURL” task only takes the URL that is created with “https://tinyurl.com/" for importing data or reading data from that URL. Observe the following code snippet:

Now what? — Let’s Exploit! 💥

Steps to replicate (What I sent to Facebook):
1. Open Burp suite proxy tool and go to the Burp menu and select “Burp Collaborator client”. Generate a Collaborator payload and copy this to the clipboard.

2. Open “https://tinyurl.com/" from web browser, enter collaborator payload and create its tiny URL. Copy that created tiny URL.

3. Insert copied “tiny URL” in “srcURL” parameter of following URL and opens it in browser:
https://m-nexus.thefacebook.com/servlet/taskProc?taskId=shortURL&taskEnv=xml&taskContentType=json&srcURL={YOUR_TINY_URL_HERE}

4. Observe that Burp Collaborator hits immediately, it shows IP address “199.201.64.1” from where request was received.

5. IP — 199.201.64.1 belongs to Facebook, confirmed with whois records.

6. To test internal SSRF: create tiny URL of invalid internal IP address (eg. 123.10.123.10), insert it in “srcURL” parameter and observe there is no response from server.

7. Again create tiny URL of valid internal IP address (127.0.0.1:8080), insert it in “srcURL” parameter and observe it ask for HTTP basic authentication.

With this observation we can enumerate the internal infrastructure behind a firewalled environment. I quickly reported my findings to Facebook, but this was rejected as they didn’t believe it to be a security vulnerability. Observe below response:

So what’s the next? — Digging Deeper ⛏️

I had to come up with the evidence. I tried to read the internal information using URL schemas such as file://, dict://, ftp://, gopher:// etc. Also tried to fetch meta-data of cloud instances but no success.

After some time I finally came up with some impactful examples. Here are some real-time attack scenarios which I sent to Facebook along with the steps to reproduce:

1. Reflected Cross Site Scripting (XSS):

2. Phishing attack with the help of SSRF:

STEP 1. Create and host a phishing page of Facebook login that steal victims Facebook login credentials which look like a legitimate login portal.

STEP 2. Open “https://tinyurl.com/" from web browser, create a tiny URL of hosted phishing page i.e. “http://ahmedabadexpress.co.in/fb/login/fb.html". Copy that created tiny URL.

STEP 3. Insert copied “tiny URL” in “srcURL” parameter of following URL and send to victim:
https://m-nexus.thefacebook.com/servlet/taskProc?taskId=shortURL&taskEnv=xml&taskContentType=json&srcURL={YOUR_TINY_URL_HERE}

As soon as victim enters his/her username and password on this page it gets saved to the “http://ahmedabadexpress.co.in/fb/login/usernames.txt" file. And victim gets redirected to real Facebook login page. You can see that host name is the string “m-nexus.thefacebook.com” so it looks legitimate.

STEP 4. Navigate to “http://ahmedabadexpress.co.in/fb/login/usernames.txt" URL and observe stolen credentials.

An attacker might also use this vulnerability to redirect users to other malicious web page that are used for serve malware and similar attacks.

3. Fingerprint internal (non-Internet exposed) network aware services:

I was able to scan the internal network behind the firewall. I used burp suite intruder to send more than 10000 requests to find an open port on the server or any application running on that port.

After scanning, I finally found an application running on port 10303 named as “LightRay”.

Before I further investigate on this, Facebook Security Team resolved that vulnerability.

And finally:

… is this the end? — No, the story has just begun 😉

Now I knew that the MicroStrategy Web SDK was hosted on Facebook’s production server. The MicroStrategy Web SDK is written in the Java programming language and I love finding bugs in the java code. So, I decompiled each jar file of the SDK using the JD Decompiler tool and started reviewing the code. I’ve also hosted the SDK on my server, so that if I find anything suspicious in the code, I can check it there. 👨‍💻

After 26 days of diligence and grinding, I finally got an interesting observation. 💡

In “com.microstrategy.web.app.task.WikiScrapperTask” class, I observed that the string “str1” is initialized by user supplied input that we are sending as parameter. It will check if provided string starts with http:// (or https://) or not, if it is then it will call the function “webScrapper”.

“webScrapper” function will internally send a GET request to provided URL using JSOUP. It used to fetch and parse an HTML page.

BOOM!! Again it was SSRF.. 🕺

Unfortunately, this time it was a blind SSRF so I cannot prove that it allows the submission of internal GET requests. However, from the source code of the MicroStrategy Web SDK (which is deployed on the domain m-nexus.thefacebook.com) I confirmed that it was an internal SSRF.

From this observation we cannot enumerate the internal infrastructure behind a firewalled environment or are not able to leak any sensitive information. I knew if I report this to Facebook they will reject it because there is no impact of this vulnerability. 😔

So what’s the next? — I was blank at this moment!

I left it and started looking for a new vulnerability in the main Facebook domain (facebook.com)