Sicherheitslücke in OAuth 2.0 und OpenID gefunden

covert_redirect3

Wang Jing, Student an der Nanyang Technological University in Singapur, hat nach dem Bekanntwerden des OpenSSL-Heartbleed-Lecks, eine weitere schwere Sicherheitslücke entdeckt, diesmal in den Authentifizierungsmethoden OAuth 2.0 und OpenID. Die als “Covert Redirect” (“Heimliche Umleitung”) benannte Sicherheitslücke ermöglicht es Angreifern, dem Nutzer einen echt aussehenden Login-Screen unterzujubeln und sich so Zugriff auf die bereitgestellten Daten zu verschaffen. Das gefährliche daran: Die Sicherheitslücke besitzt – anders als bisher bekannte Fishing-Versuche – eine legitime Domainadresse, kann also über einen Blick in die URL-Zeile des Browsers nicht oder nur sehr schwer entlarvt werden. Auf OAuth 2.0 und OpenID bieten inzwischen zahlreiche Webdienste um einen direkten Login in andere Dienste und Apps zu ermöglichen, darunter auch Google, Facebook, Microsoft und Co.

 

So ist es möglich, dem Nutzer eine Mail mit einem speziell präparierten Link zukommen zu lassen, ein Klick auf diesen öffnet eben wie gesagt eine legitime Adresse samt entsprechendem Logo. Autorisiert der Nutzer dann diese Anfrage und loggt sich in den Dienst ein, so werden die Daten nicht an die vermeintliche App weitergeleitet, sondern gelangen eben in den Besitz des Angreifers. Je nachdem, welche Daten abfragt werden, bekommt dieser somit also E-Mail-Adresse, Geburtsdatum, Kontaktlisten und dergleichen. Ebenso ist es möglich, den Nutzer nach dem Login auf eine beliebige Webseite, welche unter Umständen Malware verbreitet, weiterzuleiten.



covert-redirect-11

 

covert-redirect-12


Die Lösung des Problems könnte aber – wenn es überhaupt einmal eine geben sollte – eine langwierige Sache sein. Wang Jing hat bereits etliche größere Anbieter der Loginmethoden angeschrieben und über die gefundene Sicherheitslücke aufgeklärt, hierbei gab es jedoch unterschiedliche Aussagen. Im Hause Google beobachtet man das Problem, Microsoft ist sich keiner Schuld bewusst und schiebt die Sicherheitslücke an Drittanbieter ab. Lediglich Facebook scheint hier ehrlich zu sein und gibt an, dass es sich dabei um ein grundsätzliches Problem von OAuth 2.0 und OpenID handelt – möchte man nicht eine umfangreiche Whitelist mit sämtlichen nicht-schädlichen Apps pflegen, ist die Sicherheitslücke nicht “mal eben so” zu beheben. Im Grunde dürften sich sämtliche Gegenmaßnahmen negativ auf die Nutzererfahrung auswirken, was natürlich keiner der Dienste in Kauf nehmen möchte – und so bleibt es hierbei scheinbar beim “kleineren Übel” für die Anbieter.

So bleibt eigentlich nur die Möglichkeit, auf OAuth 2.0 oder OpenID als Login-Methode für Drittanbieter Dienste und Apps zu verzichten oder genauestens darauf zu achten, auf was man klickt. Hat man keine explizite Autorisierung angestoßen, sollte man die geöffneten Tabs umgehend schließen und darauf hoffen, dass sich nicht doch irgendwo ein falscher Link eingepfercht hat.



Quelle:
http://www.blogtogo.de/sicherheitsluecke-in-oauth-2-0-und-openid-gefunden/




Google Online Service OpenID Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

google2

 

 

Google Online Service OpenID Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)



(1) Domain:
google.com

 

“Google has been estimated to run more than one million servers in data centers around the world (as of 2007). It processes over one billion search requests and about 24 petabytes of user-generated data each day (as of 2009). In December 2013, Alexa listed google.com as the most visited website in the world. Numerous Google sites in other languages figure in the top one hundred, as do several other Google-owned sites such as YouTube and Blogger. Its market dominance has led to prominent media coverage, including criticism of the company over issues such as search neutrality, copyright, censorship, and privacy.” (Wikipedia)

 

 

 

 

 

(2) Vulnerability Description:

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

