Otra brecha de seguridad amenaza parte de Internet

Un nuevo fallo de seguridad amenaza Internet. En este caso se trata de Covert Redirect y ha sido descubierto por un estudiante chino en Singapur. Las empresas tienen en sus manos solucionar este problema.

encrypt

 

Cuando aún resuenan los ecos de Heartbleed y el terremoto que sacudió la red, nos acabamos de enterar que otra brecha de seguridad compromete Internet. En este caso se trata de un fallo que afecta a páginas como Google, Facebook, Microsoft, Linkedin, Yahoo, PayPal, GitHub o Mail.ru que usan estas herramientas de código abierto para autenticar a sus usuarios.

 

Este error permitiría a un atacante haga creer a un usuario que una nueva ventana que redirija a Facebook es segura cuando en realidad no lo es. Hasta aquí la técnica se parece al phishing pero lo que hace lo hace diferente es que Covert Redirect, que así se llama el nuevo exploit, usa el dominio real pero hace un bypass del servidor para conseguir la info. Lo mejor que podemos hacer cuando estemos navegando y pulsemos en un sitio que abre un pop up que nos pide logearnos en Facebook o Google es cerrar esa ventana para evitar que nos redirija a sitios sospechosos.

 

Wang Jing, estudiante de doctorado en la Universidad Técnica de Nanyang (Singapur), es quien ha descubierto la vulnerabilidad y le ha puesto nombre. El problema, según Jing, es que ni el proveedor ni la compañía quieren responsabilizarse de esta brecha ya que costaría mucho tiempo y dinero. Seguramente, ahora que se conoce el caso, las compañías se pondrán manos a la obra.

 

Artículos Relacionados:

Falha de segurança afetam logins de Facebook, Google e Microsoft

covert_redirect3

Um estudante de PHD de Singapura, Wang Jing, identificou a falha, chamada de “Covert Redirect”, que consegue usar domínios reais de sites para verificação de páginas de login falsas, enganando os internautas.

 

Os cibercriminosos podem criar links maliciosos para abrir janelas pop-up do Facebook pedindo que o tal aplicativo seja autorizado. Caso seja realizada esta sincronização, os dados pessoais dos usuários serão passados para os hackers.

 

Wang afirma que já entrou em contato com o Facebook, porém recebeu uma resposta de que “entende os riscos de estar associado ao OAuth 2.0″ e que corrigir a falha “é algo que não pode ser feito por enquanto”.

 

O Google afirmou que o problema está sendo rastreado, o LinkedIn publicou nota em que garante que já tomou medidas para evitar que a falha seja explorada, e a Microsoft negou que houvesse vulnerabilidade em suas páginas, apenas nas de terceiros.

 

A recomendação do descobridor da falha para os internautas é que evitem fazer o login com dados de confirmação de Facebook, Google ou qualquer outro serviço sem terem total certeza de que estão em um ambiente seguro.

 

 

Especialistas: erro é difícil de corrigir

O site CNET ouviu dois especialistas em segurança virtual sobre o assunto. Segundo Jeremiah Grossman, fundador e CEO interino da WhiteHat Security, afirma que a falha “não é fácil de corrigir”. Segundo Chris Wysopal, diretor da Veracode, a falha pode enganar muita gente.

 

“A confiança que os usuários dão ao Facebook e outros serviços que usam OAuth pode tornar mais fácil para os hackers enganarem as pessoas para que elas acabem dando suas informações pessoais a ele”, afirma Wsyopal.

 

 

 

notícias relacionadas:

Студент-математик нашёл уязвимость в OpenID и OAuth 2.0

OAuth и OpenID — очень популярные протоколы, которые совместно используются для авторизации и аутентификации. Приложение OAuth генерирует токены для клиентов, а OpenID предоставляет возможность децентрализованной аутентификации на сторонних сайтах, раскрывая персональные данные пользователей.


Студент Ван Цзин (Wang Jing) с факультета математики Наньянского технологического университета в Сингапуре нашел способ, как злоумышленник может перехватить персональные данные пользователей, перенаправив их на вредоносный сайт после авторизации. Речь идет об уязвимости типа скрытого редиректа (covert redirect), по аналогии с известной атакой open redirect.



