모든 파일 삭제 취약성 분석을 재현 Wordpress4.9.6

장 하나 소개 취약점 및 위험 분석

취약점 1.1 소개

워드 프레스는 오늘 (나는 아무 말도 할) PHP 기반의 가장 인기있는 오픈 소스 CMS, 전 세계 수백만 사용자에게 현재까지 말했다 및 다운로드 초 이상 46,000,000 번이 될 수있다. 그것은, 그 기능 다음에 오픈 소스 시스템은 매우 강력하다 소스 코드는 여기에서 찾을 수 있습니다 . 워드 프레스 사용자가 추락 한 번에 수백만 달러를 성공 수단 많은 해커의 목표가 왜, 어느. 이 광범위하게 채택은 사이버 범죄자에 대한 흥미로운 대상 있습니다. 실험은 인증 된 문서의 워드 프레스 코어의 취약점은 취약점 CVE-2018-20714 제거입니다

이 취약점은 공격자가 임의 코드를 실행할 수 있습니다. 취약점의 발견에 워드 프레스 보안 팀에보고하기 때문에 (7) 개월 , 아직 수리되지 않았습니다. 첫 번째 보고서 이후로 패치 나 구체적인 계획없이 긴 시간을 통과했다. 이제 wordpress4.9.6 다음 이 취약점의 버전.

사용 허점의 1.2 조건

아래에서 논의 된 취약점을 악용하려면 공격자 요구 편집 및 삭제 미디어 파일에 대한 사전 허가를 받아야합니다. 즉,이 저자의 권한을. 여기에서 우리는 사용자 권한을 WordPress의 무엇을보고해야합니다.

• 슈퍼 관리자 (슈퍼 관리자) - 사이트 네트워크 관리 기능 및 기타 모든 기능에 액세스 할 수있는 권리.
• 관리자 (관리자) - 모든 단일 사이트 내에서 관리 기능에 액세스 할 수 있습니다.
• (편집기) 편집 - 게시하고 다른 사용자의 글을 포함하여 게시물을 관리 할 수 ​​있습니다.
• 저자 (저자) - 게시하고 자신의 게시물을 관리 할 수 ​​있습니다.
• 참가자 (기여자) - 당신이 작성하고 자신의 게시물을 관리하지만, 게시 할 수 없습니다.
• 가입자 (가입자) - 그들의 개인 정보를 관리 할 수 ​​있습니다.

우리는 사용자는 작성자 권한을 게시하고 자신의 게시물을 관리 할 수 ​​있지만,이 취약점이 아니라 전체 사이트를 납치하고, 워드 프레스는이 결함에 의해, 공격자가 쉽게 사이트를 제어 할 수있는 서버에 임의의 코드를 실행할 수 있습니다주었습니다.

사용자가 영구적으로 백그라운드에서 썸네일 이미지 업로드 실행을 삭제하면 워드 프레스 취약점의 핵심 기능 중 하나는 존재한다.

1.3 위험 취약점

그것은 자동으로 악용 어떤 방법으로 저자의 자격 증명을 취득, 그렇지 않으면 공격 해커 또는 악성 콘텐츠 작가 피싱, 암호 재사용, 또는에 의해 악용 될 수있는 몇 가지 정도에이 취약점의 심각도를 감소시킬 것이다 계정 중 적어도 하나를 필요 .

이 취약점으로 인해 공격자가 임의의 파일을 워드 프레스 설치 (삭제 권한 서버에서 다른 파일과 + PHP 프로세스 사용자)을 삭제시킬 수있는 공격. 비참한 결과를 가져올 수없는 현재 백업을 사용할 수없는 경우, 전체 워드 프레스 설치를 삭제의 가능성뿐만 아니라, 공격자가 우회하기 보안 조치로 모든 파일을 삭제하고 웹 서버에 임의의 코드를 실행할 수있는 기능을 활용할 수 있습니다. 더 정확하게, 당신은 다음과 같은 파일을 삭제할 수 있습니다 :

