Security OAuth2 and Facebook Connect vulnerabilities
This is the sequel to my stunning first article .
I bet that every web developer has come across a facebook connection or VKontakte login or authentication via Twitter. All this is essentially built on the basis of OAuth1 / 2.
My opinion is that we all set foot on the wrong track. OAuth is the path to hell (by the way, Eran Hammer is currently working on replacing oauth - oz).
')
In this article, I will not dive into the attack model, but will retell very specific vulnerabilities that you can start using right now.
In any other situation, I would say that the CSRF on such an insignificant, though state-changing, function costs nothing. But as soon as it comes to protocols built on redirects ... The fact is that in 99 percent of cases, the connection process Site <= Facebook can be started by downloading GET / users / connect / facebook to start the process yourself, without user interaction.
The idea is to re-log the user on Facebook (provider) into your account, download this endpoint for a connection that automatically connects the attacker's account to the victim's account on the client, and then log into the victim's account yourself.
Facebook is protected only by checking the referrer:
This is the new incarnation of the Most Frequent Error (not checking state) only at a higher level. We do not pop up our callback with our code, but we force Facebook itself to return the code from your account by forced re-login. FB refused to fix it, as it breaks compatibility with various existing FB plugins. VK.com is also vulnerable (these guys have no place to report, some kind of ridicule. Even a store with baubles takes security more seriously). This bug can be used on any site with omniauth, django-social-auth, php-sdk and so on. Correction - you need to check csrf token when loading / connect addresses.
I would even say the idea of a relogin casts a shadow on OAuth - even with the help of cookie forcing, you can completely replace the victim's cookies and relogin it on any Provider. This is a conceptual mistake that can not be fixed.
The CP is a signed request using client_secret and it was created ... it is not clear why. The fact is that this is essentially the same code-flow, only the code is transmitted in the # fragment and it is released for redirect_uri = "". So, if you steal a signed_request after 302 redirect, you can use it to log in as the owner of the CP on the client’s website (just put a cookie fbsr_CLIENT_ID = SR).
In simple terms, if the site has a Facebook JS SDK and you found an open redirect (on a domain or subdomain) - you can hijack any account through merging SR of the victim. And this again will not be fixed.
Another WontFix. Before the start of the express checkout flow, you need to get the request_token by sending all its parameters and then load paypal? Token = request_token. The fact is that you can release this token for yourself, by phishing, download this URL on the victim's browser and convince him to pay this token (the payment really goes to the Client) then you can go by callback? Token = token and get all the money that paid the victim is already in your account. I checked it on namecheap.
This is a complete copy of session fixation in OAuth1. When it was opened, all providers turned off the connection to patch. In our case, Paypal did not even move its ear. Tk again, they are not vulnerable, but client sites.
I highly recommend not using the login through social networks. If you are forced to implement it, try to register a maximum of checks and put static callbacks in the settings of your client (hardening - reduction of the attack surface). With the bugs above, I found exploits to hijack my account on soundcloud, foursquare, songkick, airbnb, and a dozen other startups with social logins.
PS in Yandex Bounty wrote how to steal accounts from them, but they are not very interested, therefore, copy here:
1) fix the session on Facebook
2) call url in Yandex
social.yandex.ru/broker.com
3) he automatically attaches the attacker fb to the passport, but fortunately (my regret) you must also 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 not a word about facebook or accounts, it just requires you to enter a password, which the user will gladly do (side-bug. probably worth explaining why they ask for a password, and then you never know)
4) now it is possible to enter directly through Yandex, connect Facebook, steal mail and cookies through the attacker fb - the perfect crime
Original post in English.
I bet that every web developer has come across a facebook connection or VKontakte login or authentication via Twitter. All this is essentially built on the basis of OAuth1 / 2.
My opinion is that we all set foot on the wrong track. OAuth is the path to hell (by the way, Eran Hammer is currently working on replacing oauth - oz).
')
In this article, I will not dive into the attack model, but will retell very specific vulnerabilities that you can start using right now.
CSRF on login
In any other situation, I would say that the CSRF on such an insignificant, though state-changing, function costs nothing. But as soon as it comes to protocols built on redirects ... The fact is that in 99 percent of cases, the connection process Site <= Facebook can be started by downloading GET / users / connect / facebook to start the process yourself, without user interaction.
The idea is to re-log the user on Facebook (provider) into your account, download this endpoint for a connection that automatically connects the attacker's account to the victim's account on the client, and then log into the victim's account yourself.
Facebook is protected only by checking the referrer:
This is the new incarnation of the Most Frequent Error (not checking state) only at a higher level. We do not pop up our callback with our code, but we force Facebook itself to return the code from your account by forced re-login. FB refused to fix it, as it breaks compatibility with various existing FB plugins. VK.com is also vulnerable (these guys have no place to report, some kind of ridicule. Even a store with baubles takes security more seriously). This bug can be used on any site with omniauth, django-social-auth, php-sdk and so on. Correction - you need to check csrf token when loading / connect addresses.
I would even say the idea of a relogin casts a shadow on OAuth - even with the help of cookie forcing, you can completely replace the victim's cookies and relogin it on any Provider. This is a conceptual mistake that can not be fixed.
signed_request
The CP is a signed request using client_secret and it was created ... it is not clear why. The fact is that this is essentially the same code-flow, only the code is transmitted in the # fragment and it is released for redirect_uri = "". So, if you steal a signed_request after 302 redirect, you can use it to log in as the owner of the CP on the client’s website (just put a cookie fbsr_CLIENT_ID = SR).
In simple terms, if the site has a Facebook JS SDK and you found an open redirect (on a domain or subdomain) - you can hijack any account through merging SR of the victim. And this again will not be fixed.
OAuth1 Paypal Commit
Another WontFix. Before the start of the express checkout flow, you need to get the request_token by sending all its parameters and then load paypal? Token = request_token. The fact is that you can release this token for yourself, by phishing, download this URL on the victim's browser and convince him to pay this token (the payment really goes to the Client) then you can go by callback? Token = token and get all the money that paid the victim is already in your account. I checked it on namecheap.
This is a complete copy of session fixation in OAuth1. When it was opened, all providers turned off the connection to patch. In our case, Paypal did not even move its ear. Tk again, they are not vulnerable, but client sites.
Conclusion
I highly recommend not using the login through social networks. If you are forced to implement it, try to register a maximum of checks and put static callbacks in the settings of your client (hardening - reduction of the attack surface). With the bugs above, I found exploits to hijack my account on soundcloud, foursquare, songkick, airbnb, and a dozen other startups with social logins.
PS in Yandex Bounty wrote how to steal accounts from them, but they are not very interested, therefore, copy here:
1) fix the session on Facebook
2) call url in Yandex
social.yandex.ru/broker.com
3) he automatically attaches the attacker fb to the passport, but fortunately (my regret) you must also 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 not a word about facebook or accounts, it just requires you to enter a password, which the user will gladly do (side-bug. probably worth explaining why they ask for a password, and then you never know)
4) now it is possible to enter directly through Yandex, connect Facebook, steal mail and cookies through the attacker fb - the perfect crime
Original post in English.
Source: https://habr.com/ru/post/211362/
All Articles