Logical vulnerability (unauthorized access and payment vulnerability)

Posted by davidmuir on Wed, 19 Jan 2022 02:40:13 +0100

This column is the author's network security learning notes, which are shared and used as notes at the same time

Previous link

  1. Construction of Wamp / DVWA / sqli Labs
  2. Use of burpsuite tool to capture packets and Intruder brute force cracking
  3. Use of directory scanning, request retransmission, vulnerability scanning and other tools
  4. Website information collection and download and use of nmap
  5. SQL injection (1) -- understand the causes and manual injection methods
  6. SQL injection (2) -- various injections
  7. SQL injection (3) -- SQLMAP
  8. SQL injection (4) -- actual SQL injection takes webshell
  9. Me and my girl friend of Vulnhub target penetration
  10. XSS vulnerability
  11. File upload vulnerability
  12. File upload bypass
  13. File contains vulnerability
  14. Zico 2 of Vulnhub target penetration
  15. Command Execution Vulnerability

introduce

Logical vulnerability refers to an attacker taking advantage of the design defects of the business to obtain sensitive information or destroy the integrity of the business. It usually appears in password modification, unauthorized access, password retrieval, transaction payment amount and other functions. This article focuses on ultra vires access vulnerabilities and transaction vulnerabilities.

Logic vulnerabilities are manifested in the incorrect judgment of developers or designers on logic in the development process, that is, they are not careful enough to write code, and the resulting vulnerabilities are caused by human beings.

Ultra vires visit

It is divided into horizontal ultra vires and vertical ultra vires.

  • Horizontal ultra vires: illegal operations in which users of the same level (permission) or different users in the same role can access, modify or delete other user information ultra vires. If this vulnerability occurs, it may cause the disclosure of a large number of data, and even cause the malicious tampering of user information.

  • Vertical ultra vires: ultra vires between users at different levels or between different roles. For example, ordinary users can perform functions that can only be performed by administrators.

In my actual penetration, I once encountered a horizontal ultra vires vulnerability in a website. At that time, some parts of the website needed to invite new users or recharge to access, but as a 0 krypton user, I couldn't do this. However, I found that there is a horizontal ultra vires vulnerability in the packet capture. I can view and modify the passwords of other users. So I always use someone else's account. That website has not fixed this vulnerability yet.

The most common case of vertical ultra vires is that ordinary users perform administrator operations. For example, in DedeCMS, ordinary users can illegally modify the password of the administrator (admin). And the above code execution vulnerability, so that ordinary users have the right to manipulate the server. All belong to vertical ultra vires.

As usual, let's start with an example.

A website can view user passwords, but there is an unauthorized access vulnerability.

Since it is only an instance, the database is not connected here.

index.php

<?php
    $users=array(
        "1"=>"123456",
        "2"=>"HelloWorld",
        "3"=>"manlu"
    );
    if (isset($_COOKIE['id'])){
        $id=$_COOKIE['id'];
    }else{
        setcookie("id",'1');
        header("Refresh:0");
    }
?>
<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport"
          content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>View user information</title>
</head>
<body>
<label for="id">user id: </label>
<input type="text" id="id" value="<?=$id?>"><br>
<label for="pwd">User password:</label>
<input type="password" id="pwd" value="<?=$users[$id]?>"><button>see</button>
<script>
    document.getElementsByTagName('button')[0].onclick=function () {
        document.getElementById("pwd").type="text";
    }
</script>
</body>
</html>

Access this interface to see the password of the user with id 1.

Press F12 to view the cookie and find the parameter id

If you change the parameter id to another number, you can see the passwords of other users.

When id is 2

This is a horizontal unauthorized access vulnerability.

If a website with horizontal ultra vires vulnerability allows users to change their passwords, the attacker can modify the passwords of other users, and cooperate with the script to obtain the information of all users.

Vertical ultra vires
As in the previous example, if the user table also stores the admin account and password, you can illegally get the admin account and password.

$users=array(
        "0"=>"admin",
        "1"=>"123456",
        "2"=>"HelloWorld",
        "3"=>"manlu"
    );

Payment vulnerability

Common payment vulnerabilities include:

  • Payment order: when paying an order, you can change the price to any amount; Or you can tamper with the fact that freight or other expenses are negative, resulting in a decrease in the total amount.

  • Competitive conditions: mentioned in the file upload vulnerability above, it can be used in A variety of scenarios. If the balance of user A is 10 yuan, the price of commodity B is 6 yuan and the price of C is 5 yuan, if A wants to buy B and C, the balance is not enough. However, if A uses competition conditions and uses multiple threads to send requests to buy goods at the same time, the following results may occur:
    ① One item was purchased successfully
    ② The goods were purchased successfully, but only 6 yuan was deducted
    ③ All goods are purchased successfully, and the balance becomes - 1

Direct upper instance

index.php

<?php
    $balance=0;
    if (isset($_COOKIE['balance'])){
        $balance=(double)$_COOKIE['balance'];
    }else{
        setcookie("balance","10");
        header("Refresh:0");
    }
?>
<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport"
          content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>purchase</title>
</head>
<body>
<div>
    <h2>Balance:<?=$balance?></h2>
</div>
<form id="form">
    <label for="price">Commodity price:</label><br>
    <input type="text" disabled="disabled" value="6"><br>
    <label for="number">Purchase quantity:</label><br>
    <input type="number" id="number" value="1" name="number"><br>
    <input type="button" value="Confirm purchase" id="btn">
</form>
<script>
    document.getElementById("btn").onclick=function () {
        var form=document.getElementById("form");
        var formdata=new FormData(form);
        formdata.append("price",'6');
        var xhr=new XMLHttpRequest();
        xhr.open("POST","buy.php",true);
        xhr.send(formdata);
        xhr.onreadystatechange=function()
        {
            if (xhr.readyState==4 && xhr.status==200)
            {
                var text=xhr.responseText;
                alert(text);
                location.reload();
            }
        }
    };
</script>
</body>
</html>

buy.php

<?php
    $price=(double)$_POST['price'];
    $number=(int)$_POST['number'];
    $balance=(double)$_COOKIE['balance'];
    $money=$number*$price;
    if ($balance>$money){
        setcookie("balance",(string)($balance-$money));
        echo "Purchase successful";
    }else{
        echo "Sorry, your credit is running low";
    }
    ?>

There are two ways to exploit vulnerabilities, the modified quantity and the modified amount (it is not possible to modify the balance. The balance in the actual penetration is stored in the database, which is stored in cookie s for convenience).

Visited the website and found that he gave us 10 yuan

It is found that the purchase quantity can be modified here.

Open bp, click to confirm the purchase and capture the package for viewing.

Here, change the purchase quantity number to - 1

After sending, the purchase is successful. It is found that the balance has changed to 16

In addition, you can also modify the commodity amount, or the same packet capture, and change the amount price to - 10

Send, pop-up, purchase succeeded

The balance was found to be 20

The competitive conditions are not covered up here and can be tested by ourselves.

to guard against

Ultra vires visit
Strictly check the user's cookies and confirm their identity

Purchase vulnerability
Strictly handle user input, do not trust the front-end specification, and take precautions at the back-end.

Topics: PHP security