Google’s OpenID system is susceptible to Attacks. More specifically, the authentication of parameter “&openid.return_to” in OpenID system is insufficient. It can be misused to design Open Redirect Attacks to Google.

 

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

 

Google replies “Thanks for the reporting this issue. we’re already tracking[the vulnerability] …”

 

 

The vulnerabilities occurs at page “/accounts/o8/ud?” with parameter “&openid.return_to”, e.g.
https://www.google.com/accounts/o8/ud?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.return_to=http%3A%2F%2Fwww.rhogroupee.com%2FopenIdRp%3Fredirect%3Dhttp%253A%252F%252Fwww.rhogroupee.com%252Fjoin%252Fcontext%252FGENERAL%252Fredirect%252Fhttp%25253A%25252F%25252Fwww.tetraph.com%25252Fessayjeans%25252Fpoems%25252Fdistance.html&openid.realm=http%3A%2F%2Fwww.rhogroupee.com%2FopenIdRp&openid.aOpenIDc_handle=1.AMlYA9UWc8Nk_QfiFEpKcE9A7qm0ErEkNLgQcbOwTR_aLdEyFS4ybtZQ_V9-4ARxUqsGIpPFtRd9Mw&openid.mode=checkid_setup&openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1&openid.ext1.optional=nickname%2Cemail%2CemailVerified%2Cdob%2Cgender%2Ccountry&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fsreg%2F1.0&openid.sreg.optional=nickname%2Cemail%2CemailVerified%2Cdob%2Cgender%2Ccountry&openid.ns.ext3=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ext3.mode=fetch_request&openid.ext3.type.Username=http%3A%2F%2Fschema.openid.net%2FnamePerson%2Ffriendly&openid.ext3.type.Email=http%3A%2F%2Fschema.openid.net%2Fcontact%2Femail&openid.ext3.type.Birth+date=http%3A%2F%2Fschema.openid.net%2FbirthDate&openid.ext3.type.Gender=http%3A%2F%2Fschema.openid.net%2Fperson%2Fgender&openid.ext3.type.Country=http%3A%2F%2Fschema.openid.net%2Fcontact%2Fcountry%2Fhome&openid.ext3.required=Username%2CEmail%2CBirth+date%2CGender%2CCountry [1]

 

 

Before acceptance of third-party application:

 

When a logged-in Google 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 “&openid.return_to”.

 

If a user has not logged onto Google and clicks the URL ([1]) above, the same situation will happen upon login.

 

After acceptance of third-party application:

 

A logged-in Google 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) Google 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 “&openid.return_to” 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 Google 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 Google directly. The number of Google’s OpenID client websites is so huge that such Attacks could be commonplace.

 

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

 

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

 

 

 

 

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

 

Below is an example of a vulnerable third-party domain:
rhogroupee.com

 

 

Vulnerable URL in this domain:
http://www.rhogroupee.com/join/context/GENERAL/redirect/http%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fdistance.html

 

 

Vulnerable URL from Google that is related to rhogroupee.com:
https://www.google.com/accounts/o8/ud?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.return_to=http%3A%2F%2Fwww.rhogroupee.com%2FopenIdRp%3Fredirect%3Dhttp%253A%252F%252Fwww.rhogroupee.com%252Fuser-social-network-login%252FauthProvider%252F10%252Fredirect%252Fhttp%25253A%25252F%25252Fwww.rhogroupee.com%25252Fabout&openid.realm=http%3A%2F%2Fwww.rhogroupee.com%2FopenIdRp&openid.aOpenIDc_handle=1.AMlYA9UWc8Nk_QfiFEpKcE9A7qm0ErEkNLgQcbOwTR_aLdEyFS4ybtZQ_V9-4ARxUqsGIpPFtRd9Mw&openid.mode=checkid_setup&openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1&openid.ext1.optional=nickname%2Cemail%2CemailVerified%2Cdob%2Cgender%2Ccountry&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fsreg%2F1.0&openid.sreg.optional=nickname%2Cemail%2CemailVerified%2Cdob%2Cgender%2Ccountry&openid.ns.ext3=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ext3.mode=fetch_request&openid.ext3.type.Username=http%3A%2F%2Fschema.openid.net%2FnamePerson%2Ffriendly&openid.ext3.type.Email=http%3A%2F%2Fschema.openid.net%2Fcontact%2Femail&openid.ext3.type.Birth+date=http%3A%2F%2Fschema.openid.net%2FbirthDate&openid.ext3.type.Gender=http%3A%2F%2Fschema.openid.net%2Fperson%2Fgender&openid.ext3.type.Country=http%3A%2F%2Fschema.openid.net%2Fcontact%2Fcountry%2Fhome&openid.ext3.required=Username%2CEmail%2CBirth+date%2CGender%2CCountry

 

 

