Friday, October 17, 2014

Facebook's Critical "Won't Fix" Issue [0-Day]



       In this post, I will be talking about a new critical security issue that Facebook decided to not fix.

       During my tests for CSRF issues, I have noticed that Facebook has a CSRF token called “fb_dtsg”. It is used in every action request, and it's the only protection for Cross-Site Request Forgery vulnerabilities on m.facebook.com . Simply, by finding a security issue on “fb_dtsg” token, users will be vulnerable to CSRF attacks, which is extremely dangerous and can be used to compromise users.

       I have noticed that “fb_dtsg” is not vulnerable to classic CSRF attacks (that can be occur due the lack of validation process of CSRF tokens). Then, I started to search for bugs that affects the CSRF token.

       After tests, I have found that the “fb_dtsg” token is vulnerable to Broken Authentication and Session Management bug. By using the particular Broken Authentication and Session Management issue that I have discovered, hackers can use the issue to perform successful Cross-Site Request Forgery attacks against billions of users around the world.

How?
       I have logged the value of the CSRF token then I created a small POC for “sending messages” by using the correct current token that I have logged. Then I logged off my test account. After that, I logged in test and changed my password and logged off again. Then I logged in again. Finally, I tried the POC using the previous value that was been assigned to me before I changed my password and multiple logged off my account, and it IT WORKED!!. Using the old CSRF token, I was able to send messages successfully.





What does That Mean ?
       Being able to reuse the CSRF token after changing password and logging off  means that anyone who get the value of someone's CSRF token, he will be able to perform CSRF attacks against users, even if they do all the required steps to insure their security.


       Scenarios:

  •    Scenario#1:
1-An attacker find a way to get an access to the victim’s Facebook account.
2-The attacker gets the value of “fb_dtsg” token. and now he have a forward step on the victim’s account.
3- The victim realized that his account was compromised, then he changed the Facebook password to secure his account, and he has made all the necessary steps to secure his account.
4-The attacker sends a CSRF exploit to the victim, using the old CSRF token.
5-The victim opens the CSRF exploit, and it worked successfully although he has secured his account by making all the necessary steps.
6-The attacker gained access again to the victim’s account.

  •    Scenario #2:
   Matt and James work in the same company. Matt has left his laptop working, and James quickly opened Matt's Facebook account, and logged the value of Matt's “fb_dtsg” token. James later wanted to get Matt in trouble, so he send him a link containing a CSRF exploit using Matt's CSRF token. James successfully made an action on Matt's Facebook account on behalf of Matt's permission.


       As you can see, this issue is critical and need to be addressed quickly. So I reported the issue to Facebook Security Team. I thought that this issue will qualify for their bounty program, and would be fixed immediately, but instead, Facebook responded that this issue doesn't qualify for their Bounty Program.

       didn't expect Facebook Security to give such a response like that, so I asked for a confirmation about their reasons of rejecting it, as it's a most-fix issue that affects the security of the most popular social-media website in the world, Facebook. After my follow-up to get the reason why it doesn't qualify for their bounty program, they responded:





       Although the CSRF token might be expired by after a specific duration ( such as months), this is not the best practice to be used to secure against Cross-Site Request Forgery. Instead, CSRF tokens should be expired upon the end of the session.

Recommendation:
       I guess their is not solution or protection for this issue for users whose accounts were hacked or have been used by others before. So basically, every Facebook account is vulnerable, and there is no way to protect your account against the issue.


Final Thoughts:

  • I am pretty sure that Facebook Security understands the risk of the vulnerability and how it can be abused to take-over accounts. I guess there is a hidden reason but the bug's rejection, and I still don't know why.

  • Exploiting this issue is not difficult, even for beginners, so it might be being exploited publicly to regain access to compromised Facebook accounts.

  • The only good use for the vulnerability might be used for restoring Facebook accounts. For instance, the user can send the exploit to the attacker who hacked the user's account, when the attacker opens the exploit, the user will restore his account ( if he already have the value of the “fb_dtsg” token).

       If you need any help securing your web-application or service, you can contact me by E-Mail, or Twitter.

Best Regards,
Mazin Ahmed