怎么進(jìn)行WordPress 5.0.0 RCE分析

本篇文章為大家展示了怎么進(jìn)行WordPress 5.0.0 RCE分析，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

WordPress 5.0.0 RCE分析(CVE-2019-6977)

此漏洞通過路徑遍歷和本地文件包含漏洞的組合實(shí)現(xiàn)WorePress核心中的遠(yuǎn)程代碼執(zhí)行，據(jù)漏洞發(fā)布者ripstech透露，此漏洞已在WordPress核心中存在6年以上。

權(quán)限需求

author及以上權(quán)限，相對來說，權(quán)限需求不算高，很多小型協(xié)作內(nèi)容輸出小社區(qū)諸如樂譜站會較為常用wordpress，而后給予普通作者author權(quán)限。

影響范圍

因WordPress 4.9.9和5.0.1其他安全補(bǔ)丁所致，文件包含漏洞僅有5.0.0單一版本可利用，而路徑遍歷漏洞仍可使用且當(dāng)前仍未打補(bǔ)丁。任何安裝了此插件的WordPress站點(diǎn)都會錯(cuò)誤地處理Post Meta條目，這樣仍然可以進(jìn)行利用。

漏洞基礎(chǔ)

將圖像上傳到WordPress安裝時(shí)，首先將其移動到uploads目錄（wp-content/uploads）。WordPress還將創(chuàng)建對數(shù)據(jù)庫中圖像的內(nèi)部引用，以跟蹤元信息，例如圖像的所有者或上傳的時(shí)間。

該屬性作為Post Meta條目存儲在數(shù)據(jù)庫中。這些條目中的每一個(gè)都是鍵/值對，分配給某個(gè)ID。

譬如：

SELECT * FROM wp_postmeta WHERE post_ID = 50;

