In March 2020, the pandemic began, so I had a lot of free time. They needed to be managed wisely, and I decided to get OSWE certification. After passing the exam on August 8, I took a couple of weeks off, and then in mid-September I said to myself: “You know what? My name did not appear in the Facebook Hall of Fame in 2020, although it does happen there annually. It's time to solve this problem! ”.
I have never found a vulnerability on one of the Facebook subdomains, so I studied the articles and found one post about the Facebook subdomain that caught my attention. This is a great post, I recommend reading it: [HTML to PDF conversion bug leads to RCE on Facebook server] .
After reading this post, I realized that many vulnerabilities can be found in such a huge web application.
My main target was
https://legal.tapprd.thefacebook.com
, I intended to implement RCE (Remote Code Execution) or something similar.
I ran fuzzing tools to find out all the endpoints of this web application, took a two hour nap, and watched a movie. Then I went back to my computer and found good results.
403:
/tapprd/
/tapprd/content/
/tapprd/services/
/tapprd/Content/
/tapprd/api/
/tapprd/Services/
/tapprd/temp/
/tapprd/logs/
/tapprd/logs/portal/
/tapprd/logs/api/
/tapprd/certificates/
/tapprd/logs/auth/
/tapprd/logs/Portal/
/tapprd/API/
/tapprd/webroot/
/tapprd/logs/API/
/tapprd/certificates/sso/
/tapprd/callback/
/tapprd/logs/callback/
/tapprd/Webroot/
/tapprd/certificates/dkim/
/tapprd/SERVICES/
I think this result is quite enough to confirm my theory about the enormity of this application. Then I began to read files Javascript is, to understand how the web site, what methods he uses, etc...
I saw a way to bypass the redirection to the Login SSO on
https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login
and after analyzing the login page I found this endpoint:
/tapprd/auth/identity/user/forgotpassword
After fuzzing by endpoint of the user, I identified another endpoint
/savepassword
awaiting a POST request, After examining the Javascript files, I figured out how the page works, that the generated token and xsrf token are needed, etc. At first I thought it was worth trying to check, you can whether to change them manually with the help
burp suite
, but got an error failure of the operation .
I thought it might be the wrong email address or something similar. Let's try to pick up the administrator's email. I started jotting down arbitrary email addresses, making a list of words, and then using burp to test what happened.
When I returned a couple of hours later, I saw the same errors, plus another result. It was a 302 redirect to the login page. Wow, damn it worked!
Let me explain what happened here: I sent random requests with a CSRF token using a cracker and random email addresses with a new endpoint password
/savepassword
, and one of the results was a 302 redirect.
Redirect
Now I could go to the login page, enter my email and a new password - BOOM, login to the application was successful and I had access to the admin panel!
I read the report of a hacker who found a previous RCE implemented with PDF, the company gave him a reward of only $ 1000. So I decided: ok, you need to make a good impression and write the perfect exploit to get a high Impact.
I quickly wrote a simple Python script to exploit this vulnerability: you enter an email address and a new password, and the script changes the password.
Impact was so great here because Facebook employees logged in with their work accounts. That is, they used their own access tokens for Facebook accounts, and it is likely that if another attacker wanted to use this exploit, it would give him access to the accounts of some Facebook employees.Then
I reported the vulnerability, and my report was reviewed.
I received a $ 7,500 award on October 2nd
I liked the exploit for this vulnerability so much, and I decided that it was not enough, the script is too weak! It is worth continuing to dig deeper.
So I found two more vulnerabilities, which I will discuss in the second part of the article.
Part two
In the first part, I discovered the ability to hijack an account with an insecure API, which allowed me to change the password of any administrator account without user intervention, for which the Facebook security department paid me $ 7,500 . In the second part, I discovered a way to hijack an account using cookie manipulation. Combining it with the internal SSRF , I received a $ xxxxx reward . Yes, a five-figure sum ... Well, let's get started.
Before publication, the article was checked by several parties, and I had to get written permission for it, so some of the names and information could be changed at the request of Facebook and its partners.
When I discovered the vulnerability from the first part of the article, Facebook fixed it the day after receiving the report. Then I started studying history
burp suite
to understand how it all works.
As you can see from the screenshot (number 1 on a blue background), ASPXAUTH is used as a cookie . Ideally!
Do you see what I'm getting at? ASPXAUTH has an 80% chance of being vulnerable, but this requires the following information:
validationKey
(): , .decryptionMethod
(): ( «AES»).decryptionIV
(): ( — , ).decryptionKey
(): , .
You can read more about this here: MachineKey Class .
I have no information on any of the points, so why did I assume that there is a vulnerability here?
Actually, I don't know this, but in most ASPXAUTH applications , encrypted cookies with encryption keys usually only use email or user and cookie expiration time. I have used this method many times in the bounty programs of other websites and it worked.
I needed to find a way to get around this system, at least not a torture attempt. I went to Google and looked for other websites that use the same application. I was supposed to get lucky and find a website using the same application and the same encryption keys, and just pick the correct admin username.
I found another website using the same application, registration was active, so I logged in with the Facebook admin username, intercepted the request, took ASPXAUTH and replaced it with the expired Facebook ASPXAUTH . Guess what happened?
I already missed this panel, but finally returned to it. Now, let's talk a little about the ASP.net oversight that most developers should take into account when building applications to keep them secure:
- ASPXAUTH must be stored in the database and the application must validate it for correctness.
- As an additional check, ASPXAUTH sometimes has to contain more than just the username.
- Each site must have unique encryption and decryption keys (the default keys need to be changed).
Conclusion 1 : I could log into any administrator account, knowing only its username; I consider the complexity of this vulnerability very low , and its impact high . If I only report this vulnerability, I will receive only $ 7,500 , as in the first part, but I wanted more.
In the panel, I noticed something curious, namely the option to create forms and another option - API trigger. I suspected something, most likely there is a possibility of unlimited SSRF (Server-Side Request Forgery). Therefore, I wrote a letter to the Facebook security department, saying that there is almost one hundred percent of the critical SSRF vulnerability in the application, asking permission to test it. The answer came to me:
At that time, I was still discussing the report from the first part (account hijacking) with them, because I reported these vulnerabilities a week after the first. As you can see, Facebook's security department continued to believe that I was claiming another authentication bypass and SSRF, even after I explained the vulnerabilities with evidence. Judging by this, I was given permission to test SSRF.
After a while, I wrote a small script and uploaded it to their editor. The script allowed me to send any request with any data (GET, POST, PUT, PATCH, HEAD, OPTIONS) to any URL, both internal and external.
From the backend of the script, I could change the request method and the data sent, etc.
At this stage, I could expand this vulnerability to RCE, maybe to LFI (Local File Inclusion, adding local files), if I go a little further ( I'm not completely sure about this, later I asked Facebook for permission to reverse engineer the application, but they refused and said they didn’t think I could expand the attack ).
Then I tried to attack Facebook with a canary script. Guess what happened again?
I received my canary token. What's next? I need to write a new report with all the details, including scripts and PoC (proof of concept), as I was told above.
Conclusion 2: By writing a script to send arbitrary requests, I could get the internal SSRF and provide access to the internal Facebook network. I consider the difficulty of this attack to be low, and the Impact to be critical .
Impact SSRF:
SSRF- Facebook, , -, . SSRF .
SSRF-, , , , , .
Learn more about SSRF vulnerabilities can be found in the article portswigger .
Final takeaway: I chained both vulnerabilities to the point where I had access to the Facebook intranet ( SSRF ), using Account takeover to get to my uploaded script inside the application, sending the arbitrary requests I wanted.
Let's talk about what I can achieve with the vulnerability chain I discovered:
- I can access any Facebook employee's account in the Legal Department dashboard.
- There is no need to explain how important information an attacker can get after logging in.
- I could use SSRF to access the Facebook intranet (intern.our.facebook.com).
- I think that with a little more effort, I could expand this vulnerability and use it to scan the internal network / servers.
We all know how critical SSRF is , especially if it's not frequency limited. I can easily change the content type and request methods. According to the Facebook billing guides, this vulnerability should be rewarded with $ 40,000 in a $ 5,000 bonus if I can change the request content type and request method.
After a long wait, I received this message from Facebook:
Received a $ 40,000 award from Facebook plus a $ 2,000 bonus (up from the expected $ 7,000 ).
I asked them a question about why I did not receive the Full Control Bonus ( $ 5,000 ), and received this answer:
In total, with the first vulnerability, this amounted to $ 54,800 .
I reported this vulnerability a few days after the first part of the vulnerability report.
Chronology of reports:
- Wednesday, September 9, 2020 - Vulnerability report sent.
- Monday, October 26, 2020 - Facebook has asked me to open a new report. ~ Corrective measures taken.
- Monday, 26 October 2020 - report reviewed.
- Thursday 25th February 2021 - Issue resolved and bounty paid. About six months, yeah .
- Friday, March 5, 2021 - $ 5,300 bonus paid.
I want to give some valuable advice to bug hunters. When you see ASPXAUTH , try to get cookies from another website using the same application and test the same method as mine:
- Create new ASPXAUTH cookies from another website.
- Check to see if cookies will work on the website under investigation.
I liked the process, but waiting for six months and closing reports for irrational reasons was annoying. I am grateful, but had to work hard and this is not the only SSRF I have found. In fact, I found more curious ones, but Facebook closed the reports as "informative" because the company signed an agreement with the supplier that it struck a few weeks after reviewing the reports. Ultimately, this is not my problem, so this experience is not pleasant.
In the end, I want to apologize if something was not clear. It took some time to publish the second part - as mentioned above, I was waiting for written permission and revision of the report. Therefore, many aspects have been removed or censored to preserve the confidentiality of third parties.