covert_redirect1



В этом случае провайдер (Facebook, Google и проч.) видит, что информацию запрашивает нормальное приложение, но на самом деле пользователя скрыто направляют на другой сайт, заменив значение redirect_uri в URL.



covert_redirect2



Уязвимость затрагивает множество крупных сайтов, такие как Facebook, Google, Yahoo, LinkedIn, Microsoft, VK, Mail.Ru, PayPal, GitHub и другие. Все они выдают по запросу злоумышленника персональные данные пользователя. В случае Facebook это может быть имя, фамилия, почтовый адрес, возраст, место жительства, место работы и проч.




covert_redirect3



Кстати, open redirect входит в число 10 главных атак за 2013 год по версии OWASP.


Ван Цзин опубликовал видеоролик, в котором показывает способ эксплуатации уязвимости, на примере Facebook OAuth 2.0. По его словам, защититься от таких атак можно только с помощью «белого списка» сайтов для редиректа.


источник:
http://xakep.ru/62448/




 

 

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/




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

china

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

 

 

(1) Domain:
weibo.com

“Sina Weibo (NASDAQ: WB) is a Chinese microblogging (weibo) website. Akin to a hybrid of Twitter and Facebook, it is one of the most popular sites in China, in use by well over 30% of Internet users, with a market penetration similar to the United States’ Twitter. It was launched by SINA Corporation on 14 August 2009, and has 503 million registered users as of December 2012. About 100 million messages are posted each day on Sina Weibo. In March 2014, Sina Corporation announced a spinoff of Weibo as a separate entity and filed an IPO under the symbol WB. Sina retains 56.9% ownership in Weibo. The company began trading publicly on April 17, 2014. “Weibo” (微博) is the Chinese word for “microblog”. Sina Weibo launched its new domain name weibo.com on 7 April 2011, deactivating and redirecting from the old domain, t.sina.com.cn to the new one. Due to its popularity, the media sometimes directly uses “Weibo” to refer to Sina Weibo. However, there are other Chinese microblogging/weibo services including Tencent Weibo, Sohu Weibo and NetEase Weibo.” (Wikipedia)

(2) Vulnerability Description:

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

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

 

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.

 

The vulnerabilities occurs at page “oauth2/authorize?” with parameter “&redirect_uri”, e.g.
https://api.weibo.com/oauth2/authorize?client_id=2021435350&redirect_uri=http%3A%2F%2Fuc.cjcp.com.cn%2Findex.php%3Fm%3DUser%26a%3Dcallback%26type%3Dsina&response_type=code [1]

 

Before acceptance of third-party application:

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

 

After acceptance of third-party application:

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

 

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

 

Used one of webpages for the following tests. The webpage is “https://biyiniao.wordpress.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:
cjcp.com.cn

 

Vulnerable URL in this domain:
http://uc.cjcp.com.cn/?m=user&a=otherLogin&type=sina&furl=http%3A%2F%2Ftetraph.com%2Fessayjeans%2Fseasons%2F%25E7%25A5%25AD%25E6%2598%25A5.html

 

Vulnerable URL from Weibo that is related to cjcp.com.cn:
https://api.weibo.com/oauth2/authorize?client_id=2021435350&redirect_uri=http%3A%2F%2Fuc.cjcp.com.cn%2Findex.php%3Fm%3DUser%26a%3Dcallback%26type%3Dsina&response_type=code

 

POC:
https://api.weibo.com/oauth2/authorize?client_id=2021435350&redirect_uri=http%3A%2F%2Fuc.cjcp.com.cn%2F%3Fm%3Duser%26a%3DotherLogin%26type%3Dsina%26furl%3Dhttp%253A%252F%252Ftetraph.com%252Fessayjeans%252Fseasons%252F%2525E7%2525A5%2525AD%2525E6%252598%2525A5.html&response_type=code [2]

 

(2.2) Another method for attackers.


