利用PHP 7中的OPcache來實現Webshell

在這篇文章中,我們將會對PHP7 OPcache引擎中的安全問題進行講解,而且還會給大家介紹一種新型的漏洞利用技術。通過這種攻擊方法,我們可以繞過某些安全強化技術,例如 禁止web目錄的檔案讀寫 等安全保障措施。除此之外,攻擊者還可以利用這種攻擊技術在目標主機中執行惡意代碼。

OPcahce

OPcache是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”:

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/