• htaccess로 : 일반적으로, 어떤 안전 영향없이 파일을 삭제합니다. 그러나 어떤 경우에는, htaccess로 파일 (특정 폴더 제약, 예를 들어, 액세스) 보안에 관련된 제약 조건이 포함되어 있습니다. 이러한 보안 제한을 해제합니다이 파일을 삭제합니다.
• 의 index.php 파일 : 일반적으로 비어 index.php에 이 작업 디렉토리 목록을 수행 할 수 없습니다 웹 서버를 방지하기 위해 디렉토리에 파일을. 이러한 파일을 삭제하는 모든 파일의 디렉토리 목록을 보호하기 위해이 법안에 의해 공격자에게 수여됩니다.
• config.php를-WP : 다음 번에 당신이 사이트를 방문 할 때 워드 프레스 워드 프레스 설치 프로세스를 설치합니다 파일을 삭제 트리거됩니다. 때문이다 WP-config.php에이 데이터베이스 자격 증명을 포함하고, 그것의 존재없이, 워드 프레스는 같은 설치되지 않았습니다. 이 파일을 삭제할 수 있습니다 공격자는, 그는 관리자 계정 자격 증명 설치 프로세스에 사용하고, 마지막으로 서버에 임의의 코드를 실행하기로 결정했습니다.

그가 할 수 있습니다 그러나, 공격자는 WP-config.php 파일의 내용을 읽을 수 없기 때문에 직접 기존의 "데이터베이스 이름"을 알고, 주목해야한다 "MySQL의 사용자 이름"과 "암호", 대상 사이트를 다시 설정 자신의 통제하에 원격 데이터베이스 서버를 사용. 완료되면, 공격자는 새로운 관리자 계정과 서버에서 임의의 코드를 실행하는 기능을 포함하여 사이트의 완전한 제어를 만들 수 있습니다. "비참한 결과가 발생합니다에는 현재 백업을 사용할 수없는 경우, 전체 워드 프레스 설치를 삭제의 가능성뿐만 아니라, 공격자가 우회하기 보안 조치로 모든 파일 삭제 기능을 사용할 수 있으며 웹 서버에 임의의 코드를 실행

 

제 2 장 빌드 및 재현하기위한 환경을 취약점

2.1 빌드 환경

이동 워드 프레스 중국어 공식 웹 사이트 https://cn.wordpress.org/download/releases/의 다운로드 버전이 취약점을 가지고

(1) 설치 워드 프레스

워드 프레스 4.9.6

 

성공적으로 설치 한 후, 백그라운드에서 테스트 용으로 만 기능을 쓰는 '작가 "권한 계정"XY "를 추가

2.2 취약성 테스트 재현성

사이트 배경에 새로 추가 된 사용자 권한의 방문 (1)

(2) 추가 매체는 이미지를 업로드

  

(3) 편집을 클릭

(4) 소스에 의해 아래로 "388054b4f3"쿠키 복사 및 페이지의 값을 찾아, 페이지 소스 코드에서 _wpnonce 값을 식별합니다.

 

(5) 다음은 구부러 지거나 트림 구성된 HTTP 요청을 사용한다.

패킷 중계를 보내도록 구성된 다음 (쿠키에 필요한 값) 패킷 전송 포스트

payload: action=editattachment&_wpnonce=388054b4f3&thumb=../../../../wp-config.php'   

POST /wp-admin/post.php?post=21&action=edit HTTP/1.1 

发送成功会返回302状态

 

（6）此时在点击删除按钮

（7）抓包查看，也是返回302包

（8）再次访问主网站就会要求重新安装wordpress

 

 

第三章 漏洞代码审计以及临时手动修复

 

3.1 源码审计

（1）既然是任意文件删除漏洞，那我们就从删除功能入手，先来看wp-admin/post.php的246-268行：

case 'delete':

    check_admin_referer('delete-post_' . $post_id);

 

    if ( ! $post )

        wp_die( __( 'This item has already been deleted.' ) );

 

    if ( ! $post_type_object )

        wp_die( __( 'Invalid post type.' ) );

 

    if ( ! current_user_can( 'delete_post', $post_id ) )

        wp_die( __( 'Sorry, you are not allowed to delete this item.' ) );

 

    if ( $post->post_type == 'attachment' ) { //删除附件

        $force = ( ! MEDIA_TRASH );

        if ( ! wp_delete_attachment( $post_id, $force ) )

            wp_die( __( 'Error in deleting.' ) );

    } else {

        if ( ! wp_delete_post( $post_id, true ) )

            wp_die( __( 'Error in deleting.' ) );

    }

 

    wp_redirect( add_query_arg('deleted', 1, $sendback) );

    exit();

 

