Network Security Advanced Learning Lesson 17 - Business Logic Vulnerability (Payment&&Authentication&&Password Retrieval)

---

1. Payment loopholes

1. Modify the payment price

– – In payment, purchasing goods is generally divided into three steps: ordering, confirming information, and payment.
– – So at which step is this modified price specifically modified?

• In my opinion, you can modify the price test in any one of these three steps. If there is a verification mechanism in the first two steps, then you can capture the package and try to modify the amount when paying in the last step. If not in the last step, If you do a good inspection, then the problem will exist. You can try a small number or a negative number to modify the amount value.

2. Modify payment status

– – There are interfaces that can modify the order status, such as the interface to confirm receipt. After the receipt is confirmed, the order status will change to "Completed".

– – Example: There is the following interface/setorderstatus?orderid=1093&orderstatus=3, orderstatus=1 is pending payment, orderstatus=2 has been paid, and orderstatus=3 has been completed. Using the above interface, you can directly change the status of the order to be paid to paid.

3. Modify the purchase quantity

– – For example: I purchase two items with the same price and the same quantity. One of them has the same quantity, but the other quantity is changed to a negative number. When the payment is combined, they will offset each other and the price will become 0.

4. Modify the attached value

When the price of the product cannot be modified, I try to modify the value of the accessory value to a negative value to offset the total cost.

1. Modify coupon amount
2. Modify points amount
3. Modify shipping amount

5. Modify the payment interface

– – For example, some websites support many types of payments, such as their own payment tools and third-party payment tools, and each payment interface value is different. If the logic is not designed properly, when I randomly select a click to pay, I will capture the packet and then modify it. Its payment interface is a non-existent interface. If the processing related to the non-existent interface is not done, the payment will be successful at this time.

6. Multiple replacement payments

– – First generate two orders. The products of these two orders are different and their prices are different. If the server does not do this related verification, then it will capture the package during the payment process and modify the order value to another An order value is paid at the end. At this time, the goods of order 2 can be purchased with the payment price of order 1.

7. Repeat payment

– – For example, payment for an order will give you cash back or points. Repeatedly calling the payment success callback interface can achieve multiple cash rebates or multiple points rebates.

8. Minimum payment

– – This problem is that if you modify the payment amount when recharging to a negative number or 0.01, the payment will be displayed as failed, but if you modify the amount to 1.00, the payment will be successful.

– – The minimum here is 1 yuan, and 1 yuan corresponds to 100 points. If you change it to 0.01, the corresponding points will be null, so it will show failure. And when you change it to 1 yuan, then the payment interface for 1 yuan is Yes, the subsequent area score is the number of points of other amounts, and then if you jump to the past payment, you will buy a much larger number of points for 1 yuan, or it can be any point value.

9. The value is the maximum value payment problem

– – For example, if you purchase goods on some websites, there are two ways to modify the value. The first is to directly modify the payment amount value to the maximum value, such as 999999999, or modify the ancillary value, such as coupons, points, etc. to 999999999. If the logic design here is problem, then the payment amount will become 0.

– – Or use integer overflow to change the purchase amount to 99999999999999999999999999999999, so the payment amount may become 0.

10. Payment beyond authority

– – This kind of problem may rarely exist now. The current user’s ID will appear during payment, such as: username=XXXXX. If it is not verified, the payment is a one-time payment without a password or other mechanism, so it can be modified. This user ID is the ID of another user, so you can use other users' accounts to pay for your products.

11. Unlimited trial

– – Some products on some websites, such as cloud series products, support trial. The trial period is generally 7 days or 30 days. An account can only be tried once and cannot be tried again during the trial period. But if the trial interface will be allocated, it will be easy. cause problems to occur.

– – For example: when paying, the payment interface behind the URL is 3, and the trial interface is 4, then you have already used it. Copy the URL when confirming the trial, and modify the subsequent payment interface to 3, then this The purchase payment interface will be called, but since your product is for trial and its corresponding value is bound to the trial product, the amount must be 0. Then click Pay finally and you can see that the payment is successful and the trial is successful. , tried it again, and then their trial time will be accumulated together, which results in the unlimited purchase of any product.