Attackers enter the following URL in browser,
http://uc.cjcp.com.cn/?m=user&a=otherLogin&type=sina&furl=http%3A%2F%2Ftetraph.com%2Fessayjeans%2Fseasons%2F%25E7%25A5%25AD%25E6%2598%25A5.html

 

Then, attackers can get URL below,
https://api.weibo.com/oauth2/authorize?client_id=2021435350&redirect_uri=http%3A%2F%2Fuc.cjcp.com.cn%2Findex.php%3Fm%3DUser%26a%3Dcallback%26type%3Dsina&response_type=code [3]

 

If users click URL [3], the same thing will happen as URL [2].

 

 

 

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

 

Blog Detail:
http://tetraph.blogspot.com/2014/05/sina-weibo-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:
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://diebiyi.com/articles/security/covert-redirect/sinas-oauth-2-0-covert-redirect-vulnerability-information-leakage-open-redirect/
http://tetraph.com/security/covert-redirect/sina-weibo-oauth-2-0-covert-redirect-vulnerability-information-leakage-open-redirect/
https://redysnowfox.wordpress.com/2014/08/02/sina-exploit/
http://qianqiuxue.tumblr.com/post/118901060925/itinfotech-covert#notes
http://webtechhut.blogspot.com/2014/07/sina-bug.html
https://twitter.com/yangziyou/status/614745661704015873
http://tetraph.blog.163.com/blog/static/2346030512014463356551/
http://biboying.lofter.com/post/1cc9f4f5_706b6c3
http://frenchairing.blogspot.fr/2014/07/sina-hacking.html
http://www.inzeed.com/kaleidoscope/covert-redirect/sina-weibo-oauth-2-0-covert-redirect-vulnerability-information-leakage-open-redirect/
https://biyiniao.wordpress.com/2014/06/07/sina-research/

==========

 

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





(1) 域名:
weibo.com

” 新浪微博是一个由新浪网推出,提供微型博客服务类的社交网站。用户可以通过网页、WAP页面、手机客户端、手机短信、彩信发布消息或上传图片。新浪可以把 微博理解为“微型博客”或者“一句话博客”。用户可以将看到的、听到的、想到的事情写成一句话,或发一张图片,通过电脑或者手机随时随地分享给朋友,一起 分享、讨论;还可以关注朋友,即时看到朋友们发布的信息” (百度百科)

 

 

(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) 漏洞细节:
Weibo 的 OAuth 2.0 系统可能遭到攻击。更确切地说, Weibo 对 OAuth 2.0 系统的 parameter “&redirect_uri“ 验证不够充分。可以用来构造对 Weibo 的 URL跳转 攻击。

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

“&response_type”=sensitive_info,token,code…

“&scope”=get_user_info%2Cadd_share…

 

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

 

漏洞地点 “oauth2/authorize?”,参数”&redirect_uri”, e.g.
https://api.weibo.com/oauth2/authorize?client_id=2021435350&redirect_uri=http%3A%2F%2Fuc.cjcp.com.cn%2Findex.php%3Fm%3DUser%26a%3Dcallback%26type%3Dsina&response_type=code [1]

 

同意三方 App 前:

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


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

 

同意三方 App 后:

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

 

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

 


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

 

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

 

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

 

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

 

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

 

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

 

下面是一个有漏洞的三方 domain:
cjcp.com.cn

 

这个 domain 有漏洞的 URL:
http://uc.cjcp.com.cn/?m=user&a=otherLogin&type=Weibo&furl=http%3A%2F%2Ftetraph.com%2Fessayjeans%2Fseasons%2F%25E7%25A2%258E%25E5%25A4%258F.html

 

Weibo 与 cjcp.com.cn 有关的有漏洞的 URL:
https://api.weibo.com/oauth2/authorize?client_id=2021435350&redirect_uri=http%3A%2F%2Fuc.cjcp.com.cn%2Findex.php%3Fm%3DUser%26a%3Dcallback%26type%3Dsina&response_type=code

 

