Daily Life - Something Trivial , Something Small

Friday, 2 May 2014

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

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.

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/

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

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.

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/

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/

Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID ( 与 OAuth 2.0 and OpenID 有关的 Covert Redirect 漏洞 )

OAuth 2.0 and OpenID have serious Covert Redirect (http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html) vulnerability.

The vulnerabilities affects most major internet companies OAuth 2.0 and OpenID prodivers, such as Facebook, Google, Yahoo, LinkedIn, Microsoft, QQ, Taobao, Weibo, VK, Mail.Ru, PayPal, GitHub, Sohu and so on. I will introduce their vulnerabilities in detail one by one in the near future.

The name Covert Redirect is derived from and to contrast with the existing vulnerability Open Redirect.

The vulnerability could lead to Open Redirect Attacks (https://www.owasp.org/index.php/Open_redirect) to both clients and providers of OAuth 2.0 or OpenID. For OAuth 2.0, these attacks might jeopardize “the token” of the site users, which could be used to access user information. In the case of Facebook, the information could include the basic ones, such as email address, age, locale, work history, etc. If “the token” has greater privilege (the user needs to consent in the first place though), the attacker could obtain more sensitive information, such as mailbox, friends list and online presence, and even operate the account on the user's behalf.

For OpenID, the attackers may get user's information directly. Compounded by the large number of companies involved, this vulnerability could lead to huge consequences if left unresolved.

Unfortunately, it is difficult to patch the problem because the system is shared by a large host company (the provider) and numerous third-party websites (the clients) that use OAuth 2.0 and OpenID to gain access to the large user base of the host company. The vulnerability is usually due to the existing weakness in the third-party websites. However, they have little incentive to fix the problem. One concern is the cost and the other is that in their view, the host company is responsible for making the attacks appear more credible; therefore, it is not solely their problem. Then, the onus would fall onto the Big Brother (the provider). However, to the provider, the problem does not originate from its own website. Even if it is willing to take on the responsibility, it has to gain cooperation from all the different clients, which is nonetheless a daunting task.

I have reported the vulnerability to related companies.

Facebook said "they] understand the risks associated with OAuth 2.0. However, short of forcing every single application on the platform to use a whitelist, [fixing the vulnerability] isn't something that can be accomplished in the short term."

Google said "[they] are aware of the problem and are tracking it at the moment."

LinkedIn said "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 )

Microsoft answered after they did an investigation and concluded that the vulnerability exists in the domain of a third-party, different from the one reported by Wang (login.live.com). They recommended me to report the issue to the third-party instead.

Weibo said that they thought this vulnerability was serious and would ask their developers to deal with this situation.

Taobao just closed my report without giving any reason.

Yahoo did not reply me months after my report.

I did not report to VK.com, Mail.Ru and so on because I do not know their contact email related to security.

Posed by:
WANG Jing (王晶), a mathematics PhD student from Nanyang Technological University. He got his bachelar degree of Mathematics from University of Science and Technology of China.

http://www.tetraph.com/wangjing/

http://www.tetraph.com/wangjing/chinese.html

Facebook OAuth 2.0 Service Covert Redirect Web Security Bugs Based on Ask.com (Information Leakage & Open Redirect)

Facebook OAuth 2.0 Service Covert Redirect Web Security Bugs Based on Ask.com (Information Leakage & Open Redirect)

(1) Domain:
facebook.com

(2) Vulnerability Description:
Facebook web application has a computer security problem. Hacker can exploit it by Covert Redirect cyber attacks.

The vulnerabilities can be attacked without user login. Tests were performed on Microsoft IE (10.0.9200.16750) of Windows 8, Mozilla Firefox (34.0) & Google Chromium 39.0.2171.65-0 ubuntu0.14.04.1.1064 (64-bit) of Ubuntu (14.04)，Apple Safari 6.1.6 of Mac OS X Lion 10.7.

(2.1) Vulnerability Description:

A Covert Redirect vulnerability was found related to Facebook and was reported.

Facebook said "Short of forcing every single application on the platform to use a whitelist, which isn't something that can be accomplished in the short term, do you have any recommendations on actions we can take here?"

In my reply, I suggested "For any URL, it has a particular value "&h". If the URL is changed. there is no permission any more. That means the modified URL will not get any "&h". Because it is illegal."

Facebook agreed. "As you mentioned, that's how our Linkshim system works. As I said, that doesn't seem to be a feasible solution for an OAuth endpoint where the URL needs to be provided by a third-party site to arbitrary random users."

(2.1.1) Vulnerability Detail:
Facebook's SSO system is susceptible to Attacks. More specifically, the authentication of parameter "&redirct_uri" in SSO system is insufficient. It can be misused to design Open Redirect Attacks to Facebook.

At the same time, it can be used to collect sensitive information of both third-party app and users by using the following parameters,
"&response_type"=sensitive_info,token...
"&scope"=email,user_birthday,user_likes...

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

The vulnerabilities occurs at page "/dialog/oauth?" with parameter "&redirect_uri", e.g.
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=http%3A%2F%2Fwzus.ask.com%2Fr%3Ft%3Dp%26u%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fdistance.html%3F&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup [1]

Before acceptance of third-party application:
When a logged-in Facebook user clicks the URL ([1]) above, he/she will be asked for consent as in whether to allow a third-party website to receive his/her information. If the user clicks OK, he/she will be then redirected to the URL assigned to the parameter "&redirect_uri".

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

After acceptance of third-party application:
A logged-in Facebook user would no longer be asked for consent and could be redirected to a webpage controlled by the attacker when he/she clicks the URL ([1]).

For a user who has not logged in, the attack could still be completed after a pop-up page that prompts him/her to log in.

(2.1.2) Facebook would normally allow all the URLs that belong to the domain of an authorized third-party website. However, these URLs could be prone to manipulation. For example, the "&redirect_uri" parameter in the URLs is supposed to be set by the third-party websites, but an attacker could change its value to make Attacks.

Hence, a user could be redirected from Facebook to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site unwillingly. This is as if the user is redirected from Facebook directly. The number of Facebook's SSO client websites is so huge that such Attacks could be commonplace.

Before acceptance of the third-party application, Facebook's SSO system makes the redirects appear more trustworthy and could potentially increase the likelihood of successful Open Redirect Attacks of third-party website.

Once the user accepts the application, the attackers could completely bypass Facebook's authentication system and attack more easily.

It might be of Facebook's interest to patch up against such attacks.

(2.2) Used one of webpages for the following tests. The webpage is "http://www.diebiyi.com/articles". We can suppose it is malicious and contains code that collect sensitive information of both third-party app and users.

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

Vulnerable URL in this domain:
http://wzap.ask.com/r?t=v&d=im&u=http%3A%2F%2Ftetraph.com

Vulnerable URL from Facebook that is related to ask.com:
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=https%3a%2f%2fsocial.ask.com%2fGS%2fGSLogin.aspx%3fst%3dzNQz0TjIZd42P_zI5MUVw5WtCHw7EDMc1YEjBVuz3bU.&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup

POC:
https://www.facebook.com/dialog/oauth?client_id=152973104736490&redirect_uri=http%3A%2F%2Fwzus.ask.com%2Fr%3Ft%3Dp%26u%3Dhttp%3A%2F%2Fwww.tetraph.com%2Fessayjeans%2Fpoems%2Fdistance.html%3F&response_type=code&scope=email%2cuser_location%2cuser_birthday&display=popup

(2.3) The following URLs have the same vulnerabilities.
https://m.facebook.com/dialog/oauth?redirect_uri=http%3A%2F%2Fm.espn.go.com%2Fwireless%2Fconnect&scope=email%2Cuser_birthday%2Cuser_likes&client_id=116656161708917

https://graph.facebook.com/oauth/authorize?client_id=116656161708917&redirect_uri=http://m.espn.go.com/wireless/connect&display=touch&scope=email,user_birthday,user_likes

http://www.facebook.com/dialog/feed?app_id=180444840287&link=http://www.theguardian.com/money/2007/apr/21/creditcards.debt&display=popup&redirect_uri=http://gu-social-share-experiments.theguardian.com&show_error=false&ref=desktop

https://api.instagram.com/oauth/authorize/?client_id=28ad60e4d0b14b5c8bd87099e53feaef&redirect_uri=http%3A%2F%2Ffollowgram.me%2Flogin&response_type=code&scope=likes+comments+relationships&display=touch

(3) What is Covert Redirect?

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/

POC Video:
https://www.youtube.com/watch?v=Y2-2Scp0pbs

Blog Detail:
http://www.tetraph.com/blog/covert-redirect/facebook-oauth-2-0-covert-redirect-vulnerability-based-on-ask-com-information-leakage-and-url-redirect/

Thursday, 17 April 2014

Google Chromium XSS Auditor Bypass - 0Day Attacks

“XSS auditor” is first published in 2010 by Google which is used to prevent reflected XSS Attacks.
However, we found the following string can bypass the filter.

<script>0,alert(“XSS”)</script>

The mechanism of the filter is very simple. It will checked whether the reflected codes contain the same content sent out from the user.

If there are same content, chromium will check whether the same content is in some tag such as <script></script>
<img > …

If so, chromium will remove the same content from the reflected codes.

Published By: Wang Jing, Mathematics, School of Physical & Mathematical Science,
Nanyang Technological University, Singapore

From:
http://tetraph.com/security/xss-vulnerability/google-chromium-xss-auditor-bypass/

GetPocket getpocket.com CSRF (Cross-Site Request Forgery ) Web Security Vulnerability

GetPocket getpocket.com CSRF (Cross-Site Request Forgery ) Web Security Vulnerability

Domain: getpocket.com

"Pocket was founded in 2007 by Nate Weiner to help people save interesting articles, videos and more from the web for later enjoyment. Once saved to Pocket, the list of content is visible on any device — phone, tablet or computer. It can be viewed while waiting in line, on the couch, during commutes or travel — even offline. The world's leading save-for-later service currently has more than 17 million registered users and is integrated into more than 1500 apps including Flipboard, Twitter and Zite. It is available for major devices and platforms including iPad, iPhone, Android, Mac, Kindle Fire, Kobo, Google Chrome, Safari, Firefox, Opera and Windows." (From: https://getpocket.com/about)

Vulnerability Description:

Pocket has a computer cyber security bug problem. Hacker can exploit it by CSRF attacks.

"Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application." (OWSAP)

Tests were performed on Microsoft IE (9 9.0.8112.16421) of Windows 7, Mozilla Firefox (37.0.2) & Google Chromium 42.0.2311 (64-bit) of Ubuntu (14.04.2)，Apple Safari 6.1.6 of Mac OS X v10.9 Mavericks.

Vulnerability Details:

The code programming flaw exists at "https://getpocket.com/edit/edit" page, i.e.https://getpocket.com/edit?url=http%3A%2F%2Fwpshout.com%2Fchange-wordpress-theme-external-php&title=

Vulnerable URL:

https://getpocket.com/edit?url=http%3A%2F%2Fwpshout.com%2Fchange-wordpress-theme-external-php&title=

Use a website created by me for the following tests. The website is "http://itinfotech.tumblr.com/". Suppose that this website is malicious. If it contains the following link, attackers can post any message as they like.

<a href="https://getpocket.com/edit?url=http%3A%2F%2Fmake.wordpress.org%2Fcore%2F2014%2F01%2F15%2Fgit-mirrors-for-wordpress&title=csrf test">getpocket csrf test</a> [1]

When a logged victim clicks the link ([1]), a new item will be successfully saved to his/her "Pocket" without his/her notice. An attack happens.

Poc Video:http://www.youtube.com/watch?v=Kg743VboyoU&feature=youtu.be

Blog Detail:

https://webtechwire.wordpress.com/2014/04/29/getpocket-csrf/

http://www.tetraph.com/blog/csrf-vulnerability/getpocket-csrf-vulnerability/

http://computerobsess.blogspot.com/2014/10/getpocket-csrf-vulnerability.html

http://tetraph.blog.163.com/blog/static/23460305120143201422975/

Discover and Reporter:

Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. (@justqdjing)

http://www.tetraph.com/wangjing