POC:
https://www.google.com/accounts/o8/ud?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.return_to=http%3A%2F%2Fwww.rhogroupee.com%2FopenIdRp%3Fredirect%3Dhttp%253A%252F%252Fwww.rhogroupee.com%252Fjoin%252Fcontext%252FGENERAL%252Fredirect%252Fhttp%25253A%25252F%25252Fwww.tetraph.com%25252Fessayjeans%25252Fpoems%25252Fdistance.html&openid.realm=http%3A%2F%2Fwww.rhogroupee.com%2FopenIdRp&openid.aOpenIDc_handle=1.AMlYA9UWc8Nk_QfiFEpKcE9A7qm0ErEkNLgQcbOwTR_aLdEyFS4ybtZQ_V9-4ARxUqsGIpPFtRd9Mw&openid.mode=checkid_setup&openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1&openid.ext1.optional=nickname%2Cemail%2CemailVerified%2Cdob%2Cgender%2Ccountry&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fsreg%2F1.0&openid.sreg.optional=nickname%2Cemail%2CemailVerified%2Cdob%2Cgender%2Ccountry&openid.ns.ext3=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ext3.mode=fetch_request&openid.ext3.type.Username=http%3A%2F%2Fschema.openid.net%2FnamePerson%2Ffriendly&openid.ext3.type.Email=http%3A%2F%2Fschema.openid.net%2Fcontact%2Femail&openid.ext3.type.Birth+date=http%3A%2F%2Fschema.openid.net%2FbirthDate&openid.ext3.type.Gender=http%3A%2F%2Fschema.openid.net%2Fperson%2Fgender&openid.ext3.type.Country=http%3A%2F%2Fschema.openid.net%2Fcontact%2Fcountry%2Fhome&openid.ext3.required=Username%2CEmail%2CBirth+date%2CGender%2CCountry

 

 

 

 

(2.3) The following URL have the same vulnerabilities.
https://accounts.google.com/o/openid2/auth?openid.ns=http://specs.openid.net/auth/2.0&openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select&openid.identity=http://specs.openid.net/auth/2.0/identifier_select&openid.return_to=http://www.rhogroupee.com/openIdRp?redirect%3Dhttp%253A%252F%252Fwww.rhogroupee.com%252Fuser-social-network-login%252FauthProvider%252F10%252Fredirect%252Fhttp%25253A%25252F%25252Fwww.rhogroupee.com&openid.realm=http://www.rhogroupee.com/openIdRp&openid.aOpenIDc_handle=1.AMlYA9VvMT-wTbwpTyi–6hxkiyJYb7Oou8Wt0nqDPzqfNZBqTsNOXWhVorwkAAIZmnQXwswhZYZYQ&openid.mode=checkid_setup&openid.ns.ext1=http://openid.net/extensions/sreg/1.1&openid.ext1.optional=nickname,email,emailVerified,dob,gender,country&openid.ns.sreg=http://openid.net/sreg/1.0&openid.sreg.optional=nickname,email,emailVerified,dob,gender,country&openid.ns.ext3=http://openid.net/srv/ax/1.0&openid.ext3.mode=fetch_request&openid.ext3.type.Username=http://schema.openid.net/namePerson/friendly&openid.ext3.type.Email=http://schema.openid.net/contact/email&openid.ext3.type.Birth+date=http://schema.openid.net/birthDate&openid.ext3.type.Gender=http://schema.openid.net/person/gender&openid.ext3.type.Country=http://schema.openid.net/contact/country/home&openid.ext3.required=Username,Email,Birth+date,Gender,Country

 

 

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

 

