Des vulnérabilités pour les boutons types S’identifier avec Facebook

Quelques semaines seulement après la découverte du bug Heartbleed, les utilisateurs moyens comme vous et moi pourraient s’inquiéter d’un autre problème très répandu qui ne sera pas facile à réparer. Il s’agit du bug « Covert Redirect » récemment révélé par Wang Jing, un étudiant en doctorat de mathématiques à l’université de technologie de Nanyang à Singapour. Le problème a été détecté au sein des célèbres protocoles Internet OpenID et OAuth. Le premier est utilisé quand vous vous identifiez dans des sites qui utilisent vos profils Google, Facebook, LinkedIn, etc. Le deuxième est utilisé quand vous vous autorisez des sites, des applications ou des services avec Facebook/G+/etc., sans révéler pour autant votre mot de passe à ces sites externes. Ces deux protocoles sont utilisés ensemble et vous pourriez bien être en train de communiquer vos informations aux mauvaises personnes.

 

hacking-home-router


La menace

Nos amis de Threatpost ont une explication du problème plus technique ainsi qu’un lien vers la recherche originale, mais nous vous épargnerons les détails inutiles et allons vous décrire le possible scénario d’attaque et ces conséquences. Premièrement, dans le cas où un utilisateur visiterait un site d’hameçonnage qui utilise le bouton « S’identifier avec Facebook ». Un site peut ressembler de prêt à un service populaire ou se faire passer pour un tout nouveau service. Ensuite, une vraie fenêtre Facebook/G+/LinkedIn s’ouvrira, demandant à l’utilisateur de rentrer son nom d’utilisateur et son mot de passe afin d’autoriser le service à accéder au profil de l’utilisateur. Enfin, l’autorisation d’utiliser le profil est envoyée au mauvais site (d’hameçonnage) en utilisant une redirection incorrecte.

 

Une vraie fenêtre Facebook/G+/LinkedIn s’ouvrira, demandant à l’utilisateur de rentrer son nom d’utilisateur et son mot de passe afin d’autoriser le service à accéder au profil de l’utilisateur.

 

En fin de compte, un cybercriminel reçoit l’autorisation d’accéder au profil de la victime (jeton OAuth) avec toutes les permissions que les applications ont en général, et dans le pire des cas, avec l’habilité d’accéder aux contacts de l’utilisateur, d’envoyer des messages, etc.




Est-ce réparé ? Pas vraiment.

Cette menace ne disparaîtra pas de si tôt, car la réparation devra être aussi bien réalisée du côté du fournisseur (Facebook, LinkedIn, Google, etc.) que du côté du client (le service ou l’application externe). Le protocole OAuth est toujours en version Beta et plusieurs fournisseurs utilisent différentes mises en place qui varient selon leur habilité de contre-attaquer l’attaque mentionnée précédemment. LinkedIn est mieux positionné pour mettre en place la réparation et gère les choses de manière plus stricte en exigeant que le développeur du service externe fournisse une « liste blanche » des redirections correctes. Pour le moment, chaque application qui utilise une autorisation LinkedIn est soit sécurisée soit non fonctionnelle. Les choses sont différentes pour Facebook qui dispose malheureusement d’un très grand nombre d’applications externes et peut-être d’une version de OAuth plus ancienne. C’est pourquoi les porte-paroles de Facebook ont informé Jing que la création d’une liste blanche « n’est pas quelque chose qui pourra être mis en place à court terme ».


Il existe de nombreux autres fournisseurs qui semblent être vulnérables (regardez la photo), donc si vous vous identifiez dans certains sites en utilisant ces services, vous devez prendre des mesures.




Votre plan d’action

Pour les plus prudents, la solution infaillible serait d’abandonner l’utilisation d’OpenID et ces fameux boutons « S’identifier avec… » pendant quelques mois. Cela vous permettra peut-être également de renforcer votre confidentialité, car autoriser ces identifications sur des réseaux sociaux rend votre activité en ligne plus facile à suivre et permet à de plus en plus de sites de lire vos données démographiques de base. Pour éviter d’avoir à mémoriser différents identifiants sur tous ces sites, commencez à utiliser un gestionnaire de mots de passe efficace. La plupart des services, de nos jours, sont équipés de clients multiplateformes et de synchronisation avec le Cloud afin de garantir un accès à vos mots de passe sur tous les ordinateurs que vous possédez.

 

Néanmoins, si vous avez l’intention de continuer à utiliser l’autorisation OpenID, il n’y a pas de danger immédiat. Vous devez juste faire attention et éviter les arnaques d’hameçonnage qui commencent typiquement par un message étrange dans votre boîte de réception ou par un lien provocateur sur Facebook et autres réseaux sociaux. Si vous vous authentifiez dans un service utilisant Facebook/Google/etc., assurez-vous que vous accédez au site de ce service en tapant l’adresse manuellement ou en utilisant un marque page, et non pas le lien contenu dans vos e-mails ou votre messagerie. Vérifiez bien la barre d’adresse afin de ne pas vous rendre sur des sites louches et ne souscrivez pas de nouveaux services avec OpenID, sauf si vous êtes certain à 100% que le service est réputé et qu’il s’agit bien du bon site. De plus, nous vous conseillons d’utiliser une solution de navigation sécurisée telle que Kaspersky Internet Security – Multi-Device qui empêchera votre navigateur de visiter des endroits dangereux tels que des sites d’hameçonnage.


