Chuyển đến nội dung chính
  1. Nghiên cứu & Ghi chép kỹ thuật/

Lỗ hổng Blind OS command injection

·1189 từ·6 phút
Nguyễn Hoàng Thanh Phong
Tác giả
Nguyễn Hoàng Thanh Phong
Sinh viên năm cuối ngành An toàn thông tin tại Đại học FPT. Chuyên nghiên cứu khai thác lỗ hổng bảo mật Web, kiến trúc bảo mật AWS và các công cụ tự động hóa
Web Security Iaw301 - Bài viết này là một phần của loạt bài.
Phần 13: Bài viết này

Hỏi & Đáp
#

  1. Blind Command Injection là gì và nó khác biệt như thế nào so với các lỗ hổng classic command injection?
  • Blind Command Injection là một dạng lỗ hổng OS command injection mà ứng dụng thực thi lệnh hệ điều hành do kẻ tấn công kiểm soát trên server, nhưng không trả về kết quả (output) của lệnh đó trong HTTP response. Theo PortSwigger, nhiều trường hợp OS command injection là dạng blind vì lệnh chạy ở phía server (server-side), nhưng kết quả không được hiển thị lại cho người dùng.
  • Điểm khác biệt chính so với classic command injection nằm ở khả năng hiển thị output. Trong classic command injection, kẻ tấn công có thể thấy trực tiếp kết quả của lệnh trong web response (ví dụ: username hiện tại, thông tin hệ thống, hoặc thông báo lỗi). Với blind command injection, lệnh vẫn có thể thực thi thành công, nhưng kẻ tấn công không thể thấy trực tiếp kết quả, do đó họ phải sử dụng các kỹ thuật gián tiếp để xác nhận việc thực thi.
  1. Những thách thức của Blind Command Injection và cách attacker suy luận lệnh đã được thực thi thành công
  • Blind Command Injection khó phát hiện và khai thác hơn vì ứng dụng không đưa ra bất kỳ phản hồi trực tiếp nào. Ví dụ, một lệnh test bình thường như echo có thể thực thi, nhưng output sẽ không xuất hiện trong response, khiến kẻ tấn công không thể xác nhận ngay lập tức payload có hoạt động hay không.
  • Kẻ tấn công có thể xác nhận lệnh thực thi thành công qua các phương pháp:
  • Time delays (Độ trễ thời gian): Kẻ tấn công inject một lệnh cố ý làm server phản hồi chậm lại. Nếu thời gian phản hồi bị trễ đúng bằng khoảng thời gian dự kiến, điều này chứng tỏ lệnh đã được thực thi.
  • Output redirection (Chuyển hướng đầu ra): Nếu kẻ tấn công có quyền ghi vào một thư mục có thể truy cập qua web, họ có thể chuyển hướng kết quả của lệnh vào một file, sau đó tải file đó qua trình duyệt. Cách này giúp đọc được output gián tiếp dù nó không nằm trong HTTP response ban đầu.
  • Out-of-band interaction (Tương tác ngoài băng tần): Kẻ tấn công inject một lệnh ép server tạo một request DNS hoặc HTTP đến một domain do họ kiểm soát. Nếu kẻ tấn công nhận được tương tác này, họ biết lệnh đã chạy. PortSwigger cũng lưu ý kỹ thuật này có thể dùng để exfiltrate (tuồn) dữ liệu output ra ngoài thông qua external request.

Khai thác Blind OS command injection bằng time delays
#

Bước 1: Mở lab PortSwigger Web Security Academy
#

Đầu tiên, mở lab PortSwigger có tên “Blind OS command injection with time delays”. Mục tiêu của lab là khai thác lỗ hổng blind OS command injection trong chức năng feedback và làm cho server phản hồi chậm khoảng 10 giây.

Đây là trường hợp blind command injection vì ứng dụng không hiển thị output của lệnh hệ điều hành trong HTTP response. Do đó, việc inject thành công phải được xác nhận gián tiếp qua việc quan sát thời gian phản hồi (response time).

Bước 2: Truy cập chức năng submit feedback
#