+---------+-------------------------+----------------------------+
| post_id | meta_key                | meta_value                 |
+---------+-------------------------+----------------------------+
|      50 | _wp_attached_file       | evil.jpg                   |
|      50 | _wp_attachment_metadata | a:5:{s:5:"width";i:450 ... |
...
+---------+-------------------------+----------------------------+

在此示例中，圖像已分配給post_ID 50.倘若用戶希望將來使用或編輯具有所述ID的圖像，WordPress將查找匹配的_wp_attached_file條目并使用它的值以便在wp-content/uploads目錄中查找該文件。

漏洞構(gòu)成

本地文件包含部分

WordPress 4.9.9和5.0.1之前的這些Post Meta條目的問題在于可以修改任何條目并將它們設(shè)置為任意值。

當(dāng)圖像被更新時(shí)（例如，它的描述被改變），該edit_post()函數(shù)被調(diào)用。該函數(shù)直接作用于$_POST數(shù)組。

function edit_post( $post_data = null ) {

    if ( empty($postarr) )
        $postarr = &$_POST;
    ?
    if ( ! empty( $postarr['meta_input'] ) ) {
        foreach ( $postarr['meta_input'] as $field => $value ) {
            update_post_meta( $post_ID, $field, $value );
        }
    }

可以看出，可以注入任意Post Meta條目。由于未對哪些條目進(jìn)行了修改，因此攻擊者可以更新_wp_attached_file元條目并將其設(shè)置為任何值。這不會以任何方式重命名文件，它只會更改WordPress在嘗試編輯圖像時(shí)要查找的文件。這將導(dǎo)致稍后的路徑遍歷。

具體位置：

• POST參數(shù)_wp_page_template在函數(shù)get_page_template_slug（）中的文件wordpress / wp-includes / post-template.php的第1695行中被接收。

• 
  

• 

• 
  

• 用戶提供的數(shù)據(jù)在函數(shù)locate_template（）中的文件wordpress / wp-includes / template.php的第635行連接成路徑標(biāo)記。

• 
  

• 

• 
  

• 然后，在函數(shù)load_template（）中的文件wordpress / wp-includes / template.php的第690行中的敏感操作require（）中使用用戶提供的數(shù)據(jù)進(jìn)行未經(jīng)過處理。

• 
  

• 

路徑遍歷部分

路徑遍歷發(fā)生在wp_crop_image()用戶裁剪圖像時(shí)調(diào)用的函數(shù)中。

該函數(shù)將圖像的ID帶到crop（$attachment_id）并從數(shù)據(jù)庫中獲取相應(yīng)的_wp_attached_filePost Meta條目。

由于缺陷edit_post()，$src_file可以設(shè)置為任何東西。

function wp_crop_image( $attachment_id, $src_x, ...) {

    $src_file = $file = get_post_meta( $attachment_id, '_wp_attached_file' );
    ?

在下一步中，WordPress必須確保圖像實(shí)際存在并加載它。WordPress有兩種加載給定圖像的方法。第一種是簡單地查找目錄中_wp_attached_file Post Meta條目提供的文件名wp-content/uploads（下一個(gè)代碼片段的第2行）。

如果該方法失敗，WordPress將嘗試從其自己的服務(wù)器下載圖像作為后備。為此，它將生成一個(gè)下載URL，該URL包含wp-content/uploads目錄的URL 和存儲在_wp_attached_file Post Meta條目中的文件名（第6行）。

舉一個(gè)具體的例子：如果存儲在_wp_attached_file Post Meta條目中的值是evil.jpg，那么WordPress將首先嘗試檢查文件是否wp-content/uploads/evil.jpg存在。如果沒有，它會嘗試從以下URL下載文件：https://targetserver.com/wp-content/uploads/evil.jpg。

嘗試下載圖像而不是在本地查找圖像的原因是某些插件在訪問URL時(shí)動態(tài)生成圖像。

但是，這里沒有進(jìn)行任何過濾。WordPress將簡單地將上傳目錄和URL與$src_file用戶輸入連接起來。

一旦WordPress成功加載了有效圖像wp_get_image_editor()，即裁剪圖像。

 ?
    if ( ! file_exists( "wp-content/uploads/" . $src_file ) ) {
            // If the file doesn't exist, attempt a URL fopen on the src link.
            // This can occur with certain file replication plugins.
            $uploads = wp_get_upload_dir();
            $src = $uploads['baseurl'] . "/" . $src_file;
        } else {
            $src = "wp-content/uploads/" . $src_file;
        }

    $editor = wp_get_image_editor( $src );
    ?

然后將裁剪后的圖像保存回文件系統(tǒng)（無論是否下載）。生成的文件名將是$src_file由get_post_meta()攻擊者控制的返回文件。對結(jié)果文件名字符串進(jìn)行的唯一修改是文件的基本名稱前綴cropped-（下一個(gè)代碼片段的第4行）。為了遵循示例evil.jpg，生成的文件名將是cropped-evil.jpg。

然后，WordPress通過wp_mkdir_p()（第6行）在結(jié)果路徑中創(chuàng)建不存在的任何目錄。

然后使用save()圖像編輯器對象的方法將其最終寫入文件系統(tǒng)。該save()方法還不對給定的文件名執(zhí)行路徑遍歷檢查。

 ?
    $src = $editor->crop( $src_x, $src_y, $src_w, $src_h, $dst_w, $dst_h, $src_abs );

    $dst_file = str_replace( basename( $src_file ), 'cropped-' . basename( $src_file ), $src_file );

    wp_mkdir_p( dirname( $dst_file ) );

    $result = $editor->save( $dst_file );

函數(shù)整體(wp-admin / includes / image.php)如是：

實(shí)現(xiàn)RCE

綜上，可以確定哪個(gè)文件被加載到圖像編輯器中(因未進(jìn)行處理)。但是，如果文件不是有效圖像，圖像編輯器將會拋出異常。故而，只能在上傳目錄之外裁剪圖像。

那么如果未找到所需圖像，WordPress會嘗試下載，這就導(dǎo)致了RCE。

設(shè)置_wp_attached_file為evil.jpg?shell.php，這將導(dǎo)致對以下URL發(fā)出HTTP請求：https://targetserver.com/wp-content/uploads/evil.jpg?shell.php。此請求將返回有效的圖像文件，因?yàn)?code>?在此上下文中忽略了所有內(nèi)容。生成的文件名將是evil.jpg?shell.php。

雖說save()圖像編輯器的方法不會檢查是否存在路徑遍歷，但它會將正在加載的圖像的mime類型的擴(kuò)展名附加到生成的文件名中。在這種情況下，結(jié)果文件名將是evil.jpg?cropped-shell.php.jpg。這使得新創(chuàng)建的文件再次無害。

但是，仍可以通過使用諸如的Payload將生成的圖像植入任何目錄evil.jpg?/../../evil.jpg。

路徑遍歷 --> themes目錄 LFI

每個(gè)WordPress主題只是一個(gè)位于WordPress目錄中的wp-content/themes目錄，并為不同的案例提供模板文件。例如，如果博客的訪問者想要查看博客帖子，則WordPress會post.php在當(dāng)前活動主題的目錄中查找文件。如果它找到了模板，那include()就是它。

為了添加額外的自定義層，可以為某些帖子選擇自定義模板。為此，用戶必須將數(shù)據(jù)庫中的_wp_page_template Post Meta條目設(shè)置為這樣的自定義文件名。這里唯一的限制是要include()編輯的文件必須位于當(dāng)前活動主題的目錄中。

通常，無法訪問此目錄，也無法上載文件。但是，通過濫用上述Path Traversal，可以將惡意制作的圖像植入當(dāng)前使用的主題的目錄中。然后攻擊者可以創(chuàng)建一個(gè)新帖子并濫用相同的錯(cuò)誤，使他能夠更新_wp_attached_file Post Meta條目以便include()映像。通過將PHP代碼注入映像，攻擊者可以獲得任意遠(yuǎn)程執(zhí)行代碼。

Payload制作----Imagick

WordPress支持PHP的兩個(gè)圖像編輯擴(kuò)展：GD和Imagick。它們之間的區(qū)別在于Imagick不會刪除圖像的exif元數(shù)據(jù)，其中可以存儲PHP代碼。

WordPress 5.0.0 RCE 條件較為苛刻，但畢竟是RCE，一旦被利用危害巨大。況且，雖說僅這一小版本的本地文件包含可協(xié)同目錄遍歷完成RCE，但因?yàn)檫@目錄遍歷漏洞至今未修，一旦用戶安裝允許覆蓋任何Post data的插件，這RCE依然可被利用。

上述內(nèi)容就是怎么進(jìn)行WordPress 5.0.0 RCE分析，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。