Penetration Testing Step 3 – File upload vulnerabilities là gì?

Kết thúc nội dung Penetration Testing Step 3 – Chọc ngoáy lỗ hổng access control trong multi-step processes, tôi tạm gác lại câu chuyện liên quan đến Authorization/Access Control. Kỳ này tôi sẽ chuyển hướng sang một chủ đề khác cũng không kém phần ác liệt là file upload vulnerabilities (tạm dịch là các lỗ hổng liên quan đến hoạt động upload file).

Thực tế, khi dùng từ “không kém phần ác liệt”, tôi đã dùng phương án nói giảm. Với file upload vulnerabilities, hậu quả trong một số tình huống khai thác dạng lỗ hổng này có khi sẽ làm cho nạn nhân “trắng tay”.

#1. File upload vulnerabilities có thể nguy hiểm đến đâu?

Nói một cách ngắn gọn, file upload vulnerabilities có thể xuất hiện khi web server cho phép người dùng upload file lên filesystem của server mà không triển khai các bước kiểm duyệt phù hợp (ví dụ kiểm soát tên, loại, nội dung, kích thước, … của file upload).

Hoạt động tấn công khai thác với file upload vulnerabilities có thể tóm lược như sau:

• Attacker tuồn hàng độc hại lên server;
• Attacker kích hoạt cho các con hàng đã đẩy lên server hoạt động để khai thác (phần này tôi sẽ diễn giải rõ hơn trong Mục 2).

Nguồn: portswigger.net

Nhìn chung, hậu quả của file upload vulnerabilities sẽ tùy thuộc vào việc hệ thống thất bại trong việc kiểm soát yếu tố nào (name/content/size/type …) và hệ thống có những giải pháp gì để kiểm soát thiệt hại một khi kẻ gian đã tuồn được hàng vào. Một số dạng hậu quả phổ biến có thể gặp bao gồm:

• Với trường hợp filename (tên file), attacker có thể ghi đè vào các file hệ thống quan trọng;
• Với trường hợp filesize (kích thước file), attacker có thể chiếm dụng hết disk space (không gian đĩa) của hệ thống từ đó kích hoạt dạng tấn công Denial-of-service – DOS;
• Và trong kịch bản thúi heo nhất, hệ thống không thể kiểm duyệt được file type (loại file) dẫn đến cho phép attacker tuồn các thể loại độc hại (ví dụ như .php, .jsp) vào và thực thi như code. Với các server-side code file có thể hoạt động như web shell này, attacker có thể toàn quyền kiểm soát server.

Lưu ý:

• Web shell có thể hiểu là script độc hại cho phép attacker thực thi (từ xa) các command tùy ý trên web server thông quay việc gửi HTTP request đến endpoint phù hợp;
• Thông tin giới thiệu thêm về shell tôi có trình bày trong nội dung Giải ngố Kali Linux – Phần 4: Ép xung tốc độ thao tác Command Line với Bash và nhập môn Bash Script.

Thực tế, khả năng múc được một hệ thống bị thả trôi thả nổi không có các giải pháp để kiểm duyệt nhằm ngăn chặn file upload vulnerabilities là rất thấp. Tình huống dễ bắt gặp hơn là khi hệ thống có triển khai giải pháp bảo vệ nhưng vì lí do gì đó vẫn tồn tại vấn đề cho phép attacker bypasss các phương án bảo vệ, ví dụ như:

• Hệ thống sử dụng blacklist để ngăn cấm việc tuồn một số loại file type nhất định vào hệ thống nhưng không đủ hoặc thiếu chặt chẽ để kiểm soát các con hàng độc lạ hoặc đội lốt file extension lành tính;
• Hệ thống có tiến hành kiểm tra file type nhưng dựa vào các thuộc tính có thể bị attacker thao úng với công cụ phù hợp (ví dụ Burp Suite Repeater);
• Hệ thống triển khai giải pháp kiểm soát chuẩn cmn mực trên một thành phần của hệ thống nhưng “quên” hoặc triển khai giải pháp yếu hơn ở một thành phần khác. Và giữa 2 con đường để lựa chọn, attacker hiển nhiên chẳng dại mà đi đâm đầu vào chỗ khó.

#2. Quá trình xử lý request for static files – cơ sở để ăn “file upload vulnerabilities”

