Security OAuth2 and the Facebook Connect vulnerability
This is the stunning sequel to my first article.
I'm willing to bet that every web developer experienced with Facebook connect or Facebook login or authentication via Twitter. All of this is essentially built on the basis of OAuth1/2.
My opinion is that we all stepped on the wrong track. the OAuth is the path to hell (by the way, Eran hammer is now working on a replacement for oauth oz).
In this article I will not dive into the model of attack and retell a very specific vulnerability that you can start using right now.
In any other situation I would say that CSRF on such a minor, though, and state-changing functions is worthless. But as soon as it comes to protocols built on the redirects... the fact is that in 99 percent of cases, the process of the connect Site <= Facebook you can start downloading GET /users/connect/facebook want to start the process yourself, without user interaction.
The idea is to perhalogenated user on Facebook (the service provider) to your account, download this endpoint to connect that will automatically connect to the attacker account to the victim's account on the client, and then enter the account the victim himself.
Facebook is protected only through the check of the referer:
This new incarnation of Most Common Mistakes (do not check state) only at a higher level. We don't throw up your kolbek with your code, and forced himself to return the Facebook code from your account, a forced re-login. FB refused to fix it because it breaks compatibility with different existing plug-ins for FB. VK.com also vulnerable (these guys even reportit nowhere, a mockery of what is. Even the store with baubles more serious about security). This bug can be used on any website with omniauth, django-social-auth, php-sdk, and so on. Fix — need to check the csrf token when you load /connect address.
I would even say the idea of re-login casts a shadow on OAuth because even with the help of cookies forcing you to completely replace the cookies of the victim and perhalogenated it on any Provider. This is a conceptual mistake that is not correct.
CP is the signed request using the client_secret and it is created... it is unclear why. The fact that this is essentially the same code-flow code is transmitted only in the # fragment and released it for redirect_uri = "". So if you steal signed_request via 302 redirect, you can use it to log in as the owner of CP on the client's site (just put down the cookie fbsr_CLIENT_ID=SR).
In simple terms, if your website is using Facebook JS SDK and you have found a open redirect (domain or subdomain) — you can steal any account through the fusion of the SR victims. And this again is corrected.
Another WontFix. In Papale before running the express checkout flow you need to get request_token sending all your settings and then upload to paypal?token=request_token. The fact that you can release this token for yourself by phishing attempts to load this URL on the browser of the victim and convince him to pay this token (payment really will go to the Client) that it is possible to go on the callback?token=token and get all the money that was paid, the victim is already on your account. I checked it at namecheap.
It is a full copy session fixation in OAuth1. When it opened all providers shut off the connection to capacity. In our case, Paypal did not lift a ear. TK vulnerable again they do not, and sites clients.
I highly recommend not to use the login via social network. If you are forced to realize it, try to register a maximum of checks and put static colbecki in the settings of your client (hardening — reducing the attack surface). With the bugs above, I have found exploits to steal account on soundcloud, foursquare, songkick, airbnb, and a dozen start-UPS with social logins.
P. S. in Yandex bounty wrote as they steal accounts, but they are not very interesting so I copy here:
1) record a session on Facebook
2) caused by the logged-in Yandex url
social.yandex.ru/broker/start?retpath=https%3A%2F%2Fsocial.yandex.ru%2Fhtml%2Fcloser%2Fpromo_closer.html%23ddom%3D&consumer=social&popupName=social_popup&application=&action_if_anonymous=ignore&result_location=fragment&provider=fb&display=popup
3) it is automatic preconnected atkarsky FB to the passport, but fortunately (to my regret) have yet to confirm the auth through it. A little social engineering, ship
passport.yandex.ru/passport?mode=authentication&retpath=https%3A%2F%2Fsocial.yandex.ru%2Fupdate%3Fprofile_id%3D23177612%26allow_auth%3D1
as you can see there is no word about Facebook or accounts, just requires to enter the password that the user would love to do (side-bug. perhaps I should explain why ask password and then you never know)
4) now it is possible through atkarsky FB at Yandex, onconnecting Facebook, steal email and cookies — perfect crime
Original post in English.
Article based on information from habrahabr.ru
I'm willing to bet that every web developer experienced with Facebook connect or Facebook login or authentication via Twitter. All of this is essentially built on the basis of OAuth1/2.
My opinion is that we all stepped on the wrong track. the OAuth is the path to hell (by the way, Eran hammer is now working on a replacement for oauth oz).
In this article I will not dive into the model of attack and retell a very specific vulnerability that you can start using right now.
CSRF on login
In any other situation I would say that CSRF on such a minor, though, and state-changing functions is worthless. But as soon as it comes to protocols built on the redirects... the fact is that in 99 percent of cases, the process of the connect Site <= Facebook you can start downloading GET /users/connect/facebook want to start the process yourself, without user interaction.
The idea is to perhalogenated user on Facebook (the service provider) to your account, download this endpoint to connect that will automatically connect to the attacker account to the victim's account on the client, and then enter the account the victim himself.
Facebook is protected only through the check of the referer:
This new incarnation of Most Common Mistakes (do not check state) only at a higher level. We don't throw up your kolbek with your code, and forced himself to return the Facebook code from your account, a forced re-login. FB refused to fix it because it breaks compatibility with different existing plug-ins for FB. VK.com also vulnerable (these guys even reportit nowhere, a mockery of what is. Even the store with baubles more serious about security). This bug can be used on any website with omniauth, django-social-auth, php-sdk, and so on. Fix — need to check the csrf token when you load /connect address.
I would even say the idea of re-login casts a shadow on OAuth because even with the help of cookies forcing you to completely replace the cookies of the victim and perhalogenated it on any Provider. This is a conceptual mistake that is not correct.
signed_request
CP is the signed request using the client_secret and it is created... it is unclear why. The fact that this is essentially the same code-flow code is transmitted only in the # fragment and released it for redirect_uri = "". So if you steal signed_request via 302 redirect, you can use it to log in as the owner of CP on the client's site (just put down the cookie fbsr_CLIENT_ID=SR).
In simple terms, if your website is using Facebook JS SDK and you have found a open redirect (domain or subdomain) — you can steal any account through the fusion of the SR victims. And this again is corrected.
OAuth1 fixing Paypal
Another WontFix. In Papale before running the express checkout flow you need to get request_token sending all your settings and then upload to paypal?token=request_token. The fact that you can release this token for yourself by phishing attempts to load this URL on the browser of the victim and convince him to pay this token (payment really will go to the Client) that it is possible to go on the callback?token=token and get all the money that was paid, the victim is already on your account. I checked it at namecheap.
It is a full copy session fixation in OAuth1. When it opened all providers shut off the connection to capacity. In our case, Paypal did not lift a ear. TK vulnerable again they do not, and sites clients.
Output
I highly recommend not to use the login via social network. If you are forced to realize it, try to register a maximum of checks and put static colbecki in the settings of your client (hardening — reducing the attack surface). With the bugs above, I have found exploits to steal account on soundcloud, foursquare, songkick, airbnb, and a dozen start-UPS with social logins.
P. S. in Yandex bounty wrote as they steal accounts, but they are not very interesting so I copy here:
1) record a session on Facebook
2) caused by the logged-in Yandex url
social.yandex.ru/broker/start?retpath=https%3A%2F%2Fsocial.yandex.ru%2Fhtml%2Fcloser%2Fpromo_closer.html%23ddom%3D&consumer=social&popupName=social_popup&application=&action_if_anonymous=ignore&result_location=fragment&provider=fb&display=popup
3) it is automatic preconnected atkarsky FB to the passport, but fortunately (to my regret) have yet to confirm the auth through it. A little social engineering, ship
passport.yandex.ru/passport?mode=authentication&retpath=https%3A%2F%2Fsocial.yandex.ru%2Fupdate%3Fprofile_id%3D23177612%26allow_auth%3D1
as you can see there is no word about Facebook or accounts, just requires to enter the password that the user would love to do (side-bug. perhaps I should explain why ask password and then you never know)
4) now it is possible through atkarsky FB at Yandex, onconnecting Facebook, steal email and cookies — perfect crime
Original post in English.
Comments
Post a Comment