Blockchain Security | How do hackers steal your encrypted assets from their mobile phones?

Detection of vulnerabilities based on web page verification code mechanism

In the blockchain industry, each user has more or less registered some accounts (exchanges, blockchain communities) on some websites. When these accounts involve money or benefits, the security of the account is a very The issue that deserves attention, so the security of the account is a point of great concern to various vendors. However, there are still some vendors that have loopholes in the authentication process. It is not that vendors do not pay attention to this problem. However, there are some differences in the logic in the verification process of the code layer. These logic vulnerabilities are often easier to use.

0x00 unreliable front end check

In the real world, there are many websites that do not strictly perform identity verification. They often judge whether the user identity is correct by relying on the status code sent back after the account password is sent. This exposes a large loophole. It is quite easy to use the vulnerability. Usually, you only need a security agent BURP to complete the authentication bypass. Enter the correct account and random password when logging in, intercept the message, and then select the burp. Intercept the function of returning the packet, capturing the returned status code

• Bitcoin in India: the premium is over $600, the more banned the more "crazy"
• More “coin days” than the chain trading volume indicator, more able to reflect the flow of funds
• Interpretation of Libra: A revolution covering 2.7 billion people? Still a whimsical girl

Change the status code in the returned packet to the status code of the normal login. Of course, the status codes here are not necessarily 0 and 1, and various status codes may exist. How do we judge the correct status code? What?

Here we need to manually register a user, then log in normally, and grab the returned status code. When you find the message sent back, there is only a status code, and there is no other set-cookie or tocken information. At the time, there is a great possibility that this login interface has this vulnerability. This is a relatively fatal vulnerability, then you may have other problems, even if he has such a vulnerability, but we are unlikely to have a large number of other accounts, the harm of this vulnerability is not used any code? This is the question I will say next.

0x01 traversing the phone number

Most of the websites now have the function of registering the mobile phone number. Generally speaking, the same mobile phone number can only register one account, so the mobile phone number can also be used as an account. This is a point that can be utilized when the mobile phone number can become When the account number, then the previous problems are solved in half. Since you know that the mobile phone is an account that can be used to log in, how do you get these mobile phone numbers? This question is actually a very good question. For the mobile phone number, there are a total of 11 digits. If you want to guess whether a mobile phone number has been registered on this platform, the probability of one-time guessing is very small, but some There is a way to use the forgotten password feature of the website (although most of the vendors are ignored), but I think his harm is still there. When we forget the password and enter the mobile phone number, when sending the mobile phone verification code, some websites will first check whether the mobile phone number has been registered on this website. If there is no, the prompt number does not exist, and if it exists, it will send a text message. Then you can use this logic to traverse the user's mobile phone number. By the way, the mobile number can be generated using the mobile number dictionary generator and then used to traverse.

As shown in the figure, if the user does not exist, it is additional information. We only need to identify the length length, or you can write your own py script to traverse the registered user. This point can get a large number of user phone numbers.

0x02 blastable mobile phone verification code

The method of front-end verification bypass and the way to get the user's mobile phone number are introduced. Next, I will explain the problem of the mobile phone verification code. I put a mind map for your reference.

The location where the mobile verification code exists may have three points: login, registration, and password recovery. The hazard of registering this point is relatively small, unless you find a point (褥 wool) that can be used to register accounts in bulk.

If the damage is large, the login and password will be retrieved. The actual principle of these two points is the same, but the environment used is different.

At present, the number of websites that log in using the mobile phone verification code is not a large percentage. This article explains how to retrieve the password.

Before we test, we first judge the length, timeliness and page presence of the mobile phone SMS verification code. It is difficult to use the image verification code directly recognized by the python library (the recognition rate is lower than the recognition rate). 50%). This is the first thing we should pay attention to, and then submit a form, grab the package to see if there is front-end encryption, or sign. I use the mobile phone verification code length to be 4 and 6 digits.

The first category: 4 -digit mobile phone verification code

When we found that the phone verification code is 4 digits long, the aging time is about 5 minutes, and there is no complicated front-end encryption or sign and complex picture verification code, then congratulations, you may find a verification code that can be burst out. The point, although the loophole is blasting, but the time it takes to use it is really very low, usually can be reset or log in a mobile phone number in a short time. This is a high-risk loophole for the manufacturer, I believe he will give you a good reward.

The above is a relatively simple vulnerability. I found a 4-digit verification code with a sign when I tested it some time ago. The difficulty of this blasting is improved. His sign is based on the current timestamp. And the information such as the mobile phone number verification code is generated after encryption, it is not realistic to solve this encryption algorithm. So I used a kind of sui ideas, maybe the big guys in the security world have also used it, that is python's selenium library to simulate browser automation click test, but this requires you to go according to the actual situation of the website and the window position. To write a script. Provide a learning link about selenium.

Second category: 6 -digit mobile phone verification code

Usually 6-digit verification code, 30-minute aging is a very safe design, because it is still quite difficult to run 100W data in 30 minutes, and the website usually limits according to the delivery rate. Once you The delivery rate breaks through the setting, you will be 403, that is, your IP will be banned for a while, the verification code with these settings is safe, but if the aging is 1 hour or even longer, and does not limit IP If the rate of delivery is high, then the utilization can be utilized, but the cost of utilization is too high, so it is basically not considered. Therefore, it is basically not to be considered in the map.

0x03 vulnerability case thinking and analysis in the real environment

Next, I will bring you a real vulnerability case, which is also a high-risk vulnerability that I have discovered. This vulnerability is an arbitrary login vulnerability in a blockchain community.

In the login interface, since the picture verification code is valid for a long time, the guess can be blasted.

It is found that the picture verification code will not change for a certain period of time through two submissions, although it has been verified once. Because the js discovery verification code is the verification code received by the mobile phone verification code after passing through the sha256 and taking 4 digits from the sixth digit. The verification code entered during the test is 1602.

Prove the encryption algorithm, so the script is used to generate an encrypted dictionary of 0000-9999 for blasting. During the blasting process, it was found that the time limit of the verification code was about 1 minute, which was not enough to complete the blasting. So I changed another way of thinking. Since there is no way to complete the verification code limitation by blasting, I think that the programmer will make a mistake when writing the code, guess if he will expire the verification code. Reset to a string of specific characters. Since there is such a conjecture, then it is necessary to carry out a wave of verification. First, according to his encryption algorithm, he finds that it is sha256, that is, each verification code data is only generated between 0-f, so it is generated. A 0000-ffff dictionary, for a wave of blasting, as guessed, blasting an unexpected value, of course not found in the first blasting process, the first time may be an accident, so I After borrowing someone else's mobile phone and making several attempts, I found that the value is fixed, then the loophole proved to be established.

This reveals a loophole in the arbitrary login account. This website has the problem of traversing the mobile phone number as mentioned before, so the result of combining these two points is that you can log in to any user.

Analysis: Combining these issues, I have a few suggestions for the manufacturer:

1. Do not put information verification on the front end when authenticating users.

2. The phone verification code is longer than 6 digits.

3. Don't return the specific information of the verification code in the return packet when sending the SMS check code (many programmers often love this when debugging the program)

4. Do not set the default verification code value when you do not get the verification code.

5. The verification code on the user registration page should be bound to the mobile phone. Do not display a verification code for multiple mobile phones (may trigger any account registration)

Note: This article is strictly prohibited for illegal use.

Source: DVPNET

We will continue to update Blocking; if you have any questions or suggestions, please contact us!