Showing posts with label Facebook. Show all posts
Showing posts with label Facebook. Show all posts
Thursday, 4 June 2015
Facebook Old Generated URLs Still Vulnerable to Open Redirect Attacks & A New Open Redirect Web Security Bugs
This summary is not available. Please
click here to view the post.
Facebook, Google, Microsoft, Yahoo Users Threatened by New Security Flaw, Covert Redirect
A serious flaw in two widely used security standards could give anyone access to your account information at Google, Microsoft, Facebook, Twitter and many other online services. The flaw, dubbed "Covert Redirect" by its discoverer, exists in two open-source session-authorization protocols, OAuth 2.0 and OpenID.
Both standards are employed across the Internet to let users log into websites using their credentials from other sites, such as by logging into a Web forum using a Facebook or Twitter username and password instead of creating a new account just for that forum.
Attackers could exploit the flaw to disguise and launch phishing attempts from legitimate websites, said the flaw's finder, Mathematics Ph.D. student Wang Jing of the Nanyang Technological University in Singapore.
Wang believes it's unlikely that this flaw will be patched any time soon. He says neither the authentication companies (those with which users have an account, such as Google, Microsoft, Facebook, Twitter or LinkedIn, among others) nor the client companies (sites or apps whose users log in via an account from an authentication company) are taking responsibility for fixing the issue.
"The vulnerability is usually due to the existing weakness in the third-party websites," Wang writes on his own blog. "However, they have little incentive to fix the problem."
The biggest danger of Covert Redirect is that it could be used to conduct phishing attacks, in which cybercriminals seize login credentials, by using email messages containing links to malicious websites disguised as something their targets might want to visit.
Normal phishing attempts can be easy to spot, because the malicious page's URL will usually be off by a couple of letters from that of the real site. The difference with Covert Redirect is that an attacker could use the real website instead by corrupting the site with a malicious login popup dialogue box.
For example, say you regularly visit a given forum (the client company), to which you log in using your credentials from Facebook (the authentication company). Facebook uses OAuth 2.0 to authenticate logins, so an attacker could put a corrupted Facebook login popup box on this forum.
If you sign in using that popup box, your Facebook data will be released to the attacker, not to the forum. This means the attacker could possibly gain access to your Facebook account, which he or she could use to spread more socially engineered attacks to your Facebook friends.
Covert Redirect could also be used in redirection attacks, which is when a link takes you to a different page than the one expected.
Wang told CNET authentication companies should create whitelists — pre-approved lists that block any not on it — of the client companies that are allowed to use OAuth and OpenID to redirect to them. But he said he had contacted a number of these authentication companies, who all shifted blame elsewhere.
Wang told CNET Facebook had told him it "understood the risks associated with OAuth 2.0" but that fixing the flaw would be "something that can't be accomplished in the short term." Google and LinkedIn allegedly told Wang they were looking into the issue, while Microsoft said the issue did not exist on its own sites.
Covert Redirect appears to exist in the implementations of the OpenID and OAuth standards used on client websites and apps. But because these two standards are open-source and were developed by a group of volunteers, there's no company or dedicated team that could devote itself to fixing the issue.
Where does that leave things?
"Given the trust users put in Facebook and other major OAuth providers, I think it will be easy for attackers to trick people into giving some access to their personal information stored on those service," Chris Wysopal, chief technology officer of Boston-area security firm Veracode and a member of the legendary 1990s hackerspace the L0pht, told CNET.
"It's not easy to fix, and any effective remedies would negatively impact the user experience," Jeremiah Grossman, founder of Santa Clara, Calif.-based WhiteHat Security, told CNET. "Just another example that Web security is fundamentally broken and the powers that be have little incentive to address the inherent flaws."
Users should be extra-wary of login popups on Web pages. If you wish to log into a given website, it might be better to use an account specific to that website instead of logging in with Facebook, Twitter, or another authentication company, which would require the use of OAuth and/or OpenID to do.
If you think someone has gained access to one of your online accounts, notify the service and change that account's password immediately.
Related Articles:
http://www.tomsguide.com/us/facebook-google-covert-redirect-flaw,news-18726.html
http://www.scmagazine.com/covert-redirect-vulnerability-impacts-oauth-20-openid/article/345407/
http://news.yahoo.com/facebook-google-users-threatened-security-192547549.html
http://thehackernews.com/2014/05/nasty-covert-redirect-vulnerability.html
http://www.foxnews.com/tech/2014/05/05/facebook-google-users-threatened-by-new-security-flaw/
http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html
http://whitehatview.tumblr.com/post/120695795041
http://russiapost.blogspot.ru/2015/05/openid-oauth-20.html
http://www.diebiyi.com/articles/security/covert-redirect/covert_redirect/
http://whitehatpost.lofter.com/post/1cc773c8_706b622
https://itswift.wordpress.com/2014/05/06/microsoft-google-facebook-attacked/
http://tetraph.blog.163.com/blog/static/2346030512015420103814617/
http://itsecurity.lofter.com/post/1cfbf9e7_72e2dbe
http://ithut.tumblr.com/post/119493304233/securitypost-une-faille-dans-lintegration
http://japanbroad.blogspot.jp/2015/05/oauthopenid-facebook.html
http://webtech.lofter.com/post/1cd3e0d3_6f0f291
https://webtechwire.wordpress.com/2014/05/11/covert-redirect-attack-worldwide/
http://whitehatview.tumblr.com/post/119489968576/securitypost-sicherheitslucke-in-oauth-2-0-und
http://www.inzeed.com/kaleidoscope/computer-security/facebook-google-attack/
Friday, 2 May 2014
Facebook OAuth 2.0 Service Covert Redirect Web Security Bugs Based on Ask.com (Information Leakage & Open Redirect)
Facebook OAuth 2.0 Service Covert Redirect Web Security Bugs Based on Ask.com (Information Leakage & Open Redirect)
(1) Domain:
facebook.com
(2) Vulnerability Description:
Facebook web application has a computer security problem. Hacker can exploit it by Covert Redirect cyber attacks.
The vulnerabilities can be attacked without user login. Tests were performed on Microsoft IE (10.0.9200.16750) of Windows 8, Mozilla Firefox (34.0) & Google Chromium 39.0.2171.65-0 ubuntu0.14.04.1.1064 (64-bit) of Ubuntu (14.04)，Apple Safari 6.1.6 of Mac OS X Lion 10.7.
(2.1) Vulnerability Description:
A Covert Redirect vulnerability was found related to Facebook and was reported.
Facebook said "Short of forcing every single application on the platform to use a whitelist, which isn't something that can be accomplished in the short term, do you have any recommendations on actions we can take here?"
In my reply, I suggested "For any URL, it has a particular value "&h". If the URL is changed. there is no permission any more. That means the modified URL will not get any "&h". Because it is illegal."
Facebook agreed. "As you mentioned, that's how our Linkshim system works. As I said, that doesn't seem to be a feasible solution for an OAuth endpoint where the URL needs to be provided by a third-party site to arbitrary random users."
(2.1.1) Vulnerability Detail:
Facebook's SSO system is susceptible to Attacks. More specifically, the authentication of parameter "&redirct_uri" in SSO system is insufficient. It can be misused to design Open Redirect Attacks to Facebook.
At the same time, it can be used to collect sensitive information of both third-party app and users by using the following parameters,
"&response_type"=sensitive_info,token...
"&scope"=email,user_birthday,user_likes.
It increases the likelihood of successful Open Redirect Attacks to third-party websites, too.
The vulnerabilities occurs at page "/dialog/oauth?" with parameter "&redirect_uri", e.g.
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=http%3A%2F%2Fwzus.ask.com%2Fr%3Ft%3Dp%26u%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fdistance.html%3F&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup [1]
Before acceptance of third-party application:
When a logged-in Facebook user clicks the URL ([1]) above, he/she will be asked for consent as in whether to allow a third-party website to receive his/her information. If the user clicks OK, he/she will be then redirected to the URL assigned to the parameter "&redirect_uri".
If a user has not logged onto Facebook and clicks the URL ([1]) above, the same situation will happen upon login.
After acceptance of third-party application:
A logged-in Facebook user would no longer be asked for consent and could be redirected to a webpage controlled by the attacker when he/she clicks the URL ([1]).
For a user who has not logged in, the attack could still be completed after a pop-up page that prompts him/her to log in.
(2.1.2) Facebook would normally allow all the URLs that belong to the domain of an authorized third-party website. However, these URLs could be prone to manipulation. For example, the "&redirect_uri" parameter in the URLs is supposed to be set by the third-party websites, but an attacker could change its value to make Attacks.
Hence, a user could be redirected from Facebook to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site unwillingly. This is as if the user is redirected from Facebook directly. The number of Facebook's SSO client websites is so huge that such Attacks could be commonplace.
Before acceptance of the third-party application, Facebook's SSO system makes the redirects appear more trustworthy and could potentially increase the likelihood of successful Open Redirect Attacks of third-party website.
Once the user accepts the application, the attackers could completely bypass Facebook's authentication system and attack more easily.
It might be of Facebook's interest to patch up against such attacks.
(2.2) Used one of webpages for the following tests. The webpage is "http://www.diebiyi.com/articles". We can suppose it is malicious and contains code that collect sensitive information of both third-party app and users.
Below is an example of a vulnerable third-party domain:
ask.com
Vulnerable URL in this domain:
http://wzap.ask.com/r?t=v&d=im&u=http%3A%2F%2Ftetraph.com
Vulnerable URL from Facebook that is related to ask.com:
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=https%3a%2f%2fsocial.ask.com%2fGS%2fGSLogin.aspx%3fst%3dzNQz0TjIZd42P_zI5MUVw5WtCHw7EDMc1YEjBVuz3bU.&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup
POC:
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=http%3A%2F%2Fwzus.ask.com%2Fr%3Ft%3Dp%26u%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fdistance.html%3F&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup
(2.3) The following URLs have the same vulnerabilities.
https://m.facebook.com/dialog/oauth?redirect_uri=http%3A%2F%2Fm.espn.go.com%2Fwireless%2Fconnect&scope=email%2Cuser_birthday%2Cuser_likes&client_id=116656161708917
https://graph.facebook.com/oauth/authorize?client_id=116656161708917&redirect_uri=http://m.espn.go.com/wireless/connect&display=touch&scope=email,user_birthday,user_likes
http://www.facebook.com/dialog/feed?app_id=180444840287&link=http://www.theguardian.com/money/2007/apr/21/creditcards.debt&display=popup&redirect_uri=http://gu-social-share-experiments.theguardian.com&show_error=false&ref=desktop
https://api.instagram.com/oauth/authorize/?client_id=28ad60e4d0b14b5c8bd87099e53feaef&redirect_uri=http%3A%2F%2Ffollowgram.me%2Flogin&response_type=code&scope=likes+comments+relationships&display=touch
POC Video:
https://www.youtube.com/watch?v=Y2-2Scp0pbs
Blog Detail:
http://www.tetraph.com/blog/covert-redirect/facebook-oauth-2-0-covert-redirect-vulnerability-based-on-ask-com-information-leakage-and-url-redirect/
Facebook said "Short of forcing every single application on the platform to use a whitelist, which isn't something that can be accomplished in the short term, do you have any recommendations on actions we can take here?"
In my reply, I suggested "For any URL, it has a particular value "&h". If the URL is changed. there is no permission any more. That means the modified URL will not get any "&h". Because it is illegal."
Facebook agreed. "As you mentioned, that's how our Linkshim system works. As I said, that doesn't seem to be a feasible solution for an OAuth endpoint where the URL needs to be provided by a third-party site to arbitrary random users."
(2.1.1) Vulnerability Detail:
Facebook's SSO system is susceptible to Attacks. More specifically, the authentication of parameter "&redirct_uri" in SSO system is insufficient. It can be misused to design Open Redirect Attacks to Facebook.
At the same time, it can be used to collect sensitive information of both third-party app and users by using the following parameters,
"&response_type"=sensitive_info,token...
"&scope"=email,user_birthday,user_likes.
It increases the likelihood of successful Open Redirect Attacks to third-party websites, too.
The vulnerabilities occurs at page "/dialog/oauth?" with parameter "&redirect_uri", e.g.
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=http%3A%2F%2Fwzus.ask.com%2Fr%3Ft%3Dp%26u%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fdistance.html%3F&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup [1]
Before acceptance of third-party application:
When a logged-in Facebook user clicks the URL ([1]) above, he/she will be asked for consent as in whether to allow a third-party website to receive his/her information. If the user clicks OK, he/she will be then redirected to the URL assigned to the parameter "&redirect_uri".
If a user has not logged onto Facebook and clicks the URL ([1]) above, the same situation will happen upon login.
After acceptance of third-party application:
A logged-in Facebook user would no longer be asked for consent and could be redirected to a webpage controlled by the attacker when he/she clicks the URL ([1]).
For a user who has not logged in, the attack could still be completed after a pop-up page that prompts him/her to log in.
(2.1.2) Facebook would normally allow all the URLs that belong to the domain of an authorized third-party website. However, these URLs could be prone to manipulation. For example, the "&redirect_uri" parameter in the URLs is supposed to be set by the third-party websites, but an attacker could change its value to make Attacks.
Hence, a user could be redirected from Facebook to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site unwillingly. This is as if the user is redirected from Facebook directly. The number of Facebook's SSO client websites is so huge that such Attacks could be commonplace.
Before acceptance of the third-party application, Facebook's SSO system makes the redirects appear more trustworthy and could potentially increase the likelihood of successful Open Redirect Attacks of third-party website.
Once the user accepts the application, the attackers could completely bypass Facebook's authentication system and attack more easily.
It might be of Facebook's interest to patch up against such attacks.
(2.2) Used one of webpages for the following tests. The webpage is "http://www.diebiyi.com/articles". We can suppose it is malicious and contains code that collect sensitive information of both third-party app and users.
Below is an example of a vulnerable third-party domain:
ask.com
Vulnerable URL in this domain:
http://wzap.ask.com/r?t=v&d=im&u=http%3A%2F%2Ftetraph.com
Vulnerable URL from Facebook that is related to ask.com:
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=https%3a%2f%2fsocial.ask.com%2fGS%2fGSLogin.aspx%3fst%3dzNQz0TjIZd42P_zI5MUVw5WtCHw7EDMc1YEjBVuz3bU.&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup
POC:
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=http%3A%2F%2Fwzus.ask.com%2Fr%3Ft%3Dp%26u%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fdistance.html%3F&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup
(2.3) The following URLs have the same vulnerabilities.
https://m.facebook.com/dialog/oauth?redirect_uri=http%3A%2F%2Fm.espn.go.com%2Fwireless%2Fconnect&scope=email%2Cuser_birthday%2Cuser_likes&client_id=116656161708917
https://graph.facebook.com/oauth/authorize?client_id=116656161708917&redirect_uri=http://m.espn.go.com/wireless/connect&display=touch&scope=email,user_birthday,user_likes
http://www.facebook.com/dialog/feed?app_id=180444840287&link=http://www.theguardian.com/money/2007/apr/21/creditcards.debt&display=popup&redirect_uri=http://gu-social-share-experiments.theguardian.com&show_error=false&ref=desktop
https://api.instagram.com/oauth/authorize/?client_id=28ad60e4d0b14b5c8bd87099e53feaef&redirect_uri=http%3A%2F%2Ffollowgram.me%2Flogin&response_type=code&scope=likes+comments+relationships&display=touch
(3) What is Covert Redirect?
Covert Redirect is a class of security bugs disclosed in May 2014. It is an application that takes a parameter and redirects a user to the parameter value without sufficient validation. This often makes use of Open Redirect and XSS (Cross-site Scripting) vulnerabilities in third-party applications.
Covert Redirect is also related to single sign-on. It is known by its influence on OAuth and OpenID. Hacker may use it to steal users' sensitive information. Almost all OAuth 2.0 and OpenID providers worldwide are affected. Covert Redirect can work together with CSRF (Cross-site Request Forgery) as well.
Discover and Reporter:
Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. (@justqdjing)
POC Video:
https://www.youtube.com/watch?v=Y2-2Scp0pbs
Blog Detail:
http://www.tetraph.com/blog/covert-redirect/facebook-oauth-2-0-covert-redirect-vulnerability-based-on-ask-com-information-leakage-and-url-redirect/
Subscribe to:
Posts (Atom)