Penetration Testing Step 3 – Khai thác file upload vulnerabilities (Hiệp 2)

Tiếp theo trong nội dung Penetration Testing Step 3 – Khai thác file upload vulnerabilities (Hiệp 1), kỳ này tôi sẽ sang hiệp 2 của phần demo cụ thể phương án tấn công để khai thác các lỗ hổng file upload vulnerabilities. Cụ thể, trong phần này, tôi sẽ giới thiệu tiếp 2 kịch bản:

• Hệ thống sử dụng giải pháp bảo vệ blacklist để đối phó file upload vulnerabilities nhưng tồn tại lỗ hổng cho phép tôi bypass lách luật;
• Hệ thống lợi hại hơn với giải pháp bảo vệ whitelist để đối phó file upload vulnerabilities nhưng lại sơ hở để tôi giở trò ngụy trang đâm thủng lớp bảo vệ;

Trong trường hợp bạn chưa hình dung được vấn đề thì tôi xin nhắc lại. Để ngăn cấm kẻ gian tuồn hàng cấm lên server, cán bộ quản lý có thể dùng phương án blacklist (tức là danh sách các file extension bị cấm upload lên server) để ngăn chặn các thể loại nguy hiểm như .php. Tuy nhiên, như có thể thấy trong kỳ trước, phương án này rất dễ làm chủ xị vỡ mồm vì sự phong phú và đa dạng của file extension dẫn đến thiếu sót một số đối tượng trong blacklist.

Và kể cả khi blacklist không bị thiếu sót hay thậm chí server triển khai whitelist (tức là sử dụng danh sách liệt kê các file extension được phép upload, thằng nào không thuộc danh sách này thì chim cút ra chỗ khác giùm), đâu đó vẫn tồn tại khả năng các đối tượng ngụy trang thành file extension trong whitelist để thoát khỏi sự kiểm soát của cán bộ bảo vệ.

Ngoài ra, cũng cần nhấn mạnh đến lớp bảo vệ thứ 2 thông qua việc cấu hình quản lý thực thi cho đám file upload. Thực tế, server có thể được cấu hình theo kiểu:

• Global settings: Thiết lập chung quyền thực thi file cho toàn server (Ví dụ với file /etc/apache2/apache2.conf với Apache server);
• Special settings: Thiết lập file cấu hình riêng biệt cho các thư mục cụ thể để override (ghi đè) hoặc bổ sung thêm một số nội dung vào cấu hình trong global setting (ví dụ file .htaccess với Apache server hay config với IIS server).

Thông thường, việc truy cập, chấm mút vào các file cấu hình này sẽ bị ngăn cấm. Nhưng nếu attacker có thể tuồn các file cấu hình độc hại lên server nhằm dụ dỗ để server mapping file extesion tùy ý sang MIME type được phép thực thi thì lớp bảo vệ này cũng sẽ hoàn toàn mất hiệu lực.

Nếu sau khi nghe tôi “nhắc lại” mà bạn vẫn thấy mơ hồ thì cũng không sao cả. Tôi sẽ làm rõ mọi chuyện ngay trong phần demo sau đây.

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 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. Khai thác file upload vulnerability với extension blacklist bypass

Trong kịch bản này, ứng dụng cho phép thực hiện việc upload image kèm với cơ chế bảo vệ blacklist để ngăn cấm một số dạng file extension nguy hiểm. Và việc đầu tiên tôi làm là đăng nhập vào hệ thống sau đó thử chức năng upload image cho avatar.

Sau khi upload và quay về account page, tôi kiểm tra Burp Suite Proxy History để kiếm cái request truy cập avatar image tương ứng rồi đẩy sang Repeater.

Cũng như kỳ trước, tôi cũng tạo ra một con hàng độc hại exploit.php nhằm soi mói cái bí mật của nạn nhân carlos với nội dung kiểu như sau.

<?php echo file_get_contents('/home/carlos/secret'); ?>

Nếu thử đẩy file này lên server tôi sẽ bị từ chối thẳng thừng do server đang được thiết lập blacklist đám php files.

Đẹp trai không bằng chai mặt, tôi quyết không từ bỏ. Quay lại Burp Suite Proxy History, tôi kiếm cái POST request tương ứng để upload file php lúc nãy.

Với thông tin Apache Server xác định trong response ở trên, tôi đẩy hàng qua Repeater để thực hiện các thủ thuật mông má lại cái request. Cụ thể, trong cái request, tôi dò đến đoạn tương ứng của file php ban nãy và thực hiện một số hiệu chỉnh:

• Đổi filename thành .htaccess (phụ trách Special settings như tôi đề cập ở phần đầu cho Apache Server);
• Đổi Content-Type header thành text/plain;
• Đổi nội dung file php thành Apache directive AddType application/x-httpd-php .l33t (ý tưởng ở đây là thiết lập để server map cái extension tùy ý .133t sang MIME type có thể thực thi application/x-httpd-php).

Quá trình gửi hàng .htaccess lên server diễn ra khá thuận lợi.

Kế đến, tôi lấy lại cái request upload file php ban đầu và đổi tên exploit.php thành exploit.133t rồi send lại. Vì server chơi kiểu blacklist nên cái extension .133t dễ dàng xé rào chui vào.

Hàng (exploit.133t) đã lên server, file thiết lập .htaccess cho phần mapping để thực thi cũng đã có, tôi lướt về cái get request đọc avatar image và hiệu chỉnh lại để truy cập.

Và không nằm ngoài dự đoán, secret của carlos giờ đây đã trở thành secret của “tôi và carlos”.

#2. Khai thác file upload vulnerability với bí thuật ngụy trang file extension

Như đề cập ở trên, phương án blacklist tiềm ẩn rất nhiều nguy cơ vì khả năng bỏ sót các đối tượng nguy hiểm là rất cao. Giải pháp để khắc phục vấn đề này là chuyển sang sử dụng whitelist. Tuy nhiên, cần lưu ý rằng, chiến thuật dùng whitelist sẽ phải đối mặt với một vấn đề nhức nhối khác là các thủ thuật ngụy trang, trá hình phổ biến như sau:

• Sử dụng multiple extension kiểu như “php.jpg” để đội lốt image file extension;
• Sử dụng trailing character như whitespace (“ ”), dot (“.”) kiểu như “php.” để che dấu thân phận (php) và chỉ hiện nguyên hình khi ứng dụng xử lý loại bỏ trailing character;
• Sử dụng URL encoding (hoặc double URL encoding) cho dot, forward slash (“/”), backward slashe (“\”. Ví dụ kiểu như “exploit%2Ephp” (%2E là dạng encode của dot), sau khi qua ải xác minh file extension, ứng dụng decode trở lại thành file php thì sẽ vỡ mồm;
• Sử dụng semicolon (“;”) hoặc URL encoded null byte character phía trước file extension để khai thác sự không nhất quán của quá trình xác minh file extension và bước xử lý sau đó của server (tức là chỗ xác minh và bước xử lý sau đó “đọc” ra 2 dạng file extension khác nhau từ cùng 1 input).

Lưu ý: Bạn có thể xem thêm nội dung URL Encode trong nội dung HTML URL Encoding Reference (w3schools.com).

Trong một diễn biến khác, server có thể sử dụng phương án cắt gọt hoặc thay thế các file extension nguy hiểm để ngăn ngừa khả năng thực thi. Và vấn đề có thể phát sinh nếu giải pháp này không được triển kiểu recursive (nghĩa là đệ quy, tạm hiểu là xử lý liên tục cho đến cùng chứ không chỉ quất 1 cái rồi nghỉ). Với tình huống này, attacker có thể chơi kiểu “exploit.p.phphp”. Và nếu quá trình cắt gọt .php chỉ diễn ra 1 lần thì hàng sau xử lý sẽ lại trở thành “exploit.php”.

Nãy giờ chém gió lê thê quá rồi, thôi tôi triển phần demo minh họa cho rõ ngay đây. Tương tự như kịch bản trước đó, tôi cũng đăng nhập vào hệ thống và thử upload file exploit.php có nội dung như sau làm avatar.

<?php echo file_get_contents('/home/carlos/secret'); ?>

Lần này, phương án whitelist được sử dụng (chỉ cho phép dùng JPG và PNG) nên hiển nhiên tôi bị từ chối thẳng thừng.

Tôi nhảy qua Burp Suite Proxy History lấy cái request tương ứng rồi đẩy qua Repeater.

Sau đó, tôi lần mò đến vị trí file exploit.php và đổi filename thành kiểu: filename="exploit.php%00.jpg" (sử dụng URL encode null byte %00 như tôi nói ở trên).

Lúc này, cái .jpg giúp tôi đâm thủng lớp bảo vệ whitelist để đẩy hàng lên server. Sau khi chui được qua bước xác minh với whitelist, ở quá trình xử lý tiếp theo, khi đụng cái URL encode null byte server liền ra tay cắt gọt cái null byte lẫn cái .jpg phía sau và “chừa lại” cho tôi cái file exploit.php như mong đợi.

Công việc tiếp theo chỉ mang tính thủ tục khi tôi có thể nhẹ nhàng hiệu chỉnh lại cái GET request truy cập avatar image để hướng đến exploit.php và húp cái secret của carlos.