12. Multi-thread concurrency

• Simulate a scenario:
  withdraw cash from the website

  • Normal request: User A withdraws money on a website and sends a withdrawal request. A withdrawal request is displayed in the background, reviewed and successfully mentioned.
  • Concurrent requests: User A made a withdrawal on a website and sent multiple withdrawal requests simultaneously. Multiple withdrawal requests were displayed in the background. After review, the bounty was successfully mentioned several times.

• Generally speaking, multiple withdrawal requests are sent at one time, allowing the background to process them at the same time. This achieves the purpose of withdrawing money several times.

• Another way of thinking is to cancel the withdrawal when you normally withdraw money from the balance, so that the money will be returned to the balance. When we try to intercept the request packet on the withdrawal operation, and then use the replay module to resend multiple withdrawal cancellation requests at one time, the server will process these requests at the same time, and use this method to increase the balance of the account.

---

2. Verify security

1. Common verification code types:

2. Graphic verification code bypass

1) The graphic verification code does not refresh or is invalid

– – After a manual login attempt, no matter how many failed login attempts are made within a certain period of time, as long as the session does not expire without refreshing the page, the same verification code can be used unlimited times to violently guess one or more user accounts. .

2) The graphic verification code value can be obtained directly

– – The verification code is usually hidden in the source code of the website or in the cookie of the request, or returned in the response packet.

3) Graphical verification code parameter bypass

Login request packet data: user=admin&pass=1234&vcode=brlnYou
can try the following two bypass methods:

1. Bypass the null value of the verification code, change it to user=admin&pass=1234&vcode=
2. Directly delete the verification code parameter and change it to user=admin&pass=1234

Login request packet data: user=admin&pass=1234&needcode=1&vcode=brlnYou
can try changing the value of the needcode parameter to 0

4) There is a page without verification code

– – After testing, if we find that the website verification code itself is not defective, then we can try to find some other login pages or interfaces to try to brute force crack. Such as hidden pages, test pages, old version pages, etc.

5) Universal verification code

– – During the penetration testing process, this situation sometimes occurs. There is a universal verification code in the system, such as 0000 or 9999. As long as you enter the universal verification code, you can ignore the verification code and perform brute force cracking. This kind of universal verification code is usually left behind by developers who forget to delete it during testing.

6) The number of verification codes is limited

– – Commonly seen in calculation type verification codes, such as 1+2=? , this type of verification code cannot be called verification code in the strict sense. If we refresh the verification code a few more times, we may find that there are only a few arithmetic questions in the system. In this case, we only need to download all the verification codes and generate An md5 library, and then compare the verification code generated by the front end with the local file.

7) Simple verification code recognition

– – In the normal vulnerability mining process, if we find that the login verification code is very simple and easy to identify, then we can try to use automated tools to crack the login, such as PKAV’s HTTP Fuzzer, bp plug-in, etc.

8) Verification code reuse

– – When you open some common systems that require login, usually the system will automatically request a verification code, capture the packet, grab it, and keep the session unchanged.

3. Bypass SMS verification code

1) The SMS verification code can be violently enumerated within its lifetime.

– – Not much to say, just use the verification code to brute force the account password before it expires.

2) The SMS verification code is returned in the data packet

3) Modify request packet parameters or cookie values ​​to bypass

– – For example, there is a post packet: mobile=18888888888&userid=00001, and the cookie contains: codetype=1

– – In a specific step, modify mobile = your own mobile phone number, and you can receive other people’s verification codes on your mobile phone, and then use other people’s mobile phone numbers and received verification codes to log in later;

– – Modify suspicious parameters and values ​​in Cookie to bypass them, for example, modify codetype=0 above

4) Modify the return package to bypass

– – Let’s take a simple example: submit an incorrect SMS verification code, and the returned package contains: status=false. Use Burpsuite’s “Do intercept” function to intercept the response package, and modify the response package status=true to bypass the front-end judgment. , successfully entered the system. The specifics must be combined with actual scenarios and operated flexibly.

