Lỗ hổng SQL injection từ xa trong itsourcecode School Management System

Một lỗ hổng đã được xác định trong itsourcecode School Management System 1.0. Lỗ hổng này ảnh hưởng đến một chức năng chưa xác định của tệp /ramonsys/user/index.php. Việc thao túng đối số ID có thể dẫn đến SQL injection. Cuộc tấn công có thể được thực hiện từ xa. Exploit đã được công khai và có thể bị sử dụng.

• itsourcecode School Management System của vendor itsourcecode, phiên bản 1.0, được đánh dấu là bị ảnh hưởng.
• Thành phần được nêu trong hồ sơ là /ramonsys/user/index.php, với tham số GET id là đầu vào bị tác động.
• Không có bản phát hành đã sửa được cung cấp. Tình trạng của các nhánh hoặc phiên bản khác không được xác minh, vì vậy không nên suy ra rằng các phiên bản mới hơn hoặc nhánh song song đã an toàn.

Thành phần bị ảnh hưởng là /ramonsys/user/index.php. Phân tích công khai xác định tham số GET id là dữ liệu do kẻ tấn công kiểm soát và cho biết dữ liệu này có thể đi vào quá trình tạo câu lệnh SQL mà không được kiểm tra hoặc làm sạch đầy đủ. Đây là lỗi SQL injection thuộc CWE-89, với nguyên nhân là dữ liệu đầu vào bên ngoài có thể làm thay đổi câu lệnh SQL dự kiến. PoC công khai mô tả dạng SQL injection mù dựa trên thời gian, nhưng chức năng cụ thể, câu truy vấn, quyền của tài khoản cơ sở dữ liệu và phạm vi dữ liệu có thể bị tác động vẫn chưa được xác định. Khả năng truy cập từ xa được xác nhận, nhưng hồ sơ không chứng minh việc chiếm quyền ở mức hệ điều hành hoặc quyền quản trị ứng dụng.

• Khả năng truy cập: Có thể tấn công từ xa qua ứng dụng web.
• Xác thực: Hồ sơ và báo cáo công khai cho biết không cần xác thực trước.
• Tương tác và độ phức tạp: Không cần tương tác của người dùng; đánh giá cấu trúc cho biết độ phức tạp tấn công thấp.
• Trạng thái khai thác: Một PoC công khai đã được đăng tải. Điều này xác nhận mã khai thác hoặc bằng chứng khái niệm đã có sẵn, nhưng không tự nó chứng minh đã xảy ra xâm nhập thực tế, chiến dịch cụ thể hoặc nạn nhân cụ thể.

Lỗi có thể cho phép kẻ tấn công đưa dữ liệu SQL được chế tạo vào tham số id, từ đó làm thay đổi cách ứng dụng xử lý truy vấn. Hậu quả kỹ thuật có thể gồm đọc trái phép dữ liệu, sửa hoặc xóa dữ liệu và ảnh hưởng đến tính sẵn sàng của dịch vụ, tùy thuộc vào quyền cơ sở dữ liệu. Hồ sơ không chứng minh rằng lỗi dẫn đến thực thi mã tùy ý, chiếm quyền máy chủ hoặc vượt ra ngoài phạm vi cơ sở dữ liệu. Về vận hành, tổ chức có thể phải điều tra dữ liệu, khôi phục tính toàn vẹn và xử lý thời gian gián đoạn nếu khai thác thành công.

Khai thác thành công có thể cho phép truy cập trái phép vào cơ sở dữ liệu, làm lộ hoặc thay đổi dữ liệu và gây gián đoạn dịch vụ. Mức độ ảnh hưởng thực tế phụ thuộc vào quyền mà tài khoản cơ sở dữ liệu của ứng dụng được cấp và cách hệ thống được triển khai. Hồ sơ không xác định bộ dữ liệu cụ thể bị ảnh hưởng, không chứng minh việc chiếm quyền hệ điều hành và không nêu nạn nhân hoặc sự cố xâm nhập cụ thể.

1. Ưu tiên xác định bản sửa: Hồ sơ không cung cấp fixed release hoặc bản vá của vendor. Không nên coi một phiên bản không được nêu rõ là đã an toàn.
2. Nếu tổ chức tự duy trì mã nguồn, thay việc ghép dữ liệu trực tiếp vào SQL bằng prepared statements và parameter binding cho id.
3. Kiểm tra và giới hạn đầu vào theo định dạng dự kiến, chẳng hạn chỉ chấp nhận giá trị định danh dạng số khi phù hợp với thiết kế ứng dụng.
4. Giảm quyền của tài khoản cơ sở dữ liệu mà ứng dụng sử dụng xuống mức tối thiểu cần thiết và tránh dùng tài khoản đặc quyền cao cho hoạt động thường ngày.
5. Nếu không thể sửa mã nguồn, cân nhắc thay thế thành phần hoặc sản phẩm bị ảnh hưởng theo khuyến nghị dự phòng trong báo cáo. Đây không phải là bản sửa lỗi được vendor xác nhận.
6. Thực hiện đánh giá bảo mật sau khi thay đổi để kiểm tra lại các đầu vào SQL và quyền của tài khoản ứng dụng.

1. Kiểm kê các máy chủ đang triển khai itsourcecode School Management System và xác minh phiên bản cài đặt, đặc biệt là các hệ thống còn chứa /ramonsys/user/index.php.
2. Rà soát access log cho các yêu cầu đến /ramonsys/user/index.php có tham số GET id, nhất là các yêu cầu đến từ nguồn chưa xác thực hoặc có giá trị tham số bất thường. Đây là bước phân loại phòng thủ, không phải IOC đã được xác nhận.
3. Đối chiếu các yêu cầu trên với thời gian phản hồi bất thường, lỗi SQL hoặc truy vấn có thời lượng kéo dài. Việc xem xét độ trễ là biện pháp thận trọng vì PoC được mô tả là time-based blind SQL injection, không phải bằng chứng chắc chắn về khai thác.
4. Kiểm tra database audit log và error log để tìm các lần đọc hoặc thay đổi dữ liệu bất thường do tài khoản của ứng dụng thực hiện trong cùng khoảng thời gian.
5. Không xem việc không có log phù hợp là bằng chứng hệ thống an toàn, vì hồ sơ không cung cấp IOC hoàn chỉnh hoặc yêu cầu log cụ thể.