Blog Detail:
http://tetraph.blogspot.com/2014/05/google-openid-covert-redirect.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/google-openid-covert-redirect-vulnerability/
https://twitter.com/tetraphibious/status/559169163394940929
https://hackertopic.wordpress.com/2014/08/06/google-service-exploit/
http://www.inzeed.com/kaleidoscope/covert-redirect/google-openid-covert-redirect-vulnerability/
http://tetraph.blog.163.com/blog/static/23460305120144385547287/
http://securitypost.tumblr.com/post/119439859067/itinfotech-id-oauth
http://securityrelated.blogspot.com/2014/06/google-web-service-bug.html
http://whitehatpost.lofter.com/post/1cc773c8_706b637
https://tetraph.wordpress.com/2014/07/11/google-service-exploit/
http://computerobsess.blogspot.com/2014/06/google-web-service-bug.html

Sohu OAuth 2.0 Service Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

Screenshot from 2015-06-28 21:09:09

 

Sohu OAuth 2.0 Service Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)




(1) Domain:

sohu.com

 

“Sohu, Inc. (Chinese: 搜狐; pinyin: Sōuhú; literally: “Search-fox”) is a Chinese Internet company headquartered in the Sohu Internet Plaza in Haidian District, Beijing. This company and its subsidiaries offer advertising, a search engine, on-line multiplayer gaming and other services. For the fiscal year ended December 31, 2007, Sohu Inc.’s revenues increased 41% to $188.9M. Net income increased 31% to $35M. Sohu was ranked as the world’s 3rd and 12th fastest growing company by Fortune in 2009 and 2010 respectively. As of August 2011, Sohu is the 44th overall in Alexa’s internet rankings.” (Wikipedia)

 

 

 

 

(2) Vulnerability Description:

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

Sohu’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 Sohu.

 

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

“&scope”=get_user_info%2Cadd_share…

 

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

 

 

Before acceptance of third-party application:

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

 

 

After acceptance of third-party application:

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

 

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

 

 

 

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

 

 

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




Blog Detail:
http://tetraph.blogspot.com/2014/05/sohus-oauth-20-covert-redirect.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, 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:
Jing Wang, 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/sohus-oauth-2-0-covert-redirect
https://inzeed.wordpress.com/2014/07/28/sohu-exploit/
https://twitter.com/buttercarrot/status/558906629056249856
http://diebiyi.com/articles/security/covert-redirect/sohus-oauth-bug
http://russiapost.blogspot.com/2014/07/sohu-hacking.html
http://shellmantis.tumblr.com/post/119492886806/securitypost
http://xingzhehong.lofter.com/post/1cfd0db2_706af13
https://itinfotechnology.wordpress.com/2014/07/07/sohu-attack/
http://www.inzeed.com/kaleidoscope/covert-redirect/sohus-oauth-2-0
http://tetraph.blog.163.com/blog/static/23460305120144714756937/
http://securityrelated.blogspot.com/2014/08/sohu-service-attack.html

 

 

 

===========

 

 

搜狐 网站 OAuth 2.0 隐蔽重定向 (Covert Redirect) 网络安全漏洞 (信息泄漏 & 公开重定向) 





(1) 域名:
sohu.com



” 搜狐(NASDAQ:SOHU),是一家互联网中文门户网站。1995年,搜狐创始人张朝阳从美国麻省理工学院毕业回到中国,利用风险投资创建了爱特信信 息技术有限公司,1998年正式推出搜狐网。2000年,搜狐在美国纳斯达克证券市场上市。搜狐开发的产品有搜狗拼音输入法、搜狗五笔输入法、搜狗音乐 盒、搜狗浏览器、搜狐彩电、独立的搜索引擎搜狗和网游门户畅游。搜狐是2008年北京奥林匹克运动会唯一的互联网赞助商,也是奥林匹克运动会历史上第一个 互联网内容的赞助商。” (百度百科)







(2) 漏洞描述:

搜狐 网站有有一个计算机安全问题,黑客可以对它进行隐蔽重定向 (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。




 


(2.1) 漏洞细节:

Sohu 的 OAuth 2.0 系统可能遭到攻击。更确切地说, Sohu 对 OAuth 2.0 系统的 parameter “&redirect_uri“ 验证不够充分。可以用来构造对 Sohu 的 URL跳转 攻击。

 

 

与此同时,这个漏洞可以用下面的参数来收集第三方 App 和 用户 的敏感信息(敏感信息包含在 HTTP header里),

“&response_type”=sensitive_info,token,code…

“&scope”=email,name…

 

 

它也增加了对第三方网站 URL跳转 攻击的成功率。

 

 

漏洞地点 “/oauth2/authorize?”,参数”&redirect_uri”, e.g.

https://api.t.sohu.com/oauth2/authorize?client_id=TP4vefRdCFUEFhrNpMnQ&scope=basic&response_type=code&redirect_uri=http%3A%2F%2Fnews.cn%2Fsitecb%2Fsohu.do&state=http://my.xuan.news.cn/main.do__20 [1]

 

 

 

同意三方 App 前:

当一个已经登录的 Sohu 用户点击上面的 URL ([1]), 对话框会询问他是否接受第三方 App 接收他的信息。如果同意,他会被跳转到 参数 “&redirect_uri” 的 URL。

 

 

如果没有登录的 Sohu 用户点击 URL ([1]), 他登录后会发生同样的事情。

 

 

 

同意三方 App 后:

已经登录的 Sohu 用户 不会再被询问是否接受 三方 App。当他点击 URL ([1]) 时,他会被直接跳转到攻击者控制的页面。

 

 

如果 Sohu 用户没有登录,攻击依然可以在要求他登录的Sohu的对话框被确认后完成(这个过程不会提示任何和三方 App 有关的内容)。

 

 

 

 

(2.1.1) Sohu 一般会允许属于已被验证过得三方 App domain 的所有 URLs。 然而,这些 URLs 可以被操控。比如,参数 “&redirect_uri” 是被三方 App 设置的,但攻击者可以修改此参数的值。

 

 

因此,Sohu 用户意识不到他会被先从 Sohu 跳转到第三方 App 的网页,然后从此网页跳转到有害的网页。这与从 Sohu 直接跳转到有害网页是一样的。

 

 

因为 Sohu 的 OAuth 2.0 客户很多,这样的攻击可以很常见。

 

 

在同意三方 App 之前,Sohu 的 OAuth 2.0 让用户更容易相信被跳转的页面是安全的。这增加了三方 App 被 URL跳转 攻击的成功率。

 

 

同意三方 App 后, 攻击者可以完全绕过 Sohu 的 URL跳转 验证系统。

 

 

用了一个页面进行了测试, 页面是 “http://essayjeanslike.lofter.com/“. 可以假定它是有害的,并且含有收集三方 App 和用户敏感信息的 code。

 

 

Sohu 与 news.cn 有关的有漏洞的 URL:
https://api.t.sohu.com/oauth2/authorize?client_id=TP4vefRdCFUEFhrNpMnQ&scope=basic&response_type=code&redirect_uri=http%3A%2F%2Flogin.home.news.cn%2Fcb%2Fsohu.do&state=http://my.xuan.news.cn/main.do__20

 

 

POC (我们可以在news.cn domain 内随便修改”redirect_uri”的值):
https://api.t.sohu.com/oauth2/authorize?client_id=TP4vefRdCFUEFhrNpMnQ&scope=basic&response_type=code&redirect_uri=http%3A%2F%2Flogin.home.news.cn%2Fcb%2Fsohu.do&state=http://my.xuan.news.cn/main.do__20

 

 

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




博客细节:
http://tetraph.blogspot.com/2014/05/sohus-oauth-20-covert-redirect.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) 一起利用。



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

github-logo

 

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

 

 

(1) Domain:
github.com

 

“GitHub is a web-based Git repository hosting service, which offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features. Unlike Git, which is strictly a command-line tool, GitHub provides a web-based graphical interface and desktop as well as mobile integration. It also provides access control and several collaboration features such as wikis, task management, and bug tracking and feature requests for every project. GitHub offers both plans for private repositories and free accounts, which are usually used to host open-source software projects. As of 2015, GitHub reports having over 9 million users and over 21.1 million repositories, making it the largest code hoster in the world.” (Wikipedia)

 

 

 

(2) Vulnerability Description:

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

 

GitHub’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 GitHub.

 

At the same time, it can be used to collect sensitive information of both third-party app and users by using the following parameters (not all apps),

“&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.

 
 
 
 

 

 

Before acceptance of third-party application:

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

 
 

 

 

After acceptance of third-party application:

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

 

 

More seriously, some third-party websites may allow all URLs (even not belong to themselves) for “&redirect_uri” parameter.

 

 

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

 

 

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

 
 
 

 

 

 

 

(2.2) Use one of my webpages for the following tests. The webpage is “http://shellmantis.tumblr.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:
travis-ci.com

 
 
 
 
 
 
 
 
 
 
 
 

 

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


Blog Detail:
http://tetraph.blogspot.com/2014/05/githubs-oauth-20-covert-redirect.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/githubs-oauth-2-0-covert-redirect-vulnerability/
http://computerobsess.blogspot.com/2014/06/github-bug.html
http://ithut.tumblr.com/post/120699141388/whitehatview-internet-users-threatened-by-new
https://twitter.com/tetraphibious/status/559164386560851968
https://hackertopic.wordpress.com/2014/07/26/github-exploit/
http://webtech.lofter.com/post/1cd3e0d3_706aea5
http://securityrelated.blogspot.com/2014/06/github-bug.html
http://tetraph.blog.163.com/blog/static/23460305120144715239475/
http://www.inzeed.com/kaleidoscope/covert-redirect/githubs-oauth-2-0-covert-redirect-vulnerability/
https://vulnerabilitypost.wordpress.com/2014/07/16/github-exploit/

 

Mail.ru Online Service OAuth 2.0 Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

mail-ru_1882101c

 

Mail.ru Online Service OAuth 2.0 Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

 

(1) Domain:
mail.ru

 

 

“Mail.Ru Group (London Stock Exchange listed since November 5, 2010) is a Russian Internet company. It was started in 1998 as an e-mail service and went on to become a major corporate figure in the Russian-speaking segment of the Internet. As of 2013, according to comScore, websites owned by Mail.ru collectively had the largest audience in Russia and captured the most screen time. Mail.Ru’s sites reach approximately 86% of Russian Internet users on a monthly basis and the company is in the top 5 of largest Internet companies, based on the number of total pages viewed. Mail.ru controls the 3 largest Russian social networking sites. It operates the second and third most popular Russian social networking sites, Odnoklassniki and Moy Mir, respectively. Mail.ru holds 100% of shares of Russia’s most popular social network VKontakte and minority stakes in Qiwi, formerly OE Investments (15.04%). It also operates two instant messaging networks (Mail.Ru Agent and ICQ), an e-mail service and Internet portal Mail.ru, as well as a number of online games.” (Wikipedia)

 

 

“Mail.Ru — крупный коммуникационный портал российского Интернета, ежемесячная аудитория которого по данным на октябрь 2012 года превышает 31,9 млн человек. Ресурс занимает 52-е место по популярности в мире и 5-е — в России. Число работников составляет 2800 человек. Ресурс принадлежит инвестиционной группе Mail.Ru Group.” (Ru.Wikipedia)

 

 

 

 

(2) Vulnerability Description:

Mail.ru 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:

Mail.Ru’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 Mail.Ru.

 

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”=get_user_info…

 

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

 

 

The vulnerabilities occurs at page “/oauth/authorize?” with parameter “&redirect_uri”, e.g.
https://connect.mail.ru/oauth/authorize?response_type=token&client_id=667668&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin.do%3FreturnUrl%3Dhttp%253A%252F%252Fwww.tetraph.com%252Fessayjeans%252Fpoems%252Fdistance.html [1]

 

 

Before acceptance of third-party application:

 

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

 

After acceptance of third-party application:

 

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

 

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

 

 

 

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

 

 

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

 

Vulnerable URL from Mail.Ru that is related to kp.ru:
https://connect.mail.ru/oauth/authorize?response_type=code&client_id=667668&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin%2Fmailru.do%3FreturnUrl%3Dhttp%253A%252F%252Fizh.kp.ru

 

POC:
https://connect.mail.ru/oauth/authorize?response_type=code&client_id=667668&redirect_uri=http%3A%2F%2Fmy.kp.ru%2Flogin.do%3FreturnUrl%3Dhttp%253A%252F%252Fwww.tetraph.com%252Fessayjeans%252Fpoems%252Fdistance.html

 

 

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

 

Blog Detail:
http://tetraph.blogspot.com/2014/05/mailru-oauth-20-covert-redirect.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/mail-ru-oauth-2-0-covert-redirect-vulnerability/
http://www.inzeed.com/kaleidoscope/covert-redirect/mail-ru-oauth-2-0-covert-redirect-vulnerability/
https://twitter.com/essayjeans/status/558974764958486528
https://tetraph.wordpress.com/2014/07/11/mail-ru-security-bugs/
https://computertechhut.wordpress.com/2014/07/05/mail-ru-security-bugs/
http://securityrelated.blogspot.com/2014/08/mailru-website-attack.html
http://whitehatpost.lofter.com/post/1cc773c8_706b6bf
http://ithut.tumblr.com/post/119493112323/securitypost-sicherheitslucke-in-oauth-2-0-und
http://tetraph.blog.163.com/blog/static/23460305120144611948109/
http://computerobsess.blogspot.com/2014/08/mailru-website-attack.html

LinkedIn Online Service OAuth 2.0 Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

logolinkedin

 

LinkedIn Online Service OAuth 2.0 Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)

 