Il s’agit juste de mesures de précaution, que tous les utilisateurs Internet devraient prendre chaque jour, car les menaces d’hameçonnage sont très répandues et efficaces et peuvent mener à toutes sortes de pertes numériques, y compris à la perte de numéros de carte bancaire, d’identifiants de messagerie, etc. Le bug « Covert Redirect » dans OpenID et OAuth n’est qu’une raison supplémentaire de les suivre, et ce, sans exception.

 

 

 


Articles Liés:

http://blog.kaspersky.fr/des-vulnerabilites-pour-les-boutons-types-sidentifier-avec-facebook/2984/

 

 

 

 

 

Advertisements

Amazon Website Covert Redirect Web Security Bugs Based on Facebook – Attack Simulation

amazon_1

 

Amazon Website Covert Redirect Web Security Bugs Based on Facebook – Attack Simulation

“Amazon.com, Inc. (/ˈæməzɒn/ or /ˈæməzən/) is an American electronic commerce company with headquarters in Seattle, Washington. It is the largest Internet-based retailer in the United States. Amazon.com started as an online bookstore, but soon diversified, selling DVDs, Blu-rays, CDs, video downloads/streaming, MP3 downloads/streaming, software, video games, electronics, apparel, furniture, food, toys and jewelry. The company also produces consumer electronics—notably, Amazon Kindle e-book readers, Fire tablets, Fire TV and Fire Phone — and is a major provider of cloud computing services. Amazon also sells certain low-end products like USB cables under its inhouse brand AmazonBasics. Amazon has separate retail websites for United States, United Kingdom & Ireland, France, Canada, Germany, The Netherlands, Italy, Spain, Australia, Brazil, Japan, China, India and Mexico. Amazon also offers international shipping to certain other countries for some of its products. In 2011, it had professed an intention to launch its websites in Poland and Sweden.” (Wikipedia)

 

Discover:
Discover and Reporter:
Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. (@justqdjing)
http://www.tetraph.com/wangjing/

 

 

 

(1) Vulnerability Description:

Amazon online website has a computer security bug problem. Hackers can exploit it by Covert Redirect attacks. This allow them to get users’ sensitive information by attacks such as phishing.

 

The code programming flaw exists at “redirect.html?” page with “&location” parameter, e.g.

The vulnerability can be attacked without user login. Tests were performed on Safari 6.1.6 in Mac OS X 10.7.5, IE 8 in Windows 7, Chromium version 37.0.2062.120 in Ubuntu 12.04 (281580) (64-bit).



 

 

(2) Vulnerability Details:

When a user is redirected from Amazon to another site, Amazon will check parameters “&token”. If the redirected URL’s domain is OK, Amazon will allow the redirection.

 

However, if the URLs in a redirected domain have open URL redirection vulnerabilities themselves, a user could be redirected from Amazon to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site. This is as if being redirected from Amazon directly.

 

One of the vulnerable domain is,
facebook.com

 

“Facebook is an online social networking service headquartered in Menlo Park, California. Its website was launched on February 4, 2004, by Mark Zuckerberg with his college roommates and fellow Harvard University students Eduardo Saverin, Andrew McCollum, Dustin Moskovitz and Chris Hughes. The founders had initially limited the website’s membership to Harvard students, but later expanded it to colleges in the Boston area, the Ivy League, and Stanford University. It gradually added support for students at various other universities and later to high-school students. Since 2006, anyone who is at least 13 years old is allowed to become a registered user of the website, though the age requirement may be higher depending on applicable local laws. Its name comes from a colloquialism for the directory given to it by American universities students. After registering to use the site, users can create a user profile, add other users as “friends”, exchange messages, post status updates and photos, share videos and receive notifications when others update their profiles. Additionally, users may join common-interest user groups, organized by workplace, school or college, or other characteristics, and categorize their friends into lists such as “People From Work” or “Close Friends”. Facebook had over 1.44 billion monthly active users as of March 2015. Because of the large volume of data users submit to the service, Facebook has come under scrutiny for their privacy policies. Facebook, Inc. held its initial public offering in February 2012 and began selling stock to the public three months later, reaching an original peak market capitalization of $104 billion. As of February 2015 Facebook reached a market capitalization of $212 Billion.” (Wikipedia – Facebook)

 

 

 

(3) Use one of webpages for the following tests. The webpage address is “http://inzeed.com/kaleidoscope“. Suppose that this webpage is malicious.

 

Vulnerable URL:

 

POC:

 

 

 

(4) Vulnerability Disclosure:

The vulnerability was reported to Amazon in the beginning of February 2014. Amazon has patch part of the vulnerability.

