2. CVE-2019-18650
Joomla sử dụng component com_template cho phép người dùng có thể thêm/xóa/sửa code của template trực tiếp từ giao diện web và thư mục template này được đặt ở WEBROOT.

Hình 4 ví dụ thư mục template protostar

Các chức năng template đều được hardening, để truy cập phải thông qua quá trình routing của Joomla bao gồm kiểm tra quyền, session của người dùng như vậy ta rất khó để tìm ra lỗi nào cho phép ta thực hiện các chức năng template mà không qua xác thực. Lúc này mình nghĩ đến lỗi CSRF.
Sau khi tìm hiểu, Joomla sử dụng JSession::checkToken hoặc JRequest::checkToken để phòng chống lỗi CSRF. Ví dụ:

Hình 5 Ví dụ kiểm tra CSRF ở chức năng UploadFile

Như vậy ý tưởng tìm lỗi CSRF của như sau:

  • Duyệt toàn bộ file controller vì joomla hoạt động theo mô hình MVC, từ controller  có thể call được action trong controller đó. Ví dụ
    http://your_joomla/index.php?option=[component_name]&task=[controller_name].[action]
  • Tại mỗi file controller, kiểm tra các chức năng có sử dụng code kiểm tra token hay không, nếu không tiếp tục kiểm tra xem có cho nhận input từ người dùng hay không.
    Script mình sử dụng: https://gist.github.com/komang4130/d0516194e22a77882f845fd4324f07a6
    Kết quả:

Có khá nhiều chức năng ở component com_template không kiểm tra CSRF, trong đó mình khoanh vùng 2 file này và tiến hành phân tích.
Phân tích chức năng overrides()

Hình 6 Phân tích chức năng overrides ở Template

Chức năng nhận vào 3 tham số:

  • $file: file cần ghi
  • $override: thư mục chứa file template để ghi vào thư mục template tương ứng với $id
  • $id: id của template ( giá trị mặc định tương ứng với từng template )
    Joomla sử dụng JInput để xử lý các kiểu dữ liệu khác nhau từ người dùng, để phòng chống các lỗi nguy hiểm như XSS, SQLi, Path traversal, …. ví dụ:
Hình 7 xử lý dữ liệu string và int từ dữ liệu người dùng gửi lên.

Và ở $override ta thấy đây là nhận dữ liệu folder của người dùng, Joomla sẽ xử lý dữ liệu về folder như sau:

Hình 8 xử lý dữ liệu path từ người dùng

Tuy nhiên, biến $override được nhận theo kiểu base64

Hình 9 Xử lý dữ liệu base64 từ người dùng

Nếu trong luồng nghiệp vụ của chức năng không kiểm tra lại $override sau khi giải mã base64 sẽ xảy ra lỗi Path traversal, cho phép kẻ tấn công có thể gọi đến các thư mục ngoài WEBROOT.
Theo luồng nghiệp vụ, phân tích hàm createOverride($override) với tham số truyền vào là $override.

Hình 10 Phân tích chức năng createOverride

Như đã phân tích ở trên, dữ liệu $override tiếp tục không được kiểm tra để chống lỗi Path traversal.
Tiếp tục phân tích hàm createTemplateOverride($override, $htmlPath). Trong đó $htmlPath là thư mục tương ứng với $id, có thể truy cập từ WEBROOT.

Hình 11 Phân tích chức năng createTemplateOverride

Chức năng sẽ lấy toàn bộ file có định dạng đuôi ‘php’ từ thư mục $override để ghi vào $htmlPath. Và vẫn không có kiểm tra phòng chống lỗi Path traversal.
Như vậy, chức năng này bị hai lỗi đó là CSRF và Path traversal. Tao chain khai thác lỗi:
- Upload file mã độc php lên nơi nào đó trong máy chủ. (ftp-anon, local attack, … ).
- Tìm WEBROOT. (path disclosure, directory listing, enable error page.. ).Lừa admin ấn vào liên kết mã độc. ( XSS, Phishing )
- Mã khai thác: http://victim/joomla_path/administrator/index.php?option=com_templates&view=template&task=template.overrides&folder=base64(folder_of_malicious_php_code)&id=506&file=base64(foo_any)
Nếu kẻ tấn công có quyền quản lí thư mục template, thì kẻ tấn công có thể liệt kê các các file php trên server thư mục template và từ đó lấy thông tin các ứng dụng php có trên máy chủ. Có thể Dos hoặc ghi tràn Disk.
Mã khai thác:
http://victim/joomla_path/administrator/index.php?option=com_templates&view=template&task=template.overrides&folder=base64([WEBROOT/../../../../])&id=506&file=base64(foo_any)
trong đó
WEBROOT: path_to_joomla\components..\..\..\[to_your_malicious_folder_to_RCE]
Và với trường hợp enum thì chỉ cần đặt nhiều “..\”
Tùy target là Windows hay Linux mà ta sử dụng “../” hoặc “..\”
Minh họa lỗi:

  • Ta đã upload được lên server file mã độc php. Ở mức demo dùng chức năng CSRF Generate PoC của Burp Suite để tạo trang phishing:
  • Khi Admin click submit, mã độc được đã được thực thi.
Hình 12 Trang phishing được tạo bởi chức năng Generate CSRF PoC của Burp Suite
Hình 13 Ghi file mã độc thành công ra webroot
Hình 14 Vị trí mã độc ở WEBROOT.
Hình 15 Truy cập mã độc trực tiếp từ Web.

Mã độc liệt kê toàn bộ file php trong thư mục:
Mã khai thác trong trường hợp máy local:
WEBROOT: D:\xampp\htdocs\joomla_3.9.12
Liệt kê toàn bộ thư mục ở thư htdocs: D:\xampp\htdocs\joomla_3.9.12\components..\..\..
http://victim/joomla_path/administrator/index.php?option=com_templates&view=template&task=template.overrides&folder=base64(“D:\xampp\htdocs\joomla_3.9.12\components..\..\..\
”)&id=506&file=XZXZ
Kết quả:

Hình 16 Liệt kê toàn bộ thư mục và file php trong thư mục htdocs vào thư mục template

(Còn tiếp)

Author: Le Quang Thao