(1) Domain:
linkedin.com

 

“LinkedIn /ˌlɪŋkt.ˈɪn/ is a business-oriented social networking service. Founded in December 2002 and launched on May 5, 2003, it is mainly used for professional networking. In 2006, LinkedIn increased to 20 million members. As of March 2015, LinkedIn reports more than 364 million acquired users in more than 200 countries and territories. The site is available in 24 languages, including Arabic, Chinese, English, French, German, Italian, Portuguese, Spanish, Dutch, Swedish, Danish, Romanian, Russian, Turkish, Japanese, Czech, Polish, Korean, Indonesian, Malay, and Tagalog. As of 2 July 2013, Quantcast reports LinkedIn has 65.6 million monthly unique U.S. visitors and 178.4 million globally, a number that as of 29 October 2013 has increased to 184 million. In June 2011, LinkedIn had 33.9 million unique visitors, up 63 percent from a year earlier and surpassing MySpace. LinkedIn filed for an initial public offering in January 2011 and traded its first shares on May 19, 2011, under the NYSE symbol “LNKD”.” (Wikipedia)

 

 

 

 

(2) Vulnerability Description:

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

Linkedin’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 Linkedin.

 

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

 

LinkedIn replied with thanks and said that they “have published a blog post on how [they] intend to address [the problem].”

 

 