NetEase (163.com) Online Website Covert Redirect Web Security Bugs Based on Google.com

163-neteasy

 

NetEase (163.com) Online Website Covert Redirect Web Security Bugs Based on Google.com


(1) Domain:
163.com

 

 

“NetEase, Inc. (simplified Chinese: 网易; traditional Chinese: 網易; pinyin: Wǎng Yì) is a Chinese Internet company that operates 163.com, a popular web portal ranked 27 by Alexa as of April 2014. 163.com is one of the largest Chinese Internet content providers, and as such frequently appears in the top 10 domains used in spam.” (Wikipedia)

 

 

 

 

(2) Vulnerability Description:

163 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.

 

The programming code flaw occurs at page “redirect.html?” with parameter “&url”, e.g.
http://blog.163.com/pub/redirect.html?fromsubscribe&url=http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.tetraph.com%2F&ei=F-M2U-iiM4HoiAej74HADA&usg=AFQjCNHRJ5hWvXyy2WcSdJPZNEwvbMW9Zg&sig2=bdrpWjJ-87ZbUWuQivt5vA&bvm=bv.63808443,d.aGc

 

 

 

 

(2.1) When a user is redirected from 163 to another site, 163 will check whether this URL belongs to a domain on 163’s whitelist. If this is true, the redirection will be permitted.

However, if the URLs in a whitelisted domain have open URL redirection vulnerabilities themselves, a user could be redirected from 163 to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site. This is as if being redirected from 163 directly.

 

 

 

 

(2.2) Used one of webpages for the following tests. The webpage is “http://whitehatpostlike.lofter.com/“. Can suppose it is malicious.

 

Below is an example of a vulnerable domain:
google.com

 

Vulnerable URL from 163 that is related to yhd.com:
http://blog.163.com/pub/redirect.html?fromsubscribe&url=http://fusion.google.com

 

POC:
http://blog.163.com/pub/redirect.html?fromsubscribe&url=https://www.google.com/accounts/Logout?service=wise&continue=http%3A%2F%2Fgoogleads.g.doubleclick.net%2Faclk%3Fsa%3DL%26ai%3DCtHoIVxn3UvjLOYGKiAeelIHIBfLQnccEAAAQASAAUNTx5Pf4_____wFgvwWCARdjYS1wdWItMDQ2NjU4MjEwOTU2NjUzMsgBBOACAKgDAaoE5AFP0NHr5cHwFmWgKNs6HNTPVk7TWSV-CDHX83dKdGSWJ2ADoZNIxUHZwjAODRyDY_7nVtpuqSLOTef4xzVxDQ2U22MNbGak33Ur7i2jDB8LdYt9TbC3ifsXmklY5jl3Zpq4_lP7wagVfjt0–tNPPGTR96NGbxgPvfHMq9ZsTXpjhc_lPlnyGjlWzF8yn437iaxhGRwYLt_CymifLO2YaJPkCm9nLpONtUM-mstUSpKQrP2VjjaZkbDtuK0naLLBV37aYEY4TzWQi8fQGN47z4XgpinBCna91zQayZjn2wxccDCl0zgBAGgBhU%26num%3D0%26sig%3DAOD64_3Qi4qG3CRVHRI5AHSkSGuL7HJqSA%26client%3Dca-pub-0466582109566532%26adurl%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fblog

 

 

 

POC video:
https://www.youtube.com/watch?v=8QqKQml1QCE


Blog Detail:
http://tetraph.blogspot.com/2014/05/163com-netease-covert-redirect-based-on.html

 

 

