Kaixin Online Website OAuth 2.0 Covert Redirect Web Security Bugs (Information Leakage & Open Redirect)
“Kaixin001 (Chinese: 开心网; pinyin: Kāixīnwǎng; literally: “Happy Net”) is a leading social networking website launched in March 2008. In 2010, Kaixin001 ranks as the 13th most popular website in China and 67th overall according to Alexa Internet. On 20 May 2009, Kaixin001 formally sued Qianxiang Group for unfair competition. Qianxiang Group runs one of China’s popular social networks Renren. It purchased the kaixin.com domain and launched a Kaixin001 clone. This enables Renren to confuse users and attract some Kaixin001 potential users to the Kaixin.com clone. In October 2011, Kaixin001 won a victory. The Beijing Second Intermediate People’s Court ordered Oak Pacific to cease all use of kaixin.com and pay 400,000 renminbi ($60,000) in damages. The other main competition for Kaixin001 is Weibo.com, which is like a hybrid of Twitter and Facebook. Weibo.com has 140 million users and is owned by Sina.com.” (Wikipedia)
(2) Vulnerability Description:
Kaixin 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:
Kaixin’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 Kaixin.
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.),
It increases the likelihood of successful Open Redirect Attacks to third-party websites, too.
The vulnerabilities occurs at page “/authorize?” with parameter “&redirect_uri”, e.g.
http://api.kaixin001.com /oauth2/authorize?client_id=232383298458c9b3c19540c63bc4cb0d& response_type=code&redirect_uri=http://store.tv.sohu.com/web /login.do?bru=http://tetraph.com/essayjeans/seasons/祭春.html 
Before acceptance of third-party application:
When a logged-in user clicks the URL () 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 Kaixin and clicks the URL () above, the same situation will happen upon login.
After acceptance of third-party application:
A logged-in 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 ().
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) Kaixin 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 Kaixin 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 Kaixin directly. The number of Kaixin’s OAuth 2.0 client websites is so huge that such Attacks could be commonplace.
Before acceptance of the third-party application, Kaixin’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 Kaixin’s authentication system and attack more easily.
(2.2) One of webpages was used for the following tests. The webpage is “http://mathpost.tumblr.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:
Vulnerable URL in this domain:
Vulnerable URL from related to sohu.com:
http://api.kaixin001.com /oauth2/authorize?client_id=232383298458c9b3c19540c63bc4cb0d& response_type=code&redirect_uri=http://store.tv.sohu.com/web /login.do?bru=http://tetraph.com/essayjeans/seasons/祭春.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.