IMCAFS

Home

[6] payment vulnerability (0 yuan purchase)

Posted by millikan at 2020-04-11
all

Catalogue

Payment vulnerability is a very simple logic vulnerability.

There are two kinds of Companies in the world. One is not attacked by hackers, the other is attacked by hackers.

Therefore, enterprises pay more and more attention to network security. Such payment loopholes are so easy to find

But there must still be some. It's just a little secret.

The above "minimum hacker" packet capturing technology is very simple. Learn to use the packet capturing tool: burp suite.

Principle: payment vulnerability

There are two ways to access the payment result of merchant website, one is to make jump notification through browser, the other is to make asynchronous notification on the server side.

Payment loopholes can be roughly divided into:

Either way, it's through the packet capturing tool: burp suite changes the blocked packets to the data (price) it wants.

It's very, very simple. You only need to know how to use the grab tool: burp suite.

Actual combat: unlimited call fee (check)

This article only shows the simplest one, which can be seen in the case after the actual combat (no need to understand the code, just use burp suite).

Start, register your own account first.

Payment loopholes generally appear in the place of purchase and recharge.

The amount is 0.00 RMB. Go to the commodity center and brush

Click to buy it immediately. I find that I can't buy it without RMB in my account.

Hum, I changed the quantity of goods I bought into a negative number.

Click submit order.

The webpage is wrong, and what's surprising is that when you go back to the account center, you find that the money has arrived.

This is because the program is executed online at the same time as the error is reported.

Then why to change to a negative number to have a payment loophole???

When we buy CF point volume, the logic of the program is like this.

My account balance is 0.00, the current price of goods is 9.2, and the quantity I buy is - 1.

The program calculates: 0.00 - (9.2 * - 1)

= 0.00 - (- 9.2)

=0.00 + 9.2 (subtraction means addition)

= 9.2

Why is my 18.40? Can you guess??

The following payment vulnerabilities will be more difficult and do not require code auditing (i.e. no programming basis is required, and payment vulnerabilities are very simple).

How to dig

Grab tool: burp suite.

There may be three or four packets in a payment operation. We need to select the packets.

There will be a lot of sensitive information (account number, amount, balance, discount) in the payment data package. It is necessary to try to analyze each parameter in the data package.

Think more about what developers don't think

Dig a payment loophole in a website / APP. It is strongly recommended that the amount should not exceed 10 RMB. After the penetration test is successful, submit it as soon as possible. Do not keep it. Take care to wear rose gold handcuffs.

For some reason, I may not see it in the future, so I will move here first.

Show in order.

Case: modify the price paid

Three steps of payment - order, order, payment.

Vulnerability details

Disclosure status:

Brief description:

CITS buys any number of travel tickets in one yuan (payment logic loophole)

detailed description:

When buying tickets, CITS can grab bags through burp, modify the amount and number of people, and buy n tickets with one yuan after submitting.

The following is the screenshot after the data submission is modified in detail. Burp forgot the screenshot. You can try it yourself

Proof of loopholes:

Adultnum and childnum correspond to the number of adults and children, which can be modified to any value. After catching the data, change the amount into 1 piece. After submitting:

Repair plan:

You know. Please pay attention to the security. During the test, you can fill in the ID card and tourist name at will~

Case: modify payment status

Order completed - not completed (foolishly unclear)

Vulnerability details

Vulnerability Title: low price payment and high price order modification at will at the same journey travel interchange (another payment vulnerability)

Relevant manufacturers: Suzhou Tongcheng Tourism Network Technology Co., Ltd

Vulnerability type: design defect / logic error

Hazard level: medium

Disclosure status:

Brief description:

17u.net it's called brigade intersection now. I don't know what it means.

detailed description:

I don't know what is the calculation method in the background. In a word, the foreground can modify the order through the URL, and it doesn't need permission.

Proof of loopholes:

First register a number: 13111112343, and then place an order normally:

Click in the order to view the order:

Click back to modify.

Point submit.

Grab a bag.

The point is this URL:

After testing, this URL can update the order without logging in, that is, as long as you know OrderID, you can update the order. More importantly, OrderID is self-added, and it is easy to guess the OrderID number.

Next, let's change the list I just ordered. There are two places in the URL above: lineid and totalprice. They are the same as the existing products in the website after trial, so I found a cheap product,

The ID of this product is 1806901, and the price is 50,

Then take out the URL recorded above and modify it

Then we can execute it anywhere. Then we can see our order in the order. It has become 50 yuan,

But after all, it's a reservation, and there's human audit in it, so even if it's changed, it doesn't matter, but from the perspective of the program, it's a bug. Let's start with that

Repair plan:

DUANG

Case: modify order quantity

One pen, buy 0, or buy - 1? ?)

Vulnerability details

Disclosure status:

Brief description:

Payment loophole in the same journey

detailed description:

1: Defect URL.

2: The problem here is that some orders can be ordered for adults and children. We construct - 1 with the number of adults and positive number of children to make the money positive, and then the order can be submitted successfully.

3: Construct the screenshot of the order. The ticket is 88 yuan. The adult of - 1 and the child of - 2 are selected.

Results after submission:

4: Alipay payment amount chart:

Proof of loopholes:

Construct the screenshot of the order. The ticket is 88 yuan. The adult of - 1 and the child of - 2 are selected.

Results after submission:

Figure of Alipay's payment amount:

Repair plan:

Don't let negative numbers be submitted.

Case: unlimited trial

You only need to know the bank credit card number to consume.

Vulnerability details:

Vulnerability Title: Yilong travel network has a serious payment vulnerability (you only need to know the bank credit card number to consume)

Related manufacturers: Yilong travel.com

Vulnerability type: design defect / logic error

Hazard level: high

Disclosure status:

Brief description:

Thank you for your support. Let's go together.

detailed description:

First of all, in elong casually placed an order, to the payment page, choose credit card payment.

Enter the correct card number, expiry date.

Input the name, ID card and other relevant information at will.

The payment was successful.

So here comes the question....

This means that only the validity of the credit card can be judged to make a successful payment.

Then it's easy. We just need to try to blow up the validity of the credit card.

And then finding the wrong validity period can make the order reach the stage of judging whether the payment is successful.

Proof of loopholes:

So, place multiple orders.

Order + expiry date burst, every few seconds.

If the order is paid successfully, the validity period is correct.

Successfully burst out the validity period of credit card and successfully paid.

Repair plan:

Is the credit card payment logic composed of valid period + CVV code + mobile phone verification code??

How to defend

Payment vulnerability FAQ summary

(1) What are payment loopholes?

(2) Is payment loophole harmful?

(3) Are payment vulnerabilities common?

(5) The principle of quick payment?

(6) Does the payment vulnerability need code audit?

(7) What is the core idea of payment vulnerability mining?

(8) Common payment vulnerabilities:

(9) How to modify the payment price?

(10) How to modify payment status?

(11) How to modify order quantity?

(12) How to modify the preferential price and use restriction of the preferential volume?

(13) How to pay beyond authority?

(14) Is the payment vulnerability only on the web side?

(14) What if the secret is passed?

(15) How to prevent payment loopholes?

(16) How to prevent the loopholes of ultra vires payment?

(17) How to deal with the loophole of shooting range payment?

(18) What is the core of payment vulnerabilities and other logic vulnerabilities?

(19) Are there any magic cases?

(20) How to improve their own mining in payment loopholes?