(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:
Jing Wang, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. (@justqdjing)
http://tetraph.com/wangjing/

 

 

 

More Details:
http://tetraph.com/security/covert-redirect/163-com-netease-covert-redirect-based-on-google-com/
https://computertechhut.wordpress.com/2014/05/02/netease-hack/
http://webtechhut.blogspot.com/2014/05/163-bug.html
http://tetraph.blog.163.com/blog/static/234603051201452375727342/
http://diebiyi.com/articles/security/covert-redirect/163-com-netease-covert-redirect-based-on-google-com/
http://testingcode.lofter.com/post/1cd26eb9_72e71fd
http://canghaixiao.tumblr.com/post/119486195192/itinfotech-covert
https://twitter.com/tetraphibious/status/559166137343037440
https://biyiniao.wordpress.com/2014/05/28/163-exploit/
http://www.inzeed.com/kaleidoscope/covert-redirect/163-com-netease-covert-redirect-based-on-google-com/
http://computerobsess.blogspot.com/2014/09/163-website-vulnerability.html





==============

 

 

 

网易 (NetEase) 网站 隐蔽重定向 (Covert Redirect) 网络安全漏洞 基于 谷歌 (Google.com)





(1) 域名:
163.com


” 网易 (NASDAQ: NTES)是中国领先的互联网技术公司,利用最先进的互联网技术,加强人与人之间信息的交流和共享,实现“网聚人的力量”。创始人兼CEO是丁磊。在开发 互联网应用、服务及其它技术方面,网易始终保持业界的领先地位,并在中国互联网行业内率先推出了包括中文全文检索、全中文大容量免费邮件系统、无限容量免 费网络相册、免费电子贺卡站、网上虚拟社区、网上拍卖平台、24小时客户服务中心在内的业内领先产品或服务,还通过自主研发推出了一款率先取得白金地位的 国产网络游戏。网易公司推出了门户网站、在线游戏、电子邮箱、在线教育、电子商务、在线音乐、网易bobo等多种服务。” (百度百科)

 

 

(2) 漏洞描述:

163 网站有有一个计算机安全问题,黑客可以对它用隐蔽重定向 (Covert Redirect) 网络攻击。

 

 

 

这 个漏洞不需要用户登录,测试是基于微软 Windows 8 的 IE (10.0.9200.16750); Ubuntu (14.04) 的 Mozilla 火狐 (Firefox 34.0) 和 谷歌 Chromium 39.0.2171.65-0; 以及苹果 OS X Lion 10.7 的 Safari 6.16。

 

 

漏洞地点 “redirect.html?”,参数”&url”, e.g.
http://blog.163.com/pub/redirect.html?fromsubscribe&url=http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.tetraph.com%2F&ei=F-M2U-iiM4HoiAej74HADA&usg=AFQjCNHRJ5hWvXyy2WcSdJPZNEwvbMW9Zg&sig2=bdrpWjJ-87ZbUWuQivt5vA&bvm=bv.63808443,d.aGc

 

 

 

 

(2.1) 163 对跳转的页面存在一个 domain whitelist, 如果跳转的页面属于这些 domain, 则允许跳转。

 

但是这些被whitelist domain 本身可能有 URL 跳转漏洞。因此,163 用户意识不到他会被先从 163 跳转到有漏洞的网页,然后从此网页跳转到有害的网页。这与从 163 直接跳转到有害网页是一样的。

 

 

 

 

(2.2) 用了一个页面进行了测试, 页面是 “http://shellmantis.tumblr.com/“. 可以假定它是有害的。

 

下面是一个有漏洞的 domain:
google.com

 

 

163 与 google.com 有关的有漏洞的 URL:
http://blog.163.com/pub/redirect.html?fromsubscribe&url=http://fusion.google.com

 

 

POC:
http://blog.163.com/pub/redirect.html?fromsubscribe&url=https://www.google.com/accounts/Logout?service=wise&continue=http%3A%2F%2Fgoogleads.g.doubleclick.net%2Faclk%3Fsa%3DL%26ai%3DCtHoIVxn3UvjLOYGKiAeelIHIBfLQnccEAAAQASAAUNTx5Pf4_____wFgvwWCARdjYS1wdWItMDQ2NjU4MjEwOTU2NjUzMsgBBOACAKgDAaoE5AFP0NHr5cHwFmWgKNs6HNTPVk7TWSV-CDHX83dKdGSWJ2ADoZNIxUHZwjAODRyDY_7nVtpuqSLOTef4xzVxDQ2U22MNbGak33Ur7i2jDB8LdYt9TbC3ifsXmklY5jl3Zpq4_lP7wagVfjt0–tNPPGTR96NGbxgPvfHMq9ZsTXpjhc_lPlnyGjlWzF8yn437iaxhGRwYLt_CymifLO2YaJPkCm9nLpONtUM-mstUSpKQrP2VjjaZkbDtuK0naLLBV37aYEY4TzWQi8fQGN47z4XgpinBCna91zQayZjn2wxccDCl0zgBAGgBhU%26num%3D0%26sig%3DAOD64_3Qi4qG3CRVHRI5AHSkSGuL7HJqSA%26client%3Dca-pub-0466582109566532%26adurl%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fblog

 

 

 

POC 视频:
https://www.youtube.com/watch?v=8QqKQml1QCE


博客细节:
http://tetraph.blogspot.com/2014/05/163com-netease-covert-redirect-based-on.html

 

 

 

 

(3) 什么是隐蔽重定向?

隐蔽重定向 (Covert Redirect) 是一个计算机网络安全漏洞。这个漏洞发布于 2014年5月。漏洞成因是网络应用软件对跳转到合作者的跳转没有充分过滤。这个漏洞经常利用第三方网站 (包括合作网站) 的公开重定向 (Open Redirect) 或者 跨站脚本漏洞 (XSS – Cross-site Scripting) 问题。

 

隐蔽重定向也对单点登录 (single sign-on) 有影响。最初发布的是对两款常用登录软件 OAuth 2.0 和 OpenID 的影响。黑客可以利用真实的网站进行网络钓鱼,从而窃取用户敏感信息。几乎所用提供 OAuth 2.0 和 OpenID 服务的网站都被影响。隐蔽重定向还可以和 跨站请求伪造 (CSRF – Cross-site Request Forgery) 一起利用。

 

 

 

Serious security flaw in OAuth, OpenID discovered

Following in the steps of the OpenSSL vulnerability Heartbleed, A serious Covert Redirect vulnerability related to OAuth 2.0 and OpenID has been found. Almost all major providers of OAuth 2.0 and OpenID are affected, such as Facebook, Google, Yahoo, LinkedIn, Microsoft, Paypal, GitHub, QQ, Taobao, Weibo, VK, Mail.Ru, Sohu, etc.

 

Wang Jing, a Ph.D. student at the Nanyang Technological University in Singapore, discovered that the serious vulnerability “Covert Redirect” flaw can masquerade as a log-in popup based on an affected site’s domain. Covert Redirect is based on a well-known exploit parameter.

 

For example, someone clicking on a malicious phishing link will get a popup window in Facebook, asking them to authorize the app. Instead of using a fake domain name that’s similar to trick users, the Covert Redirect flaw uses the real site address for authentication.

 

If a user chooses to authorize the log in, personal data (depending on what is being asked for) will be released to the attacker instead of to the legitimate website. This can range from email addresses, birth dates, contact lists, and possibly even control of the account.

 

Regardless of whether the victim chooses to authorize the app, he or she will then get redirected to a website of the attacker’s choice, which could potentially further compromise the victim.

 

Wang says he has already contacted Facebook and has reported the flaw, but was told that the company “understood the risks associated with OAuth 2.0,” and that “short of forcing every single application on the platform to use a whitelist,” fixing this bug was “something that can’t be accomplished in the short term.”

 

Facebook isn’t the only site affected. Wang says he has reported this to Google, LinkedIn, and Microsoft, which gave him various responses on how they would handle the matter.

 

covert_redirect_logo_tetraph


Google (which uses OpenID) told him that the problem was being tracked, while LinkedIn said that the company has published a blog on the matter. Microsoft, on the other hand, said an investigation had been done and that the vulnerability existed on the domain of a third party and not on its own sites.

“Patching this vulnerability is easier said than done. If all the third-party applications strictly adhere to using a whitelist, then there would be no room for attacks,” said Wang.

 

“However, in the real world, a large number of third-party applications do not do this due to various reasons. This makes the systems based on OAuth 2.0 or OpenID highly vulnerable,” he added.

 

LinkedIn engineer Shikha Sehgal wrote a blog post about the creation of a whitelist for the site more than a month before Wang published his findings.

 

“In order to make the LinkedIn platform even more secure, and so we can comply with the security specifications of OAuth 2, we are asking those of you who use OAuth 2 to register your application’s redirect URLs with us by April 11, 2014,” she said.

 

Sehgal did not explicitly say that the measure was in response to a flaw in OAuth 2, but the social network did confirm to CNET that the vulnerability that Wang detailed is the same one that inspired the blog post.

 

PayPal also has addressed the flaw.

“When PayPal implemented OAuth2.0/OpenID, we engineered additional security measures to protect our merchants and customers. These measures protect PayPal customers from this specific OAuth2.0/OpenID vulnerability,” James Barrese, PayPal’s CTO, said in a blog post on Friday. PayPal declined to add details about those measures.

(Article Mainly from Cnet.com)

 

 

 

Related Articles:

VK.com OAuth 2.0 Service Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

Screenshot from 2015-06-27 14:36:59

 

VK.com OAuth 2.0 Service Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

 




(1) Domain:
vk.com

 

“VK (originally VKontakte, Russian: ВКонтакте, literally “in touch”) is the largest Russian social network in Europe. It is available in several languages, but is especially popular among Russian-speaking users, particularly in Russia, Ukraine, Belarus, Kazakhstan and Uzbekistan. Like other social networks, VK allows users to message each other publicly or privately, to create groups, public pages and events, share and tag images, audio and video, and to play browser-based games. As of November 2014, VK had at least 280 million accounts. VK is ranked 22 (as of November 1, 2014) in Alexa’s global Top 500 sites and is the second most visited website in Russia, after Yandex. According to eBizMBA Rank, it is the 8th most popular social networking site in the world. As of January 2015, VK had an average of 70 million daily users.” (Wikipedia)

 

 

 

 

(2) Vulnerability Description:

VK.com 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 Detail:

VK’s OAuth system is susceptible to Attacks. More specifically, the authentication of parameter “&redirct_uri” in OAuth system is insufficient. It can be misused to design Open Redirect Attacks to VK.

 

At the same time, it can be used to collect sensitive information of both third-party app and users by using the following parameters (sensitive information is contained in HTTP header.),

“&response_type”=code,token…

“&scope”=basic information…

 

 

It increases the likelihood of successful Open Redirect Attacks to third-party websites, too.

 

The vulnerabilities occurs at page “/authorize?” with parameter “&redirect_uri”, e.g.

http://oauth.vk.com/authorize?response_type=code&scope=12&client_id=2852163&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin.do%3FreturnUrl%3Dhttp%253A%252F%252Fwww.tetraph.com%252Fessayjeans%252Fpoems%252Ffish_water.html [1]

 

 

Before acceptance of third-party application:

 

When a logged-in VK 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 VK and clicks the URL ([1]) above, the same situation will happen upon login.

 

After acceptance of third-party application:

 

A logged-in VK 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.1) VK 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 VK 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 VK directly. The number of VK’s OAuth client websites is so huge that such Attacks could be commonplace.

 