Sau khi vào lab, chuyển đến trang Submit feedback. Trang này chứa một số trường nhập liệu bao gồm Name, Email, Subject, và Message. Theo mô tả của lab, lỗ hổng nằm ở chức năng feedback, nên form này là mục tiêu kiểm thử chính.

Bước 3: Bắt request gửi feedback bằng Burp Suite
#

Tiếp theo, sử dụng Burp Suite để bắt HTTP request được tạo ra khi submit form. Sau khi điền các giá trị test bình thường và gửi đi, Burp Suite ghi nhận một request POST gửi đến endpoint /feedback/submit.

Body của request chứa các parameter:

1
2
3
4
5
csrf=...
name=Test Name
email=test@example.com
subject=test Subject
message=test message

Sự xuất hiện của các tham số do người dùng kiểm soát đồng nghĩa với việc chúng có thể là các injection point (điểm chèn payload).

Bước 4: Gửi request tới Burp Repeater
#

Gửi request vừa bắt được sang Burp Repeater. Repeater cho phép chỉnh sửa và gửi lại request nhiều lần để quan sát phản hồi từ server.

Trước khi sửa request, gửi nguyên bản một lần để hiểu hành vi bình thường của ứng dụng. Server trả về response HTTP/2 200 OK bình thường với một body JSON ngắn. Không có output của lệnh nào xuất hiện, xác nhận đây là kịch bản blind test.

Bước 5: Kiểm thử parameter email để tìm command injection
#

Tập trung vào tham số email vì solution của PortSwigger cho lab này dùng trường email làm injection point. Để test blind OS command injection, sửa giá trị email bằng cách nối thêm một command separator (dấu phân cách lệnh) và một lệnh time-delay.

Payload được sử dụng trong request:

1
email=test@example.com||sleep+10||

Trong payload này, || đóng vai trò là shell command separator. Nếu ứng dụng đưa giá trị email vào một OS command mà không sanitize (làm sạch) đúng cách, lệnh sleep 10 được inject sẽ bị server thực thi.

Bước 6: Gửi request đã chỉnh sửa và quan sát thời gian phản hồi
#

Sau khi gửi request đã chèn payload trong Burp Repeater, nhận thấy server mất khoảng 10 giây để trả về response. Độ trễ này không xảy ra với request bình thường.

Sự khác biệt về thời gian này là bằng chứng mấu chốt của blind OS command injection. Dù server không trả về bất kỳ output hiển thị nào, phản hồi bị delay chứng tỏ lệnh đã được thực thi thành công ở server-side.

Bước 7: Xác nhận lỗ hổng
#

Để xác nhận, tiến hành so sánh hai request:

1
2
Request bình thường:
email=test@example.com

Request này phản hồi rất nhanh.

1
2
Request bị inject:
email=test@example.com||sleep+10||

Request này gây ra độ trễ rõ rệt khoảng 10 giây.

Vì độ trễ chỉ xảy ra khi thêm payload, điều này chứng minh ứng dụng tồn tại lỗ hổng blind OS command injection.

Bước 8: Lab hoàn thành
#

Sau khi thực hiện thành công injection bằng time-delay, trạng thái lab chuyển sang Solved. Điều này có nghĩa ứng dụng đã ghi nhận điều kiện khai thác mà lab yêu cầu.

Lỗ hổng được khai thác thành công bằng cách inject một OS command vào tham số email của form feedback và xác nhận việc thực thi thông qua độ trễ của server.

Tổng kết
#

Trong lab này, ứng dụng bị lỗi do thực thi một shell command chứa dữ liệu từ người dùng (feedback) mà không có cơ chế input validation hoặc xử lý an toàn. Vì output của lệnh không được trả về trong HTTP response, lỗ hổng này mang tính chất blind (mù). Cuộc tấn công được xác nhận bằng cách inject một lệnh time-delay vào tham số email và quan sát thấy server response bị trễ khoảng 10 giây.

Web Security Iaw301 - Bài viết này là một phần của loạt bài.
Phần 13: Bài viết này