Dù phần lớn website hiện này có mức độ dynamic rất cao (tạm hiểu là website hốt tài nguyên từ đâu đó về để phục vụ cho request của người dùng, chứ không phân tích request path rồi lấy thông tin tương ứng từ một file/directory trong filesystem), vẫn đâu đó tồn tại các request for static files (ví dụ stylesheet, image,…) trong quá trình hoạt động. Việc hiểu rõ cơ chế xử lý request for static files là nền tảng cơ bản để bạn có thể ra đòn tấn công chuẩn xác vào điểm yếu của mục tiêu, tránh tình trạng đánh mất cơ hội, nhả đạn nhầm vị trí đầy nuối tiếc.

Với đám request for static files này, hệ thống sẽ phân tích request path để xác định file extention trước khi đối chiếu với thông tin thiết lập trên hệ thống (ví dụ MIME/Media type) để sau đó triển khai một số kịch bản như sau:

• Non-executable file type (ví dụ image hoặc HTML page): Server sẽ đẩy nội dung vô response và gửi cho client;
• Executable file type (ví dụ php): Nếu server được cấu hình cho phép chạy file loại này, dựa vào header và parameter của HTTP request, con hàng này sẽ gán các variable (biến số) tương ứng rồi chạy script. Kết quả xử lý (có thể bao gồm thêm các bước xử lý khác phía server) sau đó được đẩy vào response để trả cho client;
• Executable file type: Nếu server được cấu hình không cho phép chạy, con hàng này sẽ làm phát sinh lỗi, hoặc trả về response cho client dạng plain text. Tình huống này vẫn có thể nguy hiểm nếu hệ thống tồn tại các thiết lập không phù hợp làm rò rỉ thông tin.

Lưu ý:

• Content-Type trong response header sẽ có thể cho biết loại file mà server đã xác định. Thông tin này có thể dựa trên thiết lập của application code hoặc kết quả đối chiếu với MIME type. Dựa vào đây, bạn sẽ có thể có các điều chỉnh phù hợp để tăng tỉ lệ thành công trong quá trình tấn công;
• Bạn có thể bơi vào Common MIME types – HTTP | MDN (mozilla.org) hoặc Media Types (iana.org) để xem thêm thông tin về đám MIME/Media type;

#3. Ngăn ngừa file upload vulnerabilities dễ hay khó?

Về cơ bản, để ngăn chặn file upload vulnerabilities thì bạn chỉ cần đừng mắc sai lầm trong quá trình triển khai các biện pháp kiểm soát (nhưng mà nói thì lúc nào cũng dễ hơn làm!!!) và đặc biệt lưu ý các vấn đề:

• Kiểm tra file extension dựa trên whitelist (lưu ý, whitelist chứ không phải blacklist) để không phải dính đạn vì lỡ quên một (hoặc một số) thể loại file extension độc hại khác;
• Soi kỹ filename coi có đám string mờ ám (ví dụ kiểu “…/”) nhằm ngăn ngừa trò traversal (tôi sẽ sắp xếp giới thiệu chiêu này trong một nội dung khác);
• Rename các file được upload để ngăn ngừa khả năng ghi đè vào các file hiện hữu trên hệ thống;
• Chỉ cho phép upload file vào permanent filesystem của server sau khi quá trình kiểm tra sát khuẩn đã hoàn thành tốt đẹp;
• Sử dụng các framework xử lý file upload chuẩn đã được kiểm tra thử nghiệm thay vì chơi hàng “nhà tự trồng” (trừ trường hợp bạn bắt buộc phải làm thế).

Đến đây tôi xin kết thúc màn giới thiệu dạo đầu với file upload vulnerabilities. Trong các kỳ tiếp theo, tôi sẽ lần lượt demo minh hoạ một số đường cơ bản để khai thác các vấn đề phổ biến của dạng lỗ hổng này, bao gồm:

• Triển khai Remote code execution thông qua Web shell upload;
• Triển khai Remote code execution thông qua polyglot Web shell upload;
• Triển khai Web shell upload bằng cách bypass phương án kiểm soát Content-Type;
• Triển khai Web shell upload với directory traversal;
• Triển khai Web shell upload bằng cách bypass extention blacklist;
• Triển khai Web shell upload với chiêu obfuscated file extension;
• Triển khai Web shell upload với race condition.