Before acceptance of the third-party application, VK’s OAuth 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 VK’s authentication system and attack more easily.

 

 

 

(2.2) Used one of webpages for the following tests. The webpage is “http://diebiyi.com/articles/“. 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:
kp.ru

 

Vulnerable URL in this domain:
http://my.kp.ru/login.do?returnUrl=http%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Ffish_water.html

 

Vulnerable URL from VK that is related to kp.ru:
http://oauth.vk.com/authorize?response_type=code&scope=12&client_id=2852163&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin%2Fvkontakte.do%3FreturnUrl%3Dhttp%253A%252F%252Fwww.kp.ru%252F

http://api.vk.com/oauth/authorize?client_id=2852163&redirect_uri=http://my.kp.ru/login.do?returnUrl=http%3A%2F%2Fwww.kp.ru&display=page&scope=wall,offline

 

POC:
http://oauth.vk.com/authorize?response_type=code&scope=12&client_id=2852163&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin.do%3FreturnUrl%3Dhttp%253A%252F%252Fwww.tetraph.com%252Fessayjeans%252Fpoems%252Ffish_water.html

http://api.vk.com/oauth/authorize?client_id=2852163&redirect_uri=http://my.kp.ru/login.do?returnUrl=http%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Ffish_water.html&display=page&scope=wall,offline

 

 

 