POC:
https://api.weibo.com/oauth2/authorize?client_id=2021435350&redirect_uri=http%3A%2F%2Fuc.cjcp.com.cn%2F%3Fm%3Duser%26a%3DotherLogin%26type%3Dsina%26furl%3Dhttp%253A%252F%252Ftetraph.com%252Fessayjeans%252Fseasons%252F%2525E7%2525A5%2525AD%2525E6%252598%2525A5.html&response_type=code [2]

 



(2.2) 攻击的另一个方法.


攻击者在浏览器输入 URL,
http://uc.cjcp.com.cn/?m=user&a=otherLogin&type=sina&furl=http%3A%2F%2Ftetraph.com%2Fessayjeans%2Fseasons%2F%25E7%25A5%25AD%25E6%2598%25A5.html

 

然后,攻击者可以得到 URL,
https://api.weibo.com/oauth2/authorize?client_id=2021435350&redirect_uri=http%3A%2F%2Fuc.cjcp.com.cn%2Findex.php%3Fm%3DUser%26a%3Dcallback%26type%3Dsina&response_type=code [3]

 

如果用户点击 URL [3], 发生的事情和 URL [2] 一样.

 




(2.3)下面的 URLs 有同样的漏洞.
https://api.t.sina.com.cn/oauth2/authorize?client_id=496934491&redirect_uri=http%3A%2F%2Fwww.paidai.com%2Fsiteuser%2Foauth_sina.php%3Ffrom%3Dweibo&response_type=code

 

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

 

博客细节:
http://tetraph.blogspot.com/2014/05/sina-weibo-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) 一起利用。它的 scipID ID 是 13185; OSVDB ID 是 106567; Bugtraq ID 是 67196; X-Force ID 是 93031。

 

 

 

 



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

Alipay-Wallet-Reaches-190-Mn-Annual-Active-Users

 

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

 

 

(1) Domain:
alipay.com

 

“Alipay.com is a third-party online payment platform with no transaction fees. It was launched in China in 2004 by Alibaba Group and its founder Jack Ma. According to analyst research report, Alipay has the biggest market share in China with 300 million users and control of just under half of China’s online payment market in February 2014. According to Credit Suisse, the total value of online transactions in China grew from an insignificant size in 2008 to around RMB 4 trillion (US$660 billion) in 2012. Alipay provides an escrow service, in which consumers can verify whether they are happy with goods they have bought before releasing money to the seller. This service was offered for what the company says are China’s weak consumer protection laws, which have reduced consumer confidence in C2C and even B2C quality control.” (Wikipedia)

 

 

 

(2) Vulnerability Description:

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

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

 

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

 

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

 
 
 
 

Before acceptance of third-party application:

When a logged-in Alipay 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 “&goto”.

 

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

 
 

After acceptance of third-party application:

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

 
 

Used one of  webpages for the following tests. The webpage is “http://lifegreen.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:
cjcp.com.cn

 
 
 

If users click URL [2], attacks happen.

 
 
 




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


Blog Detail:
http://tetraph.blogspot.com/2014/05/alibaba-alipays-oauth-20-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/alibaba-alipays-oauth-2-0-covert-redirect-vulnerability-information-leakage-open-redirect/
http://securityrelated.blogspot.com/2014/07/alibaba-alipay-bug.html
http://whitehatpost.lofter.com/post/1cc773c8_72e71f9
https://vulnerabilitypost.wordpress.com/2014/06/02/alibaba-alipay-exploit/
https://twitter.com/yangziyou/status/614368472705818624
blog.163.com/tetraph/blog/static/2346030512014471384217
http://whitehatview.tumblr.com/post/119488487851/securitypost-itinfotech-falha-de-seguranca#notes
http://computerobsess.blogspot.com/2014/07/alibaba-alipay-bug.html
https://computertechhut.wordpress.com/2014/06/06/alibaba-alipay-exploit/
http://www.inzeed.com/kaleidoscope/covert-redirect/alibaba-alipays-oauth-2-0-covert-redirect-vulnerability-information-leakage-open-redirect/

 

 

 


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

 