（2）由于我们删除的是图片附件，所以程序会进入wp_delete_attachment函数，跟进：  wp-include/post.php，函数太长，只截取关键部分。

function wp_delete_attachment( $post_id, $force_delete = false ) {
.... 
    if ( ! empty($meta['thumb']) ) {
    // Don't delete the thumb if another attachment uses it.
    if (! $wpdb->get_row( $wpdb->prepare( "SELECT meta_id FROM $wpdb->postmeta WHERE meta_key = '_wp_attachment_metadata' AND meta_value LIKE %s AND post_id <> %d", '%' . $wpdb->esc_like( $meta['thumb'] ) . '%', $post_id)) ) {
        $thumbfile = str_replace(basename($file), $meta['thumb'], $file);
        /** 该过滤器记录在wp-includes / functions.php中 */
        $thumbfile = apply_filters( 'wp_delete_file', $thumbfile );
        @ unlink( path_join($uploadpath['basedir'], $thumbfile) );
    }
}
. . . .
 
wp_delete_file( $file );

 

$meta['thumb']来自与数据库，是图片的属性之一。代码未检查$meta['thumb']的内容，直接带入unlink函数，如果$meta['thumb']可控

 (3) 那么可控点在哪呢？还记得漏洞利用的第一步吗？现在我们就回到wp-admin/post.php看一下具体代码

/wp-admin/post.php

 
//178-189行
case 'editattachment':
    check_admin_referer('update-post_' . $post_id);
 
    // Don't let these be changed
    unset($_POST['guid']);
    $_POST['post_type'] = 'attachment';
 
    // Update the thumbnail filename
$newmeta = wp_get_attachment_metadata( $post_id, true ); 
//获取附件的属性
    $newmeta['thumb'] = $_POST['thumb'];
 
wp_update_attachment_metadata( $post_id, $newmeta );
 //更新数据库中的信息

代码片段/wp-admin/post.php表示如何将属于附件的缩略图的文件名保存到数据库中。在从保存的用户输入检索$_POST[‘thumb’]和保存到数据库wp_update_attachment_metadata()之间，没有安全措施来确保该值确实代表正在编辑的附件的缩略图。值$_POST[‘thumb’]可以变更修改为相对于WordPress上传目录的任何文件的路径，当附件被删除时，文件将被删除，如第一个列表中所示。

总结一句就是该漏洞出现的原因是由于在WordPress的wp-includes/post.php文件中wp_delete_attachement()函数在接收删除文件参数时未进行安全处理，直接进行执行导致。

3.2临时手动修复

（1）在上面我们了解了漏洞生成的原因之后，我们将进行尝试性的漏洞修复。

首先针对漏洞细节提出修复方向

1. 过滤. \等关键字符

2. 挂钩wp_update_attachement_metadata()调用并确保为meta[‘thumb’]值提供的数据thumb不包含任何可以进行路径遍历的部分.

3. 将$newmeta['thumb'] = $_POST['thumb'];改为$newmeta['thumb'] = basename($_POST['thumb']);

（2）修复代码

通过将修复程序添加到functions.php当前活动的主题/子主题的文件中，可以将修复程序集成到现有的WordPress安装中。

add_filter('wp_update_attachment_metadata','rips_unlink_tempfix';
 
function rips_unlink_tempfix( $data ) {
    if( isset($data['thumb']) ) {
        $data['thumb'] = basename($data['thumb']);
    }
 
    return $data;
}

 

我们将补丁放入指定位置之后，再来测试漏洞。

 

可以看到在手动打了补丁之后，虽然发包和回显跟之前区别不大，但是已经无法任意删除文件了

 

第四章 漏洞操作的流量分析

总体操作与上文漏洞复现差不多，但为了监控流量和避免干扰便于分析，本次操作在虚拟机中进行并使用wireshark分析流量。

（1）使用wireshark捕获恶意操作的流量数据

 

 

 

服务器返回302

我们发现恶意数据最主要的特征就是向服务器传入了一个“thumb”自定义的值

（2）我们追踪这个包的tcp流

 

 

 

也出现了我们构造的关键代码，但由于这个漏洞可以删除任意文件，所以我们需要关注的就是thumb传入的数值，不管上传请求的方式是什么，总需要传入

thumb=xxxx

所以当流量中出现这些异常并指定thumb的值的时候，就需要引起我们的注意，要查看数值是否合法。