Vulnerability VKontakte: send a message with the page recovery code to someone else's number

On a typical spring day, doing “preparation” for the Unified State Exam on computer science, I came across an article about the vulnerability of Facebook , which allowed hacking all accounts on a social network, for which they paid $ 15,000. The essence of the vulnerability was to search for recovery codes on the company's test domain. I thought, why is VKontakte worse? And I decided to try to do a similar trick with them. Knowing that the web version is already quite well researched, the victim should have become an Android client, and what came of it can be read under the cut.

Look traffic

First of all, I wanted to find out what information the application transmits to the network during the page recovery process. Fiddler acted as an assistant in this matter, I configured it and the Android device as written in the official documentation . Thus, all HTTP / HTTPS requests from the device become available in Fiddler. Now, in the app, feel free to exit from your VKontakte account and click on the “Forgot your password?” Button. After entering the phone number, the application sends 2 HTTPS requests. Of particular value is the second, because it is he who is responsible for sending SMS with a recovery code.
')


Special attention should be paid to some query parameters:

phone - the number to which the SMS is sent
session_id - randomly generated session of the restore operation

Attempting to send a request by changing it did not succeed. The “signature” parameter, which acts as a “signature”, interferes, as it is generated we will understand a little later.

For the subsequent analysis, in the application, we will enter a random recovery code and continue to monitor network activity. We see the following request, it checks the correctness of the entered code. Since the code was random, the check failed.



Honestly at this point, I wanted to start sorting through recovery codes, changing the value of the “code” parameter. Unfortunately, this request is also protected from being modified using "signature". We'll have to figure out how this signature is generated.

Reverse engineering: decompilation

For the initial analysis, you can try to decompile the VKontakte application. So you can get some parts of the source code in Java.


We open in jd-gui all received .jar files. And without hesitation, we do a search for the string "signature".



The libverify library under the authorship of Mail.Ru clearly falls out of the general list of those found. We look and we are not mistaken, the generated string is very similar to the url from previous requests.

localObject3 = String.format(Locale.US, "%s%s?%s&signature=%s", new Object[] { d(), e(), localObject3, URLEncoder.encode(ru.mail.libverify.utils.mb(f() + (String)localObject4 + ru.mail.libverify.utils.mc(ab())), "UTF-8") }); 

This library is made in the best traditions of security through obscurity, all code is securely obfuscated. Therefore, through jd-gui, I managed to find out only that the “signature” hides the MD5-hash from the unknown line.

Reverse Engineering: Disassembling

I needed to find out what line goes to ru.mail.libverify.utils.mb (). The easiest way to do this is to change the application code slightly. Well, let's try. First we use apktool , with the command:

 apktool.jar d vk.apk -r ( -r   ) 

Now, in the folders with the smali-code, we find the file in which the MD5 is generated. In my case, the path was as follows: smali_classes3 \ ru \ mail \ libverify \ utils \ m.smali. Go to the desired method:

 ... .method public static b(Ljava/lang/String;)Ljava/lang/String; .locals 8 .param p0 # Ljava/lang/String; .annotation build Landroid/support/annotation/NonNull; .end annotation .end param :try_start_0 const-string/jumbo v0, "UTF-8" invoke-virtual {p0, v0}, Ljava/lang/String;->getBytes(Ljava/lang/String;)[B :try_end_0 .catch Ljava/io/UnsupportedEncodingException; {:try_start_0 .. :try_end_0} :catch_2 move-result-object v0 :try_start_1 const-string/jumbo v1, "MD5" invoke-static {v1}, Ljava/security/MessageDigest;->getInstance(Ljava/lang/String;)Ljava/security/MessageDigest; move-result-object v1 invoke-virtual {v1}, Ljava/security/MessageDigest;->reset()V invoke-virtual {v1, v0}, Ljava/security/MessageDigest;->update([B)V invoke-virtual {v1}, Ljava/security/MessageDigest;->digest()[B move-result-object v0 ... 

The string you wanted to know was passed to the function in the first register parameter (p0). Therefore, to get it, you should output the parameter somewhere, for example, in Logcat. Add a few lines to the code:

 ... .method public static b(Ljava/lang/String;)Ljava/lang/String; .locals 8 .param p0 # Ljava/lang/String; .annotation build Landroid/support/annotation/NonNull; .end annotation .end param # PATCH # String v0 = "vk-research"; const-string/jumbo v0, "vk-research" # Log.d(v0, p0),  p0   invoke-static {v0, p0}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I :try_start_0 const-string/jumbo v0, "UTF-8" ... 

After saving the changes, build the application using apktool:

 apktool.jar b vk -o newvk.apk 

Now you need to sign apk, I used APK Signer .

After that, after removing the original application, you can install and run our modified client VKontakte. To get the logcat from the device, we will use the Android Debug Bridge . We connect the Android device via USB and execute the following commands in sequence:

 adb devices adb logcat 

As soon as they joined the device and got the opportunity to watch the logs, click again on "Forgot your password?" And enter the phone number. The following entry appears in the adb window:



It becomes clear that the hash string consists of successively glued: part of the url, query parameters and another hash string (506e786f377863526a7558536c644968). And now, knowing the generation algorithm “signature”, we can start sending our “signed” requests.

Study

For research, I wrote a simple C # program that sent a request to send an SMS and tried to enter a code. Using it, I entered random recovery codes. But expectedly rested on the limit attempts:



I tried to resend SMS, in the hope that the limit would disappear after that. To my regret, the message arrived, but I still could not enter the code:



I decided to send requests with different session_id, sms came with other recovery codes, but I still rested against the limit, now not in “ATTEMPTLIMIT”, but in “RATELIMIT”.




I tried to bypass the limits in all possible ways. I changed the IP addresses, request parameters, phone numbers, but I could not make more than 5 attempts to enter the code.

And here, almost by accident, I decided to send the recovery code to two different numbers, but using the same session_id. To my surprise, there was no chapel when I saw the same SMS on both phones. Here's how it worked:


Because of the proxy, additional verification is required.

Thus, the attack was obtained:

1. We send a request to send SMS to subscriber A with session_id C, he receives the code 1234
2. We send a request to send SMS to subscriber B with session_id C, he receives the code 1234
3. Now, if subscriber A knows the telephone number of subscriber B, he can restore his page. It was possible to restore only that page, to the number of which the last SMS came with a similar session_id.

Conclusion

Immediately after the discovery of the vulnerability, I wrote a report on HackerOne. After 17 hours, the vulnerability was eliminated. A few days later I was paid $ 2000. This vulnerability allowed hacking most of the accounts in the social network, only accounts with two-factor authentication were safe (they cannot be restored by phone number). Report

PS Unified State Exam in computer science passed by 97 points. Unfortunately, the remaining items are not so successful.

UPD: The libverify library was also used in ICQ, hence the vulnerability existed there. In the bug-bounty ICQ program, I was paid an extra $ 1000. Report