Hello, World! ❤️
Welcome to my another blog post. I hope you all are doing well and safe. This post is about the reflected cross-site scripting (rXSS) vulnerabilities I found on Facebook. I suggest you read my previous article before reading this one, which is how I found several SSRFs on Facebook server where a vulnerable third-party business intelligence portal (MicroStrategy Web SDK) was deployed. If you read that article first, then, it will be easier to understand.
This post is about some complex rXSS I found on Facebook that was a little difficult to detect and exploit. As already discussed in my previous article, the MicroStrategy Web SDK was hosted on Facebook’s production server. I was looking for file upload functionality, so that I could upload a web shell to the server.
By enumerating pre-built tasks, I found that the uploadFile task was registered and accessible.
There was not much documentation available on the MicroStrategy website about this task. So I decided to manually review the source code for this task. I had already downloaded the MicroStrategy Web SDK on my local system, I started looking for the Java class for the uploadFile task.
I decompiled each jar file of the SDK using the jd-gui tool, and started looking for “com.microstrategy.web.tasks.UploadFileTask” class. I found, the WebTasks.jar file had a class “com.microstrategy.web.tasks.UploadFileTask”.
I observed that, it supports file upload and its processing functionality. First it will check the fileFieldName URL parameter which should match with the actual filename (which we want to upload). It will then check the file extension, if it happened to be an Excel file (xlsx and xls) it will call the function parseUploadedExcelFile and for other files it will process the file using the parseUploadedFile function.
parseUploadedExcelFile function first checks for a valid session, so I was unable to upload any Excel file, but parseUploadedFile function did not check for a valid session.
It did not actually store the uploaded file on the server, instead uploadFile task was used to process the uploaded file from the HTML form and return the contents of the file to client. It was not possible to upload the web shell because it did not store it on the server.
It was confirmed that reflected cross-site scripting vulnerability exists, but the question was how to exploit it? 🤔
I quickly created a web-page to exploit this XSS.
Unfortunately I was unable to exploit this because I (as an attacker) cannot control the contents of the file. 😕
After doing a little research on this, it was confirmed that form based file uploads do not allow attacker to specify file contents.
The real challenge comes here. 😨
All I need to do is host this file on my server and send its link to the victim, when s/he clicks on the link it will trigger a XSS popup with the domain name.
XSS attacks can allow malicious user to execute scripts on client’s machine which could gather information about the system and send that information to a malicious third-party.
An XSS attack can have potentially serious consequences. An attacker can trick a user to do unintended tasks by manipulating application DOM. After reporting this issue on Facebook, they gave me a very good reward.