5) Break through the SMS verification code interface

– – It’s equivalent to when I tested Ping An Insurance and found that the verification code interface was provided by the mobile company. I called the mobile company in order to obtain the verification code.

6) Default universal verification code

– – I have encountered a vulnerability before that you can log in to any user account by entering 9999 as the SMS verification code.
In order to facilitate testing and maintenance, some systems will leave a universal verification code, which will be retained after going online. It may be fixed in the configuration file, js file or code, or it may change over time.

4. Identity authentication security

1) Brute force cracking

– – Where there are no verification code restrictions or a verification code can be used multiple times, use known users to brute force passwords or use a common password to brute force users.
Simple captcha blasting.

2) session & cookie class

– – Session fixation attack: Use the server’s session immutability mechanism to obtain authentication and authorization by others, and impersonate others.

– – Cookie counterfeiting: modifying a parameter in the cookie can log in other users (Chrome plug-in: EditThisCookie).

3) Weak encryption

– – Front-end encryption, breakable, or no encryption at all.

---

3. Password retrieval vulnerability

1. General process of password retrieval logic test

1. First try the normal password retrieval process, choose different retrieval methods, and record all data packets
2. Analyze data packets to find sensitive parts
3. Analyze the verification methods used by the background retrieval mechanism
4. Modify packet verification speculation

2. Password retrieval vulnerability classification

1) Verification code brute force cracking

• Generally, the mobile phone password is a 6-digit pure number, and if it survives for more than ten minutes, you can try to brute force it.

2) The verification code is returned directly

• The server directly returns the verification code, such as a password retrieval package returned by an APP.

3) Skip the verification step

• After entering the reset account, skip the verification step and directly access the reset password page. There is no need to enter the verification code at this time, just change step2 in the link to step3, as shown below:

4) Bind using email and mobile phone number

• When binding a user's mailbox, you can bind other users' mailboxes to your own by modifying the uid, thereby resetting the user's password at will. It is equivalent to using the recharge password step to change the victim's bound mobile phone to mine, then I can use my own mobile phone to log in to other people's accounts.

5) Third-party login binds other users

• For example: when binding a Weibo account, first log in to Weibo and obtain the code, and then the request to bind the code and UID is as follows:
  • thirdPartyType=1&uid=60570181&state=test&code=fb3a6454736e15534486c5a214067943
• By modifying the uid, you can bind your Weibo to other user accounts, and then log in to any user account by logging in through Weibo.

6) There is no verification whether the mobile phone number accepted by the verification code is consistent with the username or session.

• For example, the request to send a verification code is as follows:
  username=***&mobilePhone=***&randcodeAjax=6119
• There is no verification that the username is consistent with mobilePhone. You can accept the verification code by modifying mobilePhone for your own mobile phone number.

7) Local verification bypass

• The client locally judges whether the verification code is correct, and the judgment result can also be modified locally, which ultimately leads to deceiving the client into thinking that we have entered the correct verification code.
• For example, changing the 0 in the returned packet to 1 can bypass the verification.

8) The last step of resetting the password is controllable by uid or username.

• The last step of resetting the password is to reset the account through the uid or username passed by the user, so that changing the UID can reset the passwords of other users.

9) Logic error in password modification in Personal Center

• The checksum of the current password and the new password are two separate packages. So it can be understood that the current password is not verified.
• The request to change the password is as follows:
  ssouid=***&passwd=***
• Just modify the ssouid.

10) Use session to rebind the user

• The last step in resetting the password is to obtain the username through the session and then reset it.
• The username is bound to the session in the first step of resetting the password;
  then if the last step of resetting the password does not verify whether the user has completed the verification process, then you can rebind the session to another account. So as to achieve any password reset purpose.

11) Remove verification parameters to bypass verification

• The email system's password retrieval function has a design logic error and an authentication bypass vulnerability;
• By capturing the data packet, you can modify the message, delete the parameters for retrieving the answer to the question, and then change the password directly. That is to say, capture the packet, remove the verification fields such as the verification code in the packet, and then re-insert the packet.

---