2.9K 221 103

Đã đăng vào thg 11 29, 2022 3:55 SA 5 phút đọc

373

Business logic vulnerabilities - Các lỗ hổng business logic (Phần 2)

III. Phân tích khai thác một số lỗ hổng Business logic (Tiếp)

2. Xử lý các đầu vào không hợp lệ (unconventional input) từ người dùng

Một trong những hậu quả mang lại từ những đầu vào không hợp lệ là khả năng tiết lộ các thông tin nhạy cảm trong hệ thống (đã được chúng ta bàn tới trong chủ đề Information disclosure vulnerabilities). Bên cạnh đó, chúng còn có thể khiến quy trình hoạt động của trang web bị thay đổi, dẫn đến kết quả xử lý cũng sai lệch. Chúng ta xem xét một số dạng nhỏ sau:

Dạng 1: Phạm vi giới hạn dữ liệu không chặt chẽ - Thiếu giới hạn dưới

Việc thiếu giới hạn dưới thường dẫn tới người dùng có thể yêu cầu giao dịch với những số liệu âm, dẫn đến xử lý sai lệch của hệ thống. Xem xét đoạn code thực hiện kiểm tra trước quy trình chuyển tiền sau:

$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();

if ($transferAmount <= $currentBalance) {
    // Complete the transfer
} else {
    // Block the transfer: insufficient funds
}

Đoạn code chỉ kiểm trả số lượng tiền chuyển $transferAmount có nhỏ hơn số dư hiện tại $currentBalance hay không. Điều đó dẫn người dùng A có thể yêu cầu chuyển một số lượng giá trị âm số tiền tới người dùng B. Khi $transferAmount nhận giá trị âm thì vẫn thỏa mãn điều kiện $transferAmount <= $currentBalance, bởi vậy giao dịch được thông qua và thực hiện. Chẳng hạn, người dùng A yêu cầu chuyển $-100 tới B, hệ thống sẽ xử lý tài khoản của người dùng A trừ đi $-100, còn người dùng B được thêm $-100, hay có nghĩa là người dùng B "bị chuyển" $100 đến A.

Phân tích lab High-level logic vulnerability

Miêu tả: Trang web mua sắm trên có một quá trình kiểm tra không chặt chẽ đối với tham số từ người dùng, dẫn đến lỗ hổng có thể mua sắm sản phẩm với số lượng ngoài mong muốn. Để vượt qua bài lab, chúng ta cần mua thành công sản phẩm "Lightweight l33t leather jacket". Tài khoản hợp lệ được cung cấp: wiener:peter.

Đăng nhập với tài khoản wiener:peter. Tại phần xem chi tiết sản phẩm "Lightweight l33t leather jacket", chúng ta có thể thêm món hàng vào giỏ với số lượng tùy ý, tuy nhiên trang web thiết lập trị nhỏ nhất bằng 0.

Nghĩa là trong front-end server chúng ta không thể thêm sản phẩm vào giỏ với số lượng nhỏ hơn 0:

Tuy nhiên, dự đoán điều này chỉ được quy ước ở front-end server, rất có thể back-end server không kiểm tra điều này. Thử thay đổi giá trị tham số quanlity qua Burp Suite, chúng ta nhận được phản hồi mong muốn:

Sản phẩm với số lượng -1 đã được thêm vào giỏ hàng, khi đó giá mua cũng sẽ có giá trị âm:

Chúng ta cũng có thể thay đổi thuộc tính min của số lượng sản phẩm bằng công cụ DevTool, nguyên lý hoạt động tương tự:

Đặt hàng với tùy chọn Place order để hoàn thành bài lab.

Dạng 2: Phạm vi giới hạn dữ liệu không chặt chẽ - Thiếu giới hạn trên

Bên cạnh việc thử giá trị tham số nằm dưới giới hạn thông thường, chúng ta cũng có thể thử nhập các giá trị tham số vượt ngoài ngưỡng giới hạn, điều này có thể dẫn tới sự "quay vòng" dữ liệu. Ví dụ trong đoạn code C++ sau:

#include <iostream>
using namespace std;

int main()
{
    int a = 2147483647, b = 1;
    int c = a + b;
    cout << c;

    return 0;
}

Chúng ta thu được -2147483648. Là do kết quả phép tính a + b thực tế bằng 2147483648 đã vượt qua phạm vi kiểu dữ liệu int trong C++ là 2147483647. Bởi vậy giá trị kết quả được quay ngược trở lại giá trị nhỏ nhất trong kiểu dữ liệu int.

Phân tích lab Low-level logic flaw

Source code quy định giá trị tối thiểu và tối đa của tham số quantity:

Trong trường hợp này, trang web không cho phép số lượng món hàng nhận giá trị âm ở cả front-end server và back-end server:

Trang web chỉ cho phép tăng số lượng đơn hàng tối đa bằng 99, nếu vượt quá 99 sẽ nhận về thông báo lỗi

Như vậy tham số quantity có giới hạn, chúng ta có thể dự đoán giá trị total price cũng tồn tại giới hạn. Giả sử hệ thống sử dụng biến kiểu int đặt cho total price, giới hạn của biến int trong khoảng [-2 147 483 648; 2 147 483 647]. Như vậy ta có thể tăng số lượng đơn hàng liên tục, mục đích để tổng giá trị sản phẩm vượt ngưỡng giới hạn trên, khi đó bộ đếm sẽ quay vòng và bắt đầu từ giá trị âm.

Sử dụng Burp Intruder với Null Payloads:

Thử liên tục các payloads cho tới khi thu được kết quả âm:

Mua thêm món hàng khác để total price trở về giá trị dương và nhỏ hơn $100.

Lúc này chúng ta có thể thực hiện đặt hàng:

Một trường hợp khác cho việc xử lý tràn dữ liệu trong việc xác thực mail:

Phân tích lab Inconsistent handling of exceptional input

Miêu tả: Trang web có một quá trình kiểm tra không chặt chẽ đối với tham số từ người dùng. Chúng ta cần khai thác để có thể truy cập vào trang quản trị và xóa tài khoản người dùng Carlos.

Trang quản trị administrator tại thư mục /admin (sử dụng tool Dirsearch hoặc Discover Content trong Burp Suite).

Trang web yêu cầu chúng ta cần có vai trò là DontWannaCry user.

Thông qua trang đăng ký, để trở thành người dùng có vai trò DontWannaCry, email cần có địa chỉ @dontwannacry.com.

Chú ý giá trị email trang web yêu cầu chúng ta nhập vào chỉ cần thỏa mãn điều kiện dạng A@B:

Thử khai thác lỗi logic flaw với tham số email, đăng ký với một email có chuỗi ký tự lớn:

Sau khi đăng nhập, trang web hiển thị email chúng ta đăng nhập nhưng chỉ có 255 kí tự, điều này chứng tỏ hệ thống có bộ đọc giới hạn ở 255 kí tự

Đăng kí một email có dạng A@dontwannacry.com.exploit-ac771f1f1f9f88cfc027167b018600eb.web-security-academy.net với điều kiện A@dontwannacry.com có đúng 255 kí tự, như vậy khi đăng kí, hệ thống sẽ gửi link xác nhận tài khoản vào email của chúng ta, nhưng đối với cơ chế xác thực danh tính admin thì chỉ đọc được 255 kí tự đầu nên email chúng ta chỉ dừng lại ở dontwannacry.com phù hợp với tiêu chí xác thực.