-
27/04/2017
-
30
-
76 bài viết
Phân tích và hướng dẫn triển khai CVE-2021-43617 (Phần 1)
Tiếp nối bài phân tích về lỗ hổng trong Apache HTTP Server, hôm nay mình sẽ giới thiệu với các bạn một lỗ hổng khác có mã định danh là CVE-2021-43417. Đây là lỗ hổng được đánh giá có mức ảnh hưởng nghiêm trọng với điểm CVSS lên đến 9.8 trên thang 10. Bài viết của mình sẽ gồm 2 phần:
Phần 1: Phân tích lỗ hổng
Phần 2: Hướng dẫn setup lab (step-by-step)
Bây giờ chúng ta hãy cùng bắt tay vào phân tích lỗ hổng này nhé. Cấu trúc phần 1 sẽ bao gồm các mục sau:
Cụ thể hơn thì Laravel Framework từ 8.70.2 trở xuống không chặn đủ việc tải lên nội dung PHP thực thi vì Illuminate / Validation / Concerns / ValidatesAttributes.php không kiểm tra các tệp ".phar", được xử lý dưới dạng ứng dụng / x-httpd-php trên hệ thống dựa trên Debian.
Nhìn vào hàm này có thể nhận ra rằng laravel đã bỏ qua các tập tin có đuôi .phar.
Và trong đoạn code lúc trả về
Ta thấy file tải lên sẽ được luân chuyển qua UploadFile. Tại Uploadfile sẽ đi qua function fake()
Bản thân function này sẽ trả về cho ta 1 File Factory. Nó làm nhiệm vụ đọc dữ liệu upload lên và tạo 1 tệp fake tương tự để hiển thị kết quả cho người dùng.
Ngoài ra, việc Debian lại mặc định hỗ trợ thực thi các tập tin .phar. bạn có thể kiểm tra Tập tin cấu hình php trên apache /etc/apache2/mods-available/php@[email protected]
Từ 2 nguyên nhân trên kẻ tấn công có thể tạo payload và lưu chúng dưới dạng phar extentsion để tấn công người dùng sử dụng debian.
Với 2 nguyên nhân rõ ràng như trên, hẳn các bạn cũng đã biết ảnh hưởng lỗ hổng cũng như hướng bảo vệ nó sẽ như thế nào rồi nhỉ? Nếu chưa thì hãy tiếp tục đọc bài viết nhé.
Ngoài việc vá lỗi từ laravel thì Debian cũng thực hiện cập nhật lại tập tin cấu hình của họ tại tất cả các phiên bản của mình.
Tuy nhiên, theo ý của tác giả, lỗ hổng nằm tại cơ chế kiểm tra tập tin của framework lavarel khi nó quá dễ để bypass. Cơ chế này hoạt động theo nguyên tắc sẽ quét 4 byte magic đầu tiên của tập tin để kiểm tra định dạng của tập tin. Kẻ tấn công có thể bypass bằng cách thêm 4 byte magic này vào payload của mình để thực thi payload. Mặc dù không thể tải lên các tập tin .phar nhưng vẫn còn các attack vector khác như xss.
Okay như vậy là chúng ta đã đi qua xong tất cả những gì cần phân tích rồi. Nếu như bạn hoặc công ty bạn đang dùng laravel thì hãy kiểm tra xem có ảnh hưởng không nhé!
Hẹn gặp các bạn ở phần 2
Phần 1: Phân tích lỗ hổng
Phần 2: Hướng dẫn setup lab (step-by-step)
Bây giờ chúng ta hãy cùng bắt tay vào phân tích lỗ hổng này nhé. Cấu trúc phần 1 sẽ bao gồm các mục sau:
- Tổng quan
- Phân tích chi tiết
- Nguyên nhân dẫn đến lỗ hổng
- Bản vá
- Ảnh hưởng của lỗ hổng
Tổng quan về lỗ hổng
CVE-2021-43617 là lỗ hổng liên quan đến việc bypass upload file của framework laravel (< 8.72.0). Đặc biệt, lỗ hổng này chỉ ảnh hưởng đến các ứng dụng lavarel chạy trên hệ điều hành Debian. Các ứng dụng trên hệ điều hành khác không bị ảnh hưởng. Team Lavarel đã đưa ra bản vá vào phiên bản (8.73.2), tuy nhiên theo tác giả của CVE này, lỗ hổng nằm ở việc bypass cơ chế kiểm tra tập tin được tải lên bởi người dùng.Cụ thể hơn thì Laravel Framework từ 8.70.2 trở xuống không chặn đủ việc tải lên nội dung PHP thực thi vì Illuminate / Validation / Concerns / ValidatesAttributes.php không kiểm tra các tệp ".phar", được xử lý dưới dạng ứng dụng / x-httpd-php trên hệ thống dựa trên Debian.
Nguyên nhân dẫn đến lỗ hổng
Mặc định, lavarel sẽ cấm người dùng tải lên các tập tin php. Hàm kiểm tra nằm tại Illuminate/Validation/Concerns/ValidatesAttributes.php
PHP:
protected function shouldBlockPhpUpload($value, $parameters){
if (in_array('php', $parameters)){
return false;
}
$phpExtensions = ['php', 'php3', 'php4', 'php5', 'phtml', ];
return ($value instanceof UploadedFile)
? in_array(trim(strtolower($value->getClientOriginalExtension())), $phpExtensions)
: in_array(trim(strtolower($value->getExtension())), $phpExtensions);
}
Nhìn vào hàm này có thể nhận ra rằng laravel đã bỏ qua các tập tin có đuôi .phar.
Và trong đoạn code lúc trả về
PHP:
return ($value instanceof UploadedFile)
? in_array(trim(strtolower($value->getClientOriginalExtension())), $phpExtensions)
: in_array(trim(strtolower($value->getExtension())), $phpExtensions);
Ta thấy file tải lên sẽ được luân chuyển qua UploadFile. Tại Uploadfile sẽ đi qua function fake()
Ngoài ra, việc Debian lại mặc định hỗ trợ thực thi các tập tin .phar. bạn có thể kiểm tra Tập tin cấu hình php trên apache /etc/apache2/mods-available/php@[email protected]
Apache config:
# application/x-httpd-php phtml pht php
# application/x-httpd-php3 php3
# application/x-httpd-php4 php4
# application/x-httpd-php5 php
<FilesMatch ".+\.ph(p[3457]?|t|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
# application/x-httpd-php-source phps
Require all denied
</FilesMatch>
# Deny access to files without filename (e.g. '.php')
<FilesMatch "^\.ph(p[3457]?|t|tml|ps)$">
Require all denied
</FilesMatch>
Từ 2 nguyên nhân trên kẻ tấn công có thể tạo payload và lưu chúng dưới dạng phar extentsion để tấn công người dùng sử dụng debian.
Với 2 nguyên nhân rõ ràng như trên, hẳn các bạn cũng đã biết ảnh hưởng lỗ hổng cũng như hướng bảo vệ nó sẽ như thế nào rồi nhỉ? Nếu chưa thì hãy tiếp tục đọc bài viết nhé.
Ảnh hưởng của lỗ hổng
Tất nhiên, khi bạn upload được file phar và còn executed được code thì ảnh hưởng xấu nhất của lỗ hổng sẽ là thực thi mã từ xa và chiếm quyền máy chủ.Bản vá cho lỗ hổng
Đầu tiên là lavavel đã vá ngay tại phiên bản 8.73.0. Để ngăn chặn việc tải lên file phar. Laravel đã thêm vào phần kiểm tra của mình định dạng phar nữa như hình dưới.Ngoài việc vá lỗi từ laravel thì Debian cũng thực hiện cập nhật lại tập tin cấu hình của họ tại tất cả các phiên bản của mình.
Tuy nhiên, theo ý của tác giả, lỗ hổng nằm tại cơ chế kiểm tra tập tin của framework lavarel khi nó quá dễ để bypass. Cơ chế này hoạt động theo nguyên tắc sẽ quét 4 byte magic đầu tiên của tập tin để kiểm tra định dạng của tập tin. Kẻ tấn công có thể bypass bằng cách thêm 4 byte magic này vào payload của mình để thực thi payload. Mặc dù không thể tải lên các tập tin .phar nhưng vẫn còn các attack vector khác như xss.
Okay như vậy là chúng ta đã đi qua xong tất cả những gì cần phân tích rồi. Nếu như bạn hoặc công ty bạn đang dùng laravel thì hãy kiểm tra xem có ảnh hưởng không nhé!
Hẹn gặp các bạn ở phần 2
Chỉnh sửa lần cuối: