Penetration Testing Step 3 – Làm gì khi các đòn cơ bản với Server-Side Template Injection không có tác dụng?

Tiếp theo nội dung Penetration Testing Step 3 – Các đòn cơ bản với Server-Side Template Injection, kỳ này tôi sẽ giới thiệu tiếp 2 kịch bản tấn công với Server-Side Template Injection – SSTI để xử lý tình huống khi các đòn cơ bản không có tác dụng. Nội dung cụ thể bao gồm:

• SSTI – Khai thác dựa vào documented exploit (tạm hiểu là các phương án khai thác đã được thử nghiệm thành công);
• SSTI – Thu thập thông tin thông qua các object được đẩy vào template.

Lưu ý:

• Như mọi khi, tôi cũng sẽ tận dụng các bài Lab dựng sẵn của ông PortSwigger để tiết kiệm thời gian dàn cảnh;
• Thông tin liên quan đến Burp Suite bạn có thể xem trong nội dung Penetration Testing Step 3 – 6 điều bạn nên biết trước khi xài tool khủng Burp Suite;
• Chi tiết việc sử dụng Burp Suite Repeater bạn có thể xem trong nội dung Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeater;

#1. Server-side template injection với documented exploit

Trong kỳ trước, khi triển SSTI – Khai thác documentation tôi đã dựa vào các vấn đề bảo mật đã được documentation của template liên quan dâng lên tận họng. Thực tế, nếu dò nát cái template documentation mà vẫn không ngộ ra được thứ gì hay ho, tôi sẽ cần mở rộng phạm vi tìm kiếm các nguồn khác để xem giang hồ đã có sáng tác được chiêu thức nào khai thác cái template engine mà tôi đang xem xét hay chưa. Nếu may mắn, tôi sẽ có thể tìm được documented exploit – tức là phương án khai thác đã được giang hồ thử nghiệm thành công. Tôi vào phần demo minh họa ngay đây.

Đầu tiên, tôi cũng sẽ cập truy cập vào xem chi tiết một sản phẩm trên ứng dụng (sản phẩm đầu tiên trong trường hợp này).

Lúc này tôi thấy cái message “Unfortunately this product is out of stock” dội về.

Tương tự như kỳ trước, cái Get request cũng sử dụng message parameter để render cái dòng thông báo trên ở trang chủ.

Để xác nhận, tôi có thể đẩy cái request này sang Burp Suite Repeater và quất cái message=test để check hàng thử như sau.

Rồi, giờ tôi chuyển qua múc với fuzz string tương ứng cho template syntax của các thể loại ngôn ngữ khác nhau (${{<%[%'”}}%\ như trường hợp bên dưới).

Dù không thể “chọt” đúng template syntax nhưng cái Internal Server Error cũng đã phọt ra cho tôi cái thông tin cần thiết là mục tiêu đang sử dụng Handlebars.

Tôi search thử với từ khóa “Handlebars server-side template injection” và hốt được cái thông tin tương ứng từ SSTI (Server Side Template Injection) – HackTricks. Tua nhanh đến chỗ liên quan đến Handlebars, tôi thó được nội dung cần thiết:

Sau khi hốt hàng về, tôi thay cái command ‘whoami’ sang ‘rm /home/carlos/morale.txt’ với ý đồ tiêu diệt file morale.txt của nạn nhân Carlos.

{{#with "s" as |string|}}

    {{#with "e"}}

        {{#with split as |conslist|}}

            {{this.pop}}

            {{this.push (lookup string.sub "constructor")}}

            {{this.pop}}

            {{#with string.split as |codelist|}}

                {{this.pop}}

                {{this.push "return require('child_process').exec('rm /home/carlos/morale.txt');"}}

                {{this.pop}}

                {{#each conslist}}

                    {{#with (string.sub.apply 0 codelist)}}

                        {{this}}

                    {{/with}}

                {{/each}}

            {{/with}}

        {{/with}}

    {{/with}}

{{/with}}

Sau đó tôi chạy URL encode cái đống ở trên.

Rồi đút kết quả encode vô chỗ message parameter trên Burp Suite Repeater.

Và hết sức nhẹ nhàng, cái file morale.txt của nạn nhân Carlos đã bị tôi triệt hạ thông qua cái command rm.

#2. Server-side template injection để thu thập thông tin thông qua các object được đẩy vào template

Trong kịch bản này, giả sử tôi đã đào bới và thử nghiệm chán chê với template documentation và documented exploit nhưng vẫn không có phương án tấn công trực diện với SSTI để hiện thực hóa ý đồ Remote Code Execution cũng như chiếm quyền điều khiển server. Lúc này, tôi có thể xem xét chuyển hướng khai thác thông tin với SSTI thông qua các object được đẩy vào template như kịch bản sau.

Đầu tiên, tôi truy cập vào mục tiêu với credential đã được cung cấp.

Sau đó tôi chọn xem chi tiết một sản phẩm và tiến hành Edit template.

Để test hàng, tôi thử tuồn vào cái fuzz string ví dụ như ${{<%[%'”}}%\ rồi chọn Save.

Lúc này mục tiêu phụt ra cái thông báo lỗi cho tối biết Django framework đang được sử dụng.

Như đề cập kỳ trước, tôi thử soi kèo Django documentation và ghi nhận thông tin thú vị từ cái debug (“… Outputs a whole load of debugging information, including the current context and imported modules. …”) với syntax kiểu {% debug %}.

Thử đút cái {% debug %} vào template và Save, tôi thấy ứng dụng phun ra danh sách các object và property mà tôi có thể truy cập, đặc biệt là cái settings object.

Tôi lại mò mẫm trong Settings | Django documentation | Django (djangoproject.com) và phát hiện một đối tượng tiềm năng là SECRET_KEY.

Dòng thông tin chỗ Warning hứa hẹn cho tôi một vụ mùa bội thu một khi túm được SECRET_KEY.

“…Keep this value secret.

Running Django with a known SECRET_KEY defeats many of Django’s security protections, and can lead to privilege escalation and remote code execution vulnerabilities …”

Tôi thử múc cái {{settings.SECRET_KEY}} vào template.

Và hô hô, cái SECRET_KEY giờ đây đã không còn là bí mật nữa. Dựa vào đây, tôi sẽ tha hồ tung hoành khi có thể đâm thủng các lớp bảo vệ, leo thang đặc quyền và triển Remote Code Execution trên hệ thống.

Đến đây tôi xin kết thúc nội dung demo của kỳ này. Kỳ tới tôi sẽ triển nốt nội dung còn lại trước khi bế mạc chương trình với SSTI.