POC Video:
https://www.youtube.com/watch?v=3gNhi8h2AQY

 

Blog Detail:
http://www.tetraph.com/blog/covert-redirect/vk-com-oauth-2-0-covert-redirect-vulnerability/



 

(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, such as 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)
http://tetraph.com/wangjing/




 

 

More Details:
http://tetraph.com/security/covert-redirect/vk-com-oauth-2-0-covert-redirect-vulnerability/
https://itswift.wordpress.com/2014/05/02/vk-exploit/
http://tetraph.blogspot.com/2014/05/vkcom-oauth-20-covert-redirect.html
https://twitter.com/tetraphibious/status/559166795525799936
http://frenchairing.blogspot.fr/2014/05/vk-exploit.html
http://whitehatview.tumblr.com/post/119487379761/securitypost
http://webtech.lofter.com/post/1cd3e0d3_706aec6
http://tetraph.blog.163.com/blog/static/234603051201445111630165/
http://www.inzeed.com/kaleidoscope/covert-redirect/vk-com-oauth-2-0-covert-redirect-vulnerability/
https://itinfotechnology.wordpress.com/2014/05/07/vk-bug/
http://russiapost.blogspot.ru/2014/05/vk-exploit.html

 

 

 

=================

 

 

 

 

ВКонтакте OAuth 2.0 Ошибки служба Скрытое перенаправление веб-безопасности (утечка информации и открытого редирект)

 

 

 

(1) Домен:
vk.com

 

“«ВКонта́кте» (vk.com) — социальная сеть, принадлежащая Mail.Ru Group. По данным SimilarWeb, «ВКонтакте» является первым по популярности сайтом в России и на Украине, 6-м — в мире. По данным Alexa Internet, второй по популярности сайт в России и на Украине, третий — в Белоруссии, 24-й — в мире. Проект запущен 10 октября 2006 года. Ресурс изначально позиционировал себя в качестве социальной сети студентов и выпускников российских вузов, позднее стал называть себя «современным, быстрым и эстетичным способом общения в сети». В январе 2014 года ежедневная аудитория «ВКонтакте» составляла около 60 миллионов человек, а в январе 2015 года — 70 миллионов человек в день. Генеральный директор (с 2014 года) — Борис Добродеев, сын Олега Добродеева — генерального директора Всероссийской государственной телевизионной и радиовещательной компании.”. (ru.wikipedia)

 

 

 

(2) Уязвимость Описание:

 

Веб-приложение ВКонтакте имеет проблемы компьютерной безопасности. Хакер может использовать его Скрытое перенаправление кибератак.

 

Уязвимости могут быть атакованы без входа пользователя в систему. Испытания проводились на Microsoft IE (10.0.9200.16750) в Windows 8, Mozilla Firefox (34,0) и Google Хром 39.0.2171.65-0 ubuntu0.14.04.1.1064 (64-бит) Ubuntu (14.04), Apple Safari 6.1.6 от Mac OS X Lion 10.7.

 

 

 

(2.1) Уязвимость деталь:

Система OAuth ВКонтакте подвержен атакам. Более конкретно, аутентификация параметра “& redirct_uri” в системе OAuth является недостаточным. Это может быть неправильно для разработки открытым перенаправление атак на VK.

 

В то же время, он может быть использован, чтобы собирать конфиденциальную информацию как стороннего приложения и пользователей, используя следующие параметры (секретная информация, содержащаяся в заголовке HTTP.),

