Hỏi & Đáp#
- Lỗ hổng OS Command Injection là gì và nó khác biệt như thế nào so với các loại tấn công injection khác?
- Lỗ hổng OS Command Injection xảy ra khi ứng dụng truyền dữ liệu đầu vào (user input) không an toàn trực tiếp vào shell của hệ điều hành, cho phép kẻ tấn công thực thi các lệnh hệ thống. Khác với SQL injection (nhắm vào các câu truy vấn cơ sở dữ liệu), mục tiêu của OS command injection là hệ điều hành của máy chủ (server’s OS).
- Kẻ tấn công khai thác lỗ hổng này như thế nào và tác động tiềm ẩn là gì?
- Kẻ tấn công có thể khai thác lỗ hổng này bằng cách chèn (inject) các ký tự đặc biệt hoặc các lệnh hệ thống vào các trường dữ liệu đầu vào được xử lý bởi server. Điều này có thể dẫn đến việc thực thi lệnh trái phép, đọc hoặc xóa file, đánh cắp dữ liệu, leo thang đặc quyền (privilege escalation), gián đoạn dịch vụ, hoặc chiếm quyền điều khiển toàn bộ máy chủ (full server compromise), ảnh hưởng nghiêm trọng đến tính bảo mật của ứng dụng và tính toàn vẹn của dữ liệu.
Khai thác OS command injection, trường hợp cơ bản#
1. Mục tiêu Lab#
Mục tiêu của bài lab này là xác định và khai thác một lỗ hổng OS command injection cơ bản trong chức năng kiểm tra số lượng hàng tồn kho (stock checking) của ứng dụng. Đích đến là thực thi lệnh whoami trên máy chủ và quan sát kết quả trả về trong HTTP response.
2. Truy cập ứng dụng Lab#
Đầu tiên, tôi mở lab PortSwigger Web Security Academy có tên “OS command injection, simple case”. Trạng thái ban đầu của lab hiển thị là Not solved (Chưa giải quyết).
Sau đó, tôi duyệt qua trang web bán hàng và chọn một trang sản phẩm. Trang này chứa chức năng kiểm tra tồn kho, đây chính là mục tiêu chính để kiểm thử (test) command injection.
3. Bắt Request kiểm tra tồn kho#
Sử dụng proxy Burp Suite, tôi bắt (capture) lưu lượng HTTP được tạo ra bởi ứng dụng. Khi gọi tính năng kiểm tra tồn kho, ứng dụng sẽ gửi một request POST đến endpoint sau:
| |
Body của request chứa hai tham số (parameters):
| |
Điều này cho thấy ứng dụng sử dụng productId và storeId để kiểm tra số lượng sản phẩm. Tôi chuyển request này sang Burp Repeater để tiến hành kiểm thử thủ công (manual testing).
4. Kiểm thử OS Command Injection#
Trong Burp Repeater, tôi sửa đổi tham số storeId bằng cách nối thêm một dấu phân cách lệnh (command separator) và lệnh whoami:
| |
Dấu chấm phẩy ; được sử dụng làm ký tự phân cách lệnh trong các hệ điều hành họ Unix. Nếu ứng dụng đẩy trực tiếp giá trị của storeId vào một lệnh hệ điều hành mà không có cơ chế xác thực (validation) hợp lệ, máy chủ sẽ thực thi cả lệnh gốc ban đầu lẫn lệnh whoami vừa được inject.
5. Quan sát phản hồi từ Server#
Sau khi gửi request đã chỉnh sửa, máy chủ trả về response HTTP 200 OK. Trong phần body của response, ngoài số lượng tồn kho bình thường, còn có thêm output của lệnh được inject:
| |
Giá trị 62 là kết quả tồn kho bình thường, trong khi peter-EEPf8I chính là output của lệnh whoami. Điều này xác nhận rằng lệnh hệ điều hành được inject đã thực thi thành công trên máy chủ.
6. Kết quả khai thác#
Vì máy chủ đã thực thi lệnh whoami bị inject và trả output về trong HTTP response, lỗ hổng OS command injection đã được khai thác thành công.
Sau khi việc thực thi lệnh được xác nhận, trạng thái lab chuyển sang Solved, chứng tỏ thử thách đã hoàn thành.
7. Tổng kết#
Bài lab này minh họa một lỗ hổng OS command injection cơ bản nằm trong chức năng kiểm tra hàng tồn kho. Nguyên nhân sinh ra lỗ hổng là do dữ liệu đầu vào từ người dùng (tham số storeId) được truyền thẳng vào một lệnh hệ điều hành mà không qua bất kỳ bước xác thực (validation) hay làm sạch (sanitization) nào. Bằng cách chèn payload ;whoami, tôi đã có thể thực thi một lệnh trái phép trên server và xem được kết quả trực tiếp ngay trong HTTP response.