Profile Vulnerability

Severity [Critical]

Description

During the OAuth process, IdP server will return user-related information, like user id and email address. The vulnerability is caused by the incorrect implementations in the RP app/ server, where the RP server utilizes the improper parameter from IdP to authenticate the user. The failure to return correct identity proof by the RP app and the improper verification of the credential by the RP server are two types of common mistakes made by RPs.

• The RP app returns improper identity proof. A typical example is shown in Fig. 1. In the situation, the RP developers deploy the server-to-server logics on the client side (e.g., Step 6 and 7 inFig. 3), where an RP app immediately retrieves the user identity information (stored in the IdP server) by invoking the IdP API with the access token. Once the information is received, it is returned to the RP server as identity proof. Even if the identity proof may be encrypted or signed by the RP app, the attacker can tamper the Step 4 of Fig. 1 to feed in the incorrect one (obtained/ stolen from the victim). As such, the attacker can login the RP as the victim and get access to the private information of the victim held by the RP server.
• The RP server does not verify the identity proof. As shown in Fig. 2, when the access token, as well as the attached user identity information (e.g., user id/ email address) from the IdP server, received, many RP servers simply and improperly authenticate the user based on the received user identity information WITHOUT verifying the binding between the information and the issued access token. The appended user information was originally designed to debug the access token (right after Step 7 in Fig. 3), but the RP server utilizes it as the authenticator wrongly in the situation. Therefore, the attacker can break the authentication by substituting the user identity information in Step 1 of Fig. 2.

Fig. 1

Fig. 2

Fig. 3

Impact

This vulnerability enables an attacker to log into RP App as the victim by leveraging the victim’s public user profile only.

Solution

• Sina Weibo: RP developers should deploy the server-to-server logics (Step 6 to Step 7 in Fig. 3) on the server side. Besides, the RP server needs to compare the user profile returned in Step 7 with the one from Step 3 in Fig. 3 to verify the access token. Finally, they should take the latter one to authenticate the user.
• WeChat: RP developers should deploy the server-to-server logics (Step 6 to Step 9 in Fig. 5) on the server side.
• Facebook: RP server should authenticate the user based on the signed user information (signed request/ id token) after verifying its signature. Besides, the RP developers should not hardcode the app secret in the APK.

Fig. 5

Reference

[1] Yang, Ronghai, Wing Cheong Lau, and Shangcheng Shi. "Breaking and Fixing Mobile App Authentication with OAuth2. 0-based Protocols." International Conference on Applied Cryptography and Network Security. Springer, Cham, 2017.