Blog address:
https://developer.linkedin.com/blog/register-your-oauth-2-redirect-urls

 

 

The vulnerabilities occurs at page “/oauth2/authorization?” with parameter “&redirect_uri”, e.g.
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=773svxj8m007qf&state=5316b8f3ea22a6.60933041&redirect_uri=http%3A%2F%2Fwww.inc.com%2Flogout%3Fret%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fthatday.html [1]

 

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

 

 

 

(2.1.1) Linkedin 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 Linkedin 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 Linkedin directly. The number of Linkedin’s OAuth 2.0 client websites is so huge that such Attacks could be commonplace.

 

Linkedin’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.

 

At the same time, attackers could completely bypass Linkedin’s authentication system and attack more easily.

 

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

 

 

 

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

 

Below is an example of a vulnerable third-party domain:
inc.com

 

Vulnerable URL in this domain:
http://www.inc.com/logout?ret=http://www.tetraph.com/essayjeans/poems/thatday.html

 

Vulnerable URL from Linkedin that is related to inc.com:
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=773svxj8m007qf&state=53169feb993957.93834988&redirect_uri=http%3A%2F%2Fdev-www.inc.com%2Fpatch%2Freflex%2Flib%2Flinkedin%2Fstartlogin.php

 

POC:
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=773svxj8m007qf&state=5316b8f3ea22a6.60933041&redirect_uri=http%3A%2F%2Fwww.inc.com%2Flogout%3Fret%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fthatday.html

 

 


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

 

Blog Detail:
http://tetraph.blogspot.com/2014/05/linkedin-oauth-20-covert-redirect.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:
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/linkedin-oauth-2-0-covert-redirect-vulnerability/
http://computerobsess.blogspot.com/2014/07/linkedin-service-exploit.html
https://twitter.com/tetraphibious/status/559169110106316800
https://webtechwire.wordpress.com/2014/06/07/linkedin-bugs/
http://securityrelated.blogspot.com/2014/07/linkedin-service-exploit.html
http://ithut.tumblr.com/post/119493922098/securitypost-itinfotech-continuan-los
http://tetraph.blog.163.com/blog/static/23460305120144385617661/
https://computertechhut.wordpress.com/2014/06/11/linkedin-bugs/
http://itsecurity.lofter.com/post/1cfbf9e7_70608ba
http://www.inzeed.com/kaleidoscope/covert-redirect/linkedin-oauth-2-0-covert-redirect-vulnerability/