WhiteHat News #ID:2018
WhiteHat Support
-
20/03/2017
-
129
-
443 bài viết
Magento vá các lỗ hổng khiến website bị kiểm soát
Nền tảng thương mại điện tử Magento vừa xử lý các lỗ hổng có thể bị khai thác bởi những kẻ tấn công chưa được xác thực nhắm vào các phiên quản trị và sau đó kiểm soát hoàn toàn những trang web bị dính lỗ hổng.
Để khai thác thành công, tin tặc trước hết cần khai thác lỗi Stored Cross-Site Scripting (XSS) để chèn một payload (đoạn dữ liệu) JavaScript vào trong backend (trang quản lý) của quản trị viên trên gian hàng Magento. Sau khi tấn công phiên giao dịch của một nhân viên, kẻ tấn công có thể khai thác lỗi RCE (thực thi mã từ xa) đã được xác thực để gây thiệt hại cho gian hàng.
Hãng an ninh RIPS Technologies tiết lộ: “Kẻ tấn công sau đó có thể gây ra thiệt hại về tài chính cho công ty sử dụng mã nguồn mở này. Ví dụ: Kẻ tấn công có thể điều hướng tất cả các khoản thanh toán đến tài khoản ngân hàng của mình và đánh cắp thông tin thẻ tín dụng”.
Hãng này cũng cho biết thêm: Lỗ hổng có thể bị khai thác nếu trang thương mại sử dụng phương thức thanh toán Authorize.Net được tích hợp sẵn, khi đó lỗi sẽ nằm ở giải pháp xử lý quá trình thanh toán qua thẻ tín dụng. Đây là phương thức phổ biến được sử dụng trong nhiều gian hàng của Magento và việc tự động hóa có thể dẫn đến việc khai thác đại trà.
Vì phương thức này được sử dụng để lọc các lưu ý hủy đơn hàng nên kẻ tấn công có thể khai thác lỗ hổng để chèn Javascript tùy ý được kích hoạt khi một nhân viên xem lại đơn hàng đã hủy.
Payload có thể được sử dụng để tấn công phiên xác thực của nhân viên, sau đó cho phép kẻ tấn công khai thác lỗ hổng Phar deserialization (lỗi chuyển đổi cấu trúc dữ liệu) trong trình kiểm soát cho phép hiển thị hình ảnh trong trình biên soạn WYSIWYG.
Lỗ hổng Stored XSS được tìm thấy trong phiên bản Magento 2.2.6 và đã được báo cáo vào tháng 8.2018 và bản vá được phát hành vào tháng 11. Nhưng sau đó một lỗ hổng lại được tìm thấy ảnh hưởng đến phiên bản 2.3.0. Lỗ hổng Phar deserialization được báo cáo vào tháng 1 và được vá vào tháng 3 trong phiên bản Magento 2.3.1, 2.2.8 và 2.1.17. Sau đó, lỗi này được được vá lần nữa trong phiên bản Magento 2.3.2, 2.2.9 và 2.1.18.
Để khai thác thành công, tin tặc trước hết cần khai thác lỗi Stored Cross-Site Scripting (XSS) để chèn một payload (đoạn dữ liệu) JavaScript vào trong backend (trang quản lý) của quản trị viên trên gian hàng Magento. Sau khi tấn công phiên giao dịch của một nhân viên, kẻ tấn công có thể khai thác lỗi RCE (thực thi mã từ xa) đã được xác thực để gây thiệt hại cho gian hàng.
Hãng an ninh RIPS Technologies tiết lộ: “Kẻ tấn công sau đó có thể gây ra thiệt hại về tài chính cho công ty sử dụng mã nguồn mở này. Ví dụ: Kẻ tấn công có thể điều hướng tất cả các khoản thanh toán đến tài khoản ngân hàng của mình và đánh cắp thông tin thẻ tín dụng”.
Hãng này cũng cho biết thêm: Lỗ hổng có thể bị khai thác nếu trang thương mại sử dụng phương thức thanh toán Authorize.Net được tích hợp sẵn, khi đó lỗi sẽ nằm ở giải pháp xử lý quá trình thanh toán qua thẻ tín dụng. Đây là phương thức phổ biến được sử dụng trong nhiều gian hàng của Magento và việc tự động hóa có thể dẫn đến việc khai thác đại trà.
Lỗi đầu tiên là Stored XSS chưa được xác thực trong các lưu ý hủy đơn hàng sản phẩm mới do qua mặt phương thức lọc chặn escapeHtmlWithLinks().Vì phương thức này được sử dụng để lọc các lưu ý hủy đơn hàng nên kẻ tấn công có thể khai thác lỗ hổng để chèn Javascript tùy ý được kích hoạt khi một nhân viên xem lại đơn hàng đã hủy.
Payload có thể được sử dụng để tấn công phiên xác thực của nhân viên, sau đó cho phép kẻ tấn công khai thác lỗ hổng Phar deserialization (lỗi chuyển đổi cấu trúc dữ liệu) trong trình kiểm soát cho phép hiển thị hình ảnh trong trình biên soạn WYSIWYG.
Lỗ hổng Stored XSS được tìm thấy trong phiên bản Magento 2.2.6 và đã được báo cáo vào tháng 8.2018 và bản vá được phát hành vào tháng 11. Nhưng sau đó một lỗ hổng lại được tìm thấy ảnh hưởng đến phiên bản 2.3.0. Lỗ hổng Phar deserialization được báo cáo vào tháng 1 và được vá vào tháng 3 trong phiên bản Magento 2.3.1, 2.2.8 và 2.1.17. Sau đó, lỗi này được được vá lần nữa trong phiên bản Magento 2.3.2, 2.2.9 và 2.1.18.
Theo SecurityWeek