“& Response_type” = код маркера …

“& Область” = базовая информация …

 

Это увеличивает вероятность успешных атак Открыть перенаправление на сторонних веб-сайтах, тоже.

 

Уязвимости происходит на странице “/ разрешить?” с параметром “& redirect_uri”, например
http://oauth.vk.com/authorize?response_type=code&scope=12&client_id=2852163&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin.do%3FreturnUrl%3Dhttp%253A%252F%252Fwww.tetraph.com%252Fessayjeans%252Fpoems%252Ffish_water.html [1]

 

 

 

До принятия сторонних применения:

 

Когда вошедшего в систему пользователя ВКонтакте нажимает URL ([1]) выше, то он / она будет предложено согласия, в том, чтобы позволить сторонних веб-сайт для получения его / ее информацию. Если пользователь нажимает кнопку ОК, он / она будет затем перенаправляется на URL, назначенного параметра “& redirect_uri».

 

Если пользователь не вошел на VK и нажимает URL ([1]) выше, такая же ситуация произойдет при входе.

 

После принятия стороннем приложении:

 

не вошедшего в систему пользователя ВКонтакте больше не будет предложено для согласия и может быть перенаправлен на веб-страницу, контролируемой злоумышленником, когда он / она нажимает URL ([1]).

 

Для пользователя, который не авторизованы атака еще может быть завершена после всплывающая страница, что побуждает его / ее войти.

 

 

 

(2.1.1) ВК, как правило, позволяют все адреса, которые принадлежат к сфере уполномоченным сторонних веб-сайт. Тем не менее, эти URL-адреса могут быть склонны к манипуляциям. Например, параметр “& redirect_uri” в URL, как предполагается, будет установлен сторонних веб-сайтах, но злоумышленник может изменить его значение, чтобы атак.

 

Следовательно, пользователь может быть перенаправлен от VK с уязвимой URL в этой области первым, а затем будет перенаправлен из этого уязвимого сайта на вредоносный сайт неохотно. Это как если бы пользователь перенаправляется от VK напрямую. Количество OAuth клиентских сайтов В.К. настолько огромен, что такие атаки могут быть обычным явлением.

 

До принятия стороннего приложения, система OAuth ВКонтакте делает редирект кажутся более надежными и потенциально может увеличить вероятность успешных атак Открыть перенаправление сторонних веб-сайта.

 

После того, как пользователь принимает заявки, нападавшие могли полностью обойти систему аутентификации ВКонтакте и нападение легче.

 

 

 

 

(2.2) Используется один из веб-страниц для следующих испытаний. Веб-страница “http://diebiyi.com/articles/“. Можно предположить, что это злая и содержит код, который собирают конфиденциальную информацию как сторонних приложений и пользователей.

 

Ниже пример уязвимой области стороннего:
kp.ru

 

 

Уязвимые URL в этой области:
http://my.kp.ru/login.do?returnUrl=http%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Ffish_water.html

 

 

Уязвимые URL из ВК, что это связано с kp.ru:
http://oauth.vk.com/authorize?response_type=code&scope=12&client_id=2852163&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin%2Fvkontakte.do%3FreturnUrl%3Dhttp%253A%252F%252Fwww.kp.ru%252F

http://api.vk.com/oauth/authorize?client_id=2852163&redirect_uri=http://my.kp.ru/login.do?returnUrl=http%3A%2F%2Fwww.kp.ru&display=page&scope=wall,offline

 

 

СПЭ:
http://oauth.vk.com/authorize?response_type=code&scope=12&client_id=2852163&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin.do%3FreturnUrl%3Dhttp%253A%252F%252Fwww.tetraph.com%252Fessayjeans%252Fpoems%252Ffish_water.html

http://api.vk.com/oauth/authorize?client_id=2852163&redirect_uri=http://my.kp.ru/login.do?returnUrl=http%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Ffish_water.html&display=page&scope=wall,offline

 

 

СПЭ Видео:
https://www.youtube.com/watch?v=3gNhi8h2AQY

 

Блог деталь:
http://www.tetraph.com/blog/covert-redirect/vk-com-oauth-2-0-covert-redirect-vulnerability/

 

 

 

(3) Что такое Скрытое перенаправление?

Скрытое перенаправление класс ошибок безопасности, описанных мая 2014 Это приложение, которое принимает параметр и перенаправляет пользователя на значение параметра без достаточного обоснования. Это часто делает использование открытого Redirect и XSS (Cross-Site Scripting) уязвимостей в сторонних приложениях.

 

Скрытое перенаправление также связано с единого входа, такие как OAuth и OpenID. Хакер может использовать это, чтобы украсть конфиденциальную информацию пользователей. Почти все OAuth 2.0 и OpenID-провайдеров по всему миру страдают. Скрытое перенаправление может работать вместе с CSRF (Cross-Site Request подлог), а также.

 

 

 

Откройте для себя и Докладчик:
Ван Цзин, Отдел математических наук (MAS), школа физико-математических наук (ВПУ), Nanyang технологический университет (НТУ), Сингапур. (@justqdjing)
http://tetraph.com/wangjing/

 

 

 

 

