利用PHP 7中的OPcache來實現Webshell
在這篇文章中,我們將會對PHP7 OPcache引擎中的安全問題進行講解,而且還會給大家介紹一種新型的漏洞利用技術。通過這種攻擊方法,我們可以繞過某些安全強化技術,例如 禁止web目錄的文件讀寫 等安全保障措施。除此之外,攻擊者還可以利用這種攻擊技術在目標主機中執行惡意代碼。
OPcahceOPcache是PHP 7.0中內嵌的新型緩存引擎。它可以對PHP腳本代碼進行編譯,并且將編譯結果以字節碼的形勢存入內存中。
OPcache 通過將 PHP 腳本預編譯的字節碼存儲到共享內存中來提升 PHP 的性能, 存儲預編譯字節碼的好處就是省去了每次加載和解析 PHP 腳本的開銷。
除此之外,它還能提供文件系統的緩存功能,但是我們必須在PHP.ini配置文件中定義緩存信息的目標文件夾路徑:
opcache.file_cache=/tmp/opcache
在上面這個文件夾中,OPcache會將編譯好的PHP腳本保存在相應PHP腳本的相同目錄結構之中。比如說,需要進行編譯的代碼保存在/var/www/index.php之中,而完成編譯的代碼將會保存在/tmp/opcache/[system_id]/var/www/index.php.bin之中。
在上述文件路徑中,system_id是一個包含了當前PHP版本信息,Zend框架的擴展ID,以及各種數據類型信息的MD5 哈希值。在最新發行版的Ubuntu操作系統(16.04)之中,system_id是由當前Zend框架和PHP的版本號所組成的(81d80d78c6ef96b89afaadc7ffc5d7ea)。當OPcache首次對這些文件進行緩存處理時,會在文件系統中創建相應的目錄。
正如我們將會在接下來的章節中看到的,每一個OPcache文件還會在文件的header域中保存system_id的副本。
至此,我們就不得不提到OPcache文件夾了,其中一個非常有趣的地方就是,當用戶啟用了這項服務之后,用戶就會擁有OPcache生成的所有文件夾或者文件(所有文件和文件夾均位于/tmp/opcache/目錄之下)的寫入權限。
OPcache文件夾中的權限信息如下所示:
$ ls /tmp/opcache/
drwx------ 4 www-data www-data 4096 Apr 26 09:16 81d80d78c6ef96b89afaadc7ffc5d7ea
正如我們看到的那樣,www-data分組下的用戶都擁有OPcache所生成文件夾的寫入權限。如果我們擁有OPcache目錄的寫入權限,那么我們就可以重寫目錄中的緩存文件,然后利用webshell來執行任意代碼。
攻擊場景首先,我們必須得到緩存文件夾的保存路徑(/tmp/opcache/[system_id]),以及目標PHP文件的保存路徑(/var/www/...)。
為了讓大家更容易理解,我們假設網站目錄中存在一個phpinfo()文件,我們可以從這個文件中獲取到緩存文件夾和文件源代碼的存儲位置,當我們在計算system_id的時候將會需要用到這些數據。我們已經開發出了一款能夠從網站phpinfo()中提取信息,并計算system_id的工具。你可以在我們的 GitHub代碼庫 中獲取到這個工具。
在此,我們需要注意的是,目標網站必須不能對上傳的文件有所限制。
現在,我們假設php.ini中除了默認的設置信息之外,還添加有下列配置數據:
opcache.validate_timestamp = 0 ; PHP 7’s default is 1
opcache.file_cache_only = 1 ; PHP 7’s default is 0
opcache.file_cache = /tmp/opcache
接下來,我們就會給大家講解攻擊的實施過程:
我們已經在網站中找到了一個漏洞,這個漏洞意味著網站不會對我們上傳的文件進行任何的限制。我們的目標就是利用包含后門的惡意代碼替換掉文件/tmp/opcache/[system_id]/var/www/index.php.bin。
上圖顯示的就是包含漏洞的網站界面。
1.在本地創建一個包含Webshell的惡意PHP文件,將其命名為“index.php”:
<?php
system($_GET[’cmd’]);
?>
2.將opcache.file_cache的相關設置添加進你的PHP.ini文件之中。
3.利用php –S 127.0.0.1:8080命令啟動一個Web服務器,然后向服務器請求index.php文件,并觸發緩存引擎。在這一步中,我們只需要使用命令wget 127.0.0.1:8080就可以實現我們的目的了。
4.定位到我們在第一步中設置的緩存文件夾,你將會發現了一個名為index.php.bin的文件。這個文件就是已經經過編譯處理的webshell。
上圖顯示的是OPcache生成的index.php.bin。
5.由于本地system_id很可能與目標主機的system_id不同,所以我們必須打開index.php.bin文件,并將我們的system_id修改成目標主機的system_id。正如我們之前所提到的,system_id是有可能被猜到的,例如暴力破解,或者根據phpinfo()文件中的服務器信息計算出來。我們可以在文件簽名數據之后修改system_id,具體如下圖所示:
上圖顯示的是system_id的數據存儲位置。
6.由于目標網站對上傳的文件沒有任何的限制,所以我們現在就將文件上傳至服務器的目錄之中:
/tmp/opcache/[system_id]/var/www/index.php.bin
7.刷新網站的index.php,網站將會自動執行我們的webshell。
繞過內存緩存(file_cache_only = 0)
如果內存緩存的優先級高于文件緩存,那么重寫OPcache文件并不會執行我們的webshell。如果服務器托管的網站中存在文件上傳限制漏洞,那么在服務器重啟之后,我們就可以繞過這種限制。既然內存緩存可以被清空,OPcache將會使用文件緩存來填充內存緩存,從而達到我們執行webshell的目的。
這也就意味著,我們還是有辦法能夠在服務器不進行重啟的情況下,執行我們的webshell。
在WordPress等網站框架之中,還是會有一些過時的文件可以公開訪問到,例如 registration-functions.php 。
由于這些文件已經過時了,所以系統不會再加載這些文件,這也就意味著,內存和文件系統的緩存中是不可能存在有這些文件的。當我們上傳了惡意代碼(registration-functions.php.bin)之后,然后訪問相關的網頁(/wp-includes/registration-functions.php),OPcache就會自動執行我們的webshell。
繞過時間戳認證(validate_timestamps = 1)
時間戳通常是一個字符序列,它可以唯一地標識某一時刻的時間。一般來說,時間戳產生的過程為:用戶首先將需要加時間戳的文件用Hash編碼加密形成摘要,然后將該摘要發送到DTS,DTS在加入了收到文件摘要的日期和時間信息后再對該文件加密(數字簽名),然后送回用戶。
如果服務器啟用了時間戳認證功能,OPcache將會對被請求的PHP源文件的時間戳進行驗證,如果該文件與緩存文件header域中的時間戳相匹配,那么服務器就會允許訪問。如果時間戳不匹配,那么緩存文件將會被丟棄,并創建出一個新的緩存文件。為了繞過這種限制,攻擊者必須知道目標源文件的時間戳。
這也就意味著,在WordPress等網站框架之中,源文件的時間戳是可以獲取到的,因為當開發人員將代碼文件從壓縮包中解壓出來之后,時間戳信息仍然是保持不變的。
上圖顯示的是WordPress/wp-includes文件夾中的信息。
有趣的是,其中的有些文件從2012年起就再也沒有進行過任何的修改(請注意以下兩個文件:registration-functions.php和registration.php)。因此,即使是不同版本的WordPress,這些相同文件的時間戳也是一樣的。在獲取到了文件時間戳的信息之后,攻擊者就可以修改他們的惡意代碼,并且成功覆蓋服務器的緩存數據。時間戳信息位于文件開頭處的第34字節位置:
在此,我們給大家提供了一個簡短的演示視頻,并在視頻中對攻擊步驟進行了講解:
視頻地址:https://youtu.be/x42l-PQHhbA
正如我們在此之前提到的,大家可以在我們的 GitHub代碼庫 中獲取到你們所需要的工具。
總結總而言之,這種新型的攻擊方法并不會對使用PHP進行開發的應用程序產生影響,因為這并不是PHP的通用漏洞。現在,很多Linux發行版的操作系統(例如Ubuntu 16.04)都會默認安裝PHP 7,所以當我們在了解到了這種攻擊技術之后,在我們的開發過程中,更加因該謹慎地審查我們的代碼,并檢查網站中是否存在文件上傳限制漏洞,因為這個漏洞將會對服務器的安全產生影響。
本文由 360安全播報 翻譯，轉載請注明“轉自360安全播報”，并附上鏈接。
原文鏈接：http://blog.gosecure.ca/2016/04/27/binary-webshell-through-opcache-in-php-7/
相關文章：
網公網安備