Wordpress內(nèi)容注入漏洞致超67000個(gè)網(wǎng)站遭黑產(chǎn)利用
如果你的網(wǎng)站使用的是WordPress，并且沒有及時(shí)更新官方上周發(fā)布的補(bǔ)丁，升級到v4.7.2版本，那么你的網(wǎng)站很有可能受到這4個(gè)黑客組織的攻擊。
據(jù)國外Web安全公司Sucuri表示，自上周一該漏洞細(xì)節(jié)公開后，攻擊范圍不斷擴(kuò)大，最近每天趨于3000次。
隨著時(shí)間的推移利用REST API漏洞嘗試次數(shù)(來源：Sucuri)
攻擊者正在利用WordPress的REST API的漏洞，該漏洞由WordPress團(tuán)隊(duì)兩個(gè)星期前修復(fù)并更新補(bǔ)丁，他們于上周一公開了漏洞詳情。
攻擊者利用這個(gè)漏洞精心構(gòu)造一個(gè)向目標(biāo)站點(diǎn)REST API發(fā)起的HTTP請求，可以修改文章的標(biāo)題和內(nèi)容。
上周已經(jīng)有人提供了完整的利用代碼。
超過67,000的網(wǎng)站內(nèi)容已經(jīng)被篡改
即使該漏洞僅影響WordPress4.7.0和4.7.1兩個(gè)版本而且該CMS內(nèi)置有自動更新的功能，但仍然有很多網(wǎng)站沒有更新。
據(jù)Sucuri部署的蜜罐服務(wù)器收集到的數(shù)據(jù)顯示，在過去的一周，有四波攻擊者正在著手利用這個(gè)漏洞。
由于攻擊已經(jīng)持續(xù)一段時(shí)間了，谷歌已經(jīng)可以檢索一部分被攻擊的內(nèi)容。
通過Google檢索被篡改的站點(diǎn)
通過Google搜索"by w4l3XzY3"，可以瀏覽一些受影響的站點(diǎn)。
部分受影響的站點(diǎn)列表
更多受影響站點(diǎn)可在http://www.zone-h.org/archive/notifier=w4l3XzY3/page=1查看。
目前，使用REST API漏洞篡改網(wǎng)站的這些組織只是做了一些知名度的曝光，將網(wǎng)站內(nèi)文章的標(biāo)題和正文修改為自己的內(nèi)容。
其中一個(gè)被篡改的站點(diǎn)
Sucuri's CTO, Daniel Cid表示希望看到更專業(yè)的內(nèi)容進(jìn)入大家的視野，如利用該漏洞發(fā)布更復(fù)雜的內(nèi)容，黑鏈SEO：如插入鏈接和圖像。
利用漏洞做這種篡改的話，做黑鏈SEO，可以提高其他網(wǎng)站的搜索引擎排名，或者宣傳一些其他的非法產(chǎn)品。
當(dāng)然如果網(wǎng)站內(nèi)容被篡改為一些惡意內(nèi)容，會導(dǎo)致網(wǎng)站被搜索引擎屏蔽。
建議所有使用WordPress的網(wǎng)站主及時(shí)更新至最新版本v4.7.2。避免由于REST API的安全問題，導(dǎo)致網(wǎng)站被搜索引擎屏蔽。
0x00 漏洞簡述
1. 漏洞簡介
在REST API自動包含在Wordpress4.7以上的版本，WordPress REST API提供了一組易于使用的HTTP端點(diǎn)，可以使用戶以簡單的JSON格式訪問網(wǎng)站的數(shù)據(jù)，包括用戶，帖子，分類等。檢索或更新數(shù)據(jù)與發(fā)送HTTP請求一樣簡單。上周，一個(gè)由REST API引起的影響WorePress4.7.0和4.7.1版本的漏洞被披露，該漏洞可以導(dǎo)致WordPress所有文章內(nèi)容可以未經(jīng)驗(yàn)證被查看，修改，刪除，甚至創(chuàng)建新的文章，危害巨大。
2. 漏洞影響版本
WordPress4.7.0
WordPress4.7.1
0x01 漏洞復(fù)現(xiàn)
Seebug上已經(jīng)給出詳細(xì)的復(fù)現(xiàn)過程，在復(fù)現(xiàn)過程中可以使用已經(jīng)放出的POC來進(jìn)行測試。
0x02 漏洞分析
其實(shí)漏洞發(fā)現(xiàn)者已經(jīng)給出了較為詳細(xì)的分析過程，接下來說說自己在參考了上面的分析后的一點(diǎn)想法。
WP REST API
首先來說一下REST API。
控制器
WP-API中采用了控制器概念，為表示自愿端點(diǎn)的類提供了標(biāo)準(zhǔn)模式，所有資源端點(diǎn)都擴(kuò)展WP_REST_Controller來保證其實(shí)現(xiàn)通用方法。
五種請求
之后，WP-API還有這么幾種請求(也可以想成是功能吧)：
- HEAD
- GET
- POST
- PUT
- DELETE
以上表示HTTP客戶端可能對資源執(zhí)行的操作類型。
HTTP客戶端
WordPress本身在WP_HTTP類和相關(guān)函數(shù)中提供了一個(gè)HTTP客戶端。用于從另一個(gè)訪問一個(gè)WordPress站點(diǎn)。
資源
簡單來說，就是文章，頁面，評論等。
WP-API允許HTTP客戶端對資源執(zhí)行CRUD操作(創(chuàng)建，讀取，更新，刪除，這邊只展示和漏洞相關(guān)的部分)：
GET /wp-json/wp/v2/posts獲取帖子的集合：
GET /wp-json/wp/v2/posts/1獲取一個(gè)ID為1的單獨(dú)的Post：
可以看到ID為1的文章標(biāo)題為Hello World，包括文章的路由也有。
路由
路由是用于訪問端點(diǎn)的“名稱”，在URL中使用(在非法情況下可控，就像這個(gè)漏洞一樣)。
例如，使用URLhttp://example.com/wp-json/wp/v2/posts/123:
路由(route)是wp/v2/posts/123，不包括wp-json，因?yàn)閣p-json是API本身的基本路徑。
這個(gè)路由有三個(gè)端點(diǎn)：
GET觸發(fā)一個(gè)get_item方法，將post數(shù)據(jù)返回給客戶端。
PUT觸發(fā)一個(gè)update_item方法，使數(shù)據(jù)更新，并返回更新的發(fā)布數(shù)據(jù)。
DELETE觸發(fā)delete_item方法，將現(xiàn)在刪除的發(fā)布數(shù)據(jù)返回給客戶端。
靜態(tài)追蹤
知道了WP-API的路由信息以及其操作方式，可以根據(jù)其運(yùn)行的思路來看一下具體實(shí)現(xiàn)的代碼。
我們看一下/wp-includes/rest-api/endpoints/class-wp-rest-post-controller.php：
根據(jù)上面的信息，我們可以知道這是注冊controller對象的路由，實(shí)現(xiàn)路由中端點(diǎn)方法。
在這里，如果我們向/wp-json/wp/v2/posts/1發(fā)送請求，則ID參數(shù)將被設(shè)置為1：
同時(shí)，注意一下這里：
- register_rest_route( $this->namespace, '/' . $this->rest_base . '/(?P<id>[\d]+)', array(
- array(
- 'methods' => WP_REST_Server::READABLE,
- 'callback' => array( $this, 'get_item' ),
- 'permission_callback' => array( $this, 'get_item_permissions_check' ),
- 'args' => $get_item_args,
- ),
- array(
- 'methods' => WP_REST_Server::EDITABLE,
- 'callback' => array( $this, 'update_item' ),
- 'permission_callback' => array( $this, 'update_item_permissions_check' ),
- 'args' => $this->get_endpoint_args_for_item_schema( WP_REST_Server::EDITABLE ),
- ),
- array(
- 'methods' => WP_REST_Server::DELETABLE,
- 'callback' => array( $this, 'delete_item' ),
- 'permission_callback' => array( $this, 'delete_item_permissions_check' ),
- 'args' => array(
- 'force' => array(
- 'type' => 'boolean',
- 'default' => false,
- 'description' => __( 'Whether to bypass trash and force deletion.' ),
- ),
- ),
- ),
- 'schema' => array( $this, 'get_public_item_schema' ),
- ) );
可以看到在register_rest_route中對路由進(jìn)行了正則限制：
也就是防止攻擊者惡意構(gòu)造ID值，但是我們可以發(fā)現(xiàn)$_GET和$_POST值優(yōu)先于路由正則表達(dá)式生成的值：
這邊沒有找到ID為123hh的項(xiàng)目，所以返回rest_invalid。
現(xiàn)在我們可以忽略路由正則的限制，來傳入我們自定義的ID。
接下來在審查各個(gè)端點(diǎn)方法中，找到了update_item這個(gè)方法，及其權(quán)限檢查方法update_item_permissions_check：
- public function update_item_permissions_check( $request ) {
- $post = get_post( $request['id'] );
- $post_type = get_post_type_object( $this->post_type );
- if ( $post && ! $this->check_update_permission( $post ) ) {
- return new WP_Error( 'rest_cannot_edit', __( 'Sorry, you are not allowed to edit this post.' ), array( 'status' => rest_authorization_required_code() ) );
- }
- if ( ! empty( $request['author'] ) && get_current_user_id() !== $request['author'] && ! current_user_can( $post_type->cap->edit_others_posts ) ) {
- return new WP_Error( 'rest_cannot_edit_others', __( 'Sorry, you are not allowed to update posts as this user.' ), array( 'status' => rest_authorization_required_code() ) );
- }
- if ( ! empty( $request['sticky'] ) && ! current_user_can( $post_type->cap->edit_others_posts ) ) {
- return new WP_Error( 'rest_cannot_assign_sticky', __( 'Sorry, you are not allowed to make posts sticky.' ), array( 'status' => rest_authorization_required_code() ) );
- }
- if ( ! $this->check_assign_terms_permission( $request ) ) {
- return new WP_Error( 'rest_cannot_assign_term', __( 'Sorry, you are not allowed to assign the provided terms.' ), array( 'status' => rest_authorization_required_code() ) );
- }
- return true;
- }
可以看到，此函數(shù)通過檢查文章是否實(shí)際存在，以及我們的用戶是否有權(quán)限編輯這邊文章來驗(yàn)證請求。但是當(dāng)我們發(fā)送一個(gè)沒有響應(yīng)文章的ID時(shí)，就可以通過權(quán)限檢查，并允許繼續(xù)執(zhí)行對update_item方法的請求。
具體到代碼，就是讓$post為空，就可以通過權(quán)限檢查，接下來跟進(jìn)get_post方法中看一下：
- function get_post( $post = null, $output = OBJECT, $filter = 'raw' ) {
- if ( empty( $post ) && isset( $GLOBALS['post'] ) )
- $post = $GLOBALS['post'];
- if ( $post instanceof WP_Post ) {
- $_post = $post;
- } elseif ( is_object( $post ) ) {
- if ( empty( $post->filter ) ) {
- $_post = sanitize_post( $post, 'raw' );
- $_post = new WP_Post( $_post );
- } elseif ( 'raw' == $post->filter ) {
- $_post = new WP_Post( $post );
- } else {
- $_post = WP_Post::get_instance( $post->ID );
- }
- } else {
- $_post = WP_Post::get_instance( $post );
- }
- if ( ! $_post )
- return null;
從代碼中可以看出，它是用wp_posts中的get_instance靜態(tài)方法來獲取文章的，跟進(jìn)wp_posts類，位于/wp-includes/class-wp-post.php中：
- public static function get_instance( $post_id ) {
- global $wpdb;
- if ( ! is_numeric( $post_id ) || $post_id != floor( $post_id ) || ! $post_id ) {
- return false;
- }
可以看到，當(dāng)我們傳入的ID不是全由數(shù)字字符組成的時(shí)候，就會返回false，也就是返回一個(gè)不存在的文章。從而get_post方法返回null，從而繞過update_item_permissions_check的權(quán)限檢測。
回頭再看一下可執(zhí)行方法upload_item：
- public function update_item( $request ) {
- $id = (int) $request['id'];
- $post = get_post( $id );
- if ( empty( $id ) || empty( $post->ID ) || $this->post_type !== $post->post_type ) {
- return new WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.' ), array( 'status' => 404 ) );
- }
- $post = $this->prepare_item_for_database( $request );
- if ( is_wp_error( $post ) ) {
- return $post;
- }
- // convert the post object to an array, otherwise wp_update_post will expect non-escaped input.
- $post_id = wp_update_post( wp_slash( (array) $post ), true );
在這邊將ID參數(shù)裝換為一個(gè)整數(shù)，然后傳遞給get_post。而PHP類型轉(zhuǎn)換的時(shí)候回出現(xiàn)這樣的情況：
所以，也就是說，當(dāng)攻擊者發(fā)起/wp-json/wp/v2/posts/1?id=1hhh請求時(shí)，便是發(fā)起了對ID為1的文章的請求。下面為利用[exploit-db][2]上的POC來進(jìn)行測試：
新建文章：
測試：
測試結(jié)果：
多想了一下
乍一看，感覺這個(gè)洞并沒有什么太大的影響，但是仔細(xì)想了一下，危害還是很大的。先不說WordPress頁面執(zhí)行php代碼的各種插件，還有相當(dāng)一部分的WordPress文章可以調(diào)用短代碼的方式來輸出特定的內(nèi)容，以及向日志中添加內(nèi)容，這是一個(gè)思路。
另一個(gè)思路就是可以進(jìn)行對原來文章中的指定超鏈接進(jìn)行修改，從而進(jìn)行釣魚。
還有一個(gè)思路，就是利用WordPress文章中解析html以及JavaScript文件包含的做法，輔助其他方法，進(jìn)行攻擊。
0x03 diff比較
對于該漏洞，關(guān)鍵的修改在/wp-includes/class-wp-post.php中：
更改了對于$post_id的參數(shù)的傳入順序和判斷條件，防止了我們傳入數(shù)字+字母這樣的格式進(jìn)行繞過。
0x04 修補(bǔ)方案
將WordPress更新到最新版本。