Подробнее:
http://tetraph.com/security/covert-redirect/vk-com-oauth-2-0-covert-redirect-vulnerability/
https://itswift.wordpress.com/2014/05/02/vk-exploit/
http://tetraph.blogspot.com/2014/05/vkcom-oauth-20-covert-redirect.html
https://twitter.com/tetraphibious/status/559166795525799936
http://frenchairing.blogspot.fr/2014/05/vk-exploit.html
http://whitehatview.tumblr.com/post/119487379761/securitypost
http://webtech.lofter.com/post/1cd3e0d3_706aec6
http://tetraph.blog.163.com/blog/static/234603051201445111630165/
http://www.inzeed.com/kaleidoscope/covert-redirect/vk-com-oauth-2-0-covert-redirect-vulnerability/
https://itinfotechnology.wordpress.com/2014/05/07/vk-bug/
http://russiapost.blogspot.ru/2014/05/vk-exploit.html

 

 

OAuth and OpenID Users Threatened by New Security Flaw, Covert Redirect

heartbleed_bug_hackers

 

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://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/

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/

 

 

 

 

 

Paypal Online Website OAuth 2.0 Covert Redirect (OpenIDconnect) Web Security Bugs (Information Leakage & Open Redirect)

paypal_big-1

Paypal Online Website OAuth 2.0 Covert Redirect (OpenIDconnect) Web Security Bugs (Information Leakage & Open Redirect)




(1) Domain:
paypal.com

 

“PayPal is an American worldwide online payments system. Online money transfers serve as electronic alternatives to traditional paper methods like checks and money orders. PayPal is one of the world’s largest internet payment companies.The company operates as an acquirer, performing payment processing for online vendors, auction sites and other commercial users, for which it charges a fee. Established in 1998, PayPal (NASDAQ: PYPL) had its IPO in 2002, and became a wholly owned subsidiary of eBay later that year. In 2014, PayPal moved $228 billion in 26 currencies across more than 190 nations, generating a total revenue of $7.9 billion (44% of eBay’s total profits). The same year, eBay announced plans to spin-off PayPal into an independent company the following year.” (Wikipedia)

 

 

 

 

(2) Vulnerability Description:

Paypal 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 Detail:

PayPal’s OAuth 2.0 system is susceptible to Attacks. More specifically, the authentication of parameter “&redirct_uri” in OAuth 2.0 system is insufficient. It can be misused to design Open Redirect Attacks to PayPal.

 

 

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”=code,token…

“&scope”=email,user_birthday,user_likes…

 

 

It increases the likelihood of successful Open Redirect Attacks to third-party websites, too.

 
 
 
 

 

Before acceptance of third-party application:

When a logged-in PayPal 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 PayPal and clicks the URL ([1]) above, the same situation will happen upon login.

 
 

 

After acceptance of third-party application:

A logged-in PayPal 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.1) PayPal 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 PayPal 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 PayPal directly. The number of PayPal’s OAuth 2.0 client websites is so huge that such Attacks could be commonplace.

 

 

Before acceptance of the third-party application, PayPal’s OAuth 2.0 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 PayPal’s authentication system and attack more easily.

 

 

It might be of PayPal’s interest to patch up against such attacks. 

 
 
 

 

 

 

(2.2) Used one of webpages for the following tests. The webpage is “http://essayjeanslike.lofter.com/“. 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:
constantcontact.com

 
 
 
 
 



POC Video:
https://www.youtube.com/watch?v=TVtLA1YzIBs


Blog Detail:
http://tetraph.blogspot.com/2014/05/paypal-oauth-20-openidconnect-covert.html





(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. After Covert Redirect was published, it is kept in some common databases such as SCIP, OSVDB, Bugtraq, and X-Force. Its scipID is 13185, while OSVDB reference number is 106567. Bugtraq ID: 67196.  X-Force reference number is 93031.

 
 
 
 



 

Discover and Reporter:
Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. 
(@justqdjing)
http://tetraph.com/wangjing/









Related Articles:
http://tetraph.com/security/covert-redirect/paypal-oauth-2-0-openidconnect-covert-redirect-vulnerability/
http://ithut.tumblr.com/post/119493112323/securitypost-sicherheitslucke-in-oauth-2-0-und
https://twitter.com/tetraphibious/status/559164333721001984
http://www.inzeed.com/kaleidoscope/covert-redirect/paypal-oauth-2-0-openidconnect-covert-redirect-vulnerability/
http://computerobsess.blogspot.sg/2014/05/paypal-bug.html
https://hackertopic.wordpress.com/2014/05/01/paypal-covert-redirect/
http://ittechnology.lofter.com/post/1cfbf60d_72e61e0
http://securityrelated.blogspot.com/2014/05/paypal-bug.html
http://blog.163.com/tetraph/blog/static/23460305120144612635422
https://webtechwire.wordpress.com/2014/05/02/paypal-covert-redirect/