Kingsoft's mobile phone client can access another user's account.

This program is exclusively sponsored by @ imlonghao for retest.

(Title)
Cloud storage, fast and convenient. (Synchronous voice Customer: "I can read novels on Android through online storage ")
Modify the captured package. (Same-phase sound security researcher: "If you change the size of several bytes, your privacy documents will be kept at a Glance ")
What makes the quick drive mobile edition vulnerable? (A competitor (a network disk) at the same time: "We were lucky to log on with a third-party account ")
Who should ensure authentication transfer in the cloud age? (Simultaneous voice Reporter: "When we are still arguing about who should be responsible, users are already suffering from unexpected events in the cloud ")

Cloud Security Authentication confusion will be broadcast soon.

(I would like to express my appreciation for the aforementioned news investigation on the CCTV News Channel .)

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

 

Detailed description:

 

Kingsoft fast disk mobile client, in the process of using microblog OAuth 2.0 authorization information in exchange for their own authentication information, one-time committing two common logical design defects, resulting in any access to other people's fast disk account; however, the premise is that the quick disk account needs to be bound to Weibo.

Specific mistakes:
(Problem 1) OAuth 2.0 unbound token problem: due to the "unbound token" feature (http://article.yeeyan.org/view/50978/307535) of OAuth 2.0, third-party applications use the platform's OAuth 2.0 authorization (authorize) as the authenticate Method of its own applications, there is a lack of an effective authentication transfer checksum and source check, resulting in only the access token of application B, you can log on to the service bound to application.

(Question 2) Incorrect OAuth authorization information is used for authentication exchange: uid is used to authenticate user information, instead of access token.
In this case, we can see that:Tao web site sina oauth login Vulnerability
I wanted to review the online storage of other companies, but found that they did not provide Weibo login, so I was lucky enough to escape this problem. However, I believe that once it is enabled, it is also very easy to recruit. Therefore, mobile phone clients that threaten cloud security need to be noticed by mobile phone developers (such as those who use Sina Weibo sso sdk) and related backend (see figure ).

 

This vulnerability also reflects a problem: Oauth 2.0 is used as a framework protocol, and many security details need to be implemented by developers themselves, it is obviously inappropriate for the platform to cover all the security details. However, if you place the security details to the app developer's own guarantee, it is easy for both parties to implement the security details, it is particularly difficult to pass and exchange certification. How to divide it has become a future direction worth studying. However, no matter how we argue, users and hackers cannot wait ......

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

 

Proof of vulnerability:

 

Problem 1:
OAuth 2.0 does not have the token binding problem. by intercepting the access token information returned by Sina Weibo, you can change it to the access token and Sina uid of another person to access another person's quick drive. Note that this access token can be obtained by other applications.

It is difficult to modify because you need to know the access token of the victim in other applications. In this case, the attacker must be tricked into authorizing the application specified by the victim to complete the attack.

(During the authorization process on Weibo, I used Sina uid 1780xxx to log on. Then, after the next login was successful, I intercepted it, and the access token "2.00tRjxx" and uid "1780xxx" obtained from the Sina uid 1780xxx on the quick disk ", replace it with the access token "2.00isUxx" and uid "1454xxx" obtained by Sina uid 1454xxx in other applications)

 

Proof of Question 2:

Use the wrong OAuth authorization information to obtain it. by intercepting the data to be sent to the back-end Server api of the fast disk, replace the Sina uid to access the others' online disks.

The modification is difficult. You only need to know the Sina uid, and you also need to know that the Sina uid has been logged on too fast.

(During Weibo authorization, I used Sina uid 1780xxx to log on. Then, I intercepted the request before sending data to the backend server api and replaced it with Sina uid 1791 xxxx)

 

 

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

Solution:

 

Hazard assessment:

For fast disks, it is regarded as "high ". The reason is as follows:

(1) Question 1: It is easier to obtain the user's access token. You only need to register a third-party application and induce user authorization.

(2) Question 2: it is very easy to obtain the user's Sina uid. You only need to search Weibo to obtain it.

(3) targeted attacks are easy. You only need to modify data packets. The ultimate success rate is extremely high. As long as the user does not change the password, the user will have permanent access permissions.

(4) The user base of the quick disk is large.

(5) Whether the Source Query, proof or signature verification is used for access token depends on the provision of the open platform. If yes, you only need to fix the new binding and login vulnerabilities on the server.

Repair suggestions:

(1) On the mobile server side, when receiving the platform authentication information of the mobile client, in exchange for the authentication creden of their own services, the uid without authorization information cannot be used for authentication in exchange, instead, access tokens with authorization information must be used. In addition, access tokens must be used for Source Query, proof, or signature verification.

Specifically, the interface documents that have been verified on various open platforms in China are as follows:

(A) "authorized query" on Sina Weibo's Open Platform ":

Http://open.weibo.com/wiki/Oauth2/get_token_info

(B) QQ login: the general parameters seem to have been protected against this problem (the time issue is not verified ):
Click here!

(C) Baidu Open Platform "determines whether the current user has been authorized to the application" (this interface has not verified whether it can defend against this issue, please consult Baidu Open Platform ):
Click here!

(D) Renren "determines whether a user has authorized the App" (this interface has not been verified to defend against this issue. Please consult Renren Open Platform ):

Http://wiki.dev.renren.com/wiki/Users.isAppUser

For other open platforms, we recommend that you consult related questions.

(2) Check all bound access tokens, it is found that the Sina uid in the access token is inconsistent with the bound Sina uid, the access token authorized by the non-fast disk appkey, And the expired access token must all be revoked, these users are required to authorize logon again.

(3) Strengthen education on various open platforms and remind developers to pay attention to the above issues