阿里巴巴 支付宝 网站 OAuth 2.0 隐蔽重定向 (Covert Redirect) 网络安全漏洞 (信息泄漏 & 公开重定向) 





(1) 域名:
alipay.com


” 支付宝(中国)网络技术有限公司是国内领先的第三方支付平台,致力于提供“简单、安全、快速”的支付解决方案。支付宝公司从2004年建立开始,始终以 “信任”作为产品和服务的核心。旗下有“支付宝”与“支付宝钱包”两个独立品牌。自2014年第二季度开始成为当前全球最大的移动支付厂商。支付宝主要提 供支付及理财服务。包括网购担保交易、网络支付、转账、信用卡还款、手机充值、水电煤缴费、个人理财等多个领域。在进入移动支付领域后,为零售百货、电影 院线、连锁商超和出租车等多个行业提供服务。还推出了余额宝等理财服务。支付宝与国内外180多家银行以及VISA、MasterCard国际组织等机构 建立战略合作关系,成为金融机构在电子支付领域最为信任的合作伙伴。” (百度百科)







(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) 漏洞细节:

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

 

 

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

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

 

漏洞地点 “login/express.htm?”,参数”&goto”, e.g.

https://auth.alipay.com/login/express.htm?goto=https%3A%2F%2Fmemberexprod.alipay.com%2Fauthorize%2FuserAuthQuickLoginAction.htm%3Fe_i_i_d%3D41da904223e68d291bfb0eecbff264e1 [1]

 

同意三方 App 前:

 

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

 

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

 

同意三方 App 后:

 

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

 

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

 

 

 

(2.1.1) 因为 Alipay 的 OAuth 2.0 客户很多,这样的攻击可以很常见。

 

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

 

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

 

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

 

下面是一个有漏洞的三方 domain:
cjcp.com.cn

 

这个 domain 有漏洞的 URL:
http://uc.cjcp.com.cn/?m=pay&a=login&furl=http%3A%2F%2Ftetraph.com%2Fessayjeans%2Foutings%2F%25E5%2590%25AC%25E6%25B5%25B7.html

 

攻击者在浏览器输入 URL,
http://uc.cjcp.com.cn/?m=pay&a=login&furl=http%3A%2F%2Ftetraph.com%2Fessayjeans%2Foutings%2F%25E5%2590%25AC%25E6%25B5%25B7.html

 

 

然后,攻击者可以得到 URL,

https://auth.alipay.com/login/express.htm?goto=https%3A%2F%2Fmemberexprod.alipay.com%2Fauthorize%2FuserAuthQuickLoginAction.htm%3Fe_i_i_d%3D41da904223e68d291bfb0eecbff264e1 [2]

 

如果用户点击 URL [2], 攻击发生。

 


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

 

 

 

博客细节:
http://tetraph.blogspot.com/2014/05/alibaba-alipays-oauth-20-covert.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) 一起利用。它的 scipID ID 是 13185; OSVDB ID 是 106567;  Bugtraq ID 是 67196;  X-Force ID 是 93031。

 
 
 





 

相关文章:
http://tetraph.com/security/covert-redirect/alibaba-alipays-oauth-2-0-covert-redirect-vulnerability-information-leakage-open-redirect/
http://securityrelated.blogspot.com/2014/07/alibaba-alipay-bug.html
http://whitehatpost.lofter.com/post/1cc773c8_72e71f9
https://vulnerabilitypost.wordpress.com/2014/06/02/alibaba-alipay-exploit/
https://twitter.com/yangziyou/status/614368472705818624
blog.163.com/tetraph/blog/static/2346030512014471384217
http://whitehatview.tumblr.com/post/119488487851/securitypost-itinfotech-falha-de-seguranca#notes
http://computerobsess.blogspot.com/2014/07/alibaba-alipay-bug.html
https://computertechhut.wordpress.com/2014/06/06/alibaba-alipay-exploit/
http://www.inzeed.com/kaleidoscope/covert-redirect/alibaba-alipays-oauth-2-0-covert-redirect-vulnerability-information-leakage-open-redirect/

 

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/

 

 

 

 

 

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:

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/