0x00
? ? 前些日子，例行每天打開各大論壇，exploit-db進行遨游，發現了都在寫joomla 3.4.6的RCE漏洞，也有說他是反序列漏洞。本來以為是跟幾年前CVE-2015-8562的EXP公布了是同一個洞，再加上當時有任務就跳過沒去測試。最近閑下來了，突然就想再試試，比較CVE-2015-8562這一個洞我當時沒有成功利用過，拉了docker，用phpstudy搭了環境也都失敗。結果，一看文章才發現雖然都需要用到反序列化構造POP鏈但是漏洞出現的地方并不一樣。下面就講一下這個洞的復現。
0x01
? ? 首先先下載對應版本號 joomla 3.4.6?https://downloads.joomla.org/it/cms/joomla3/3-4-6
? ? 然后取exploit-db上下載exp，這邊就不放出來了。
? ? 接下來用phpstudy搭建好環境之后就能測試了，emmmm php版本我使用的是5.4.45 比較在復現CVE-2015-8562發現特定版本才能達到反序列化的作用。
? ? 接下來直接EXP利用：
? ? ? 可以看到利用成功之后會在configuration.php文件下生成一段隨機密鑰的一句話，拿你的菜刀或者蟻劍連接就行。
0x10
? ? ? 我們來看下EXP文件的簡單構造。
? ? ? 攻擊過程主要如下：
? ? ? 可以看到傳入url以及構造的pop鏈然后對登錄頁面進行登錄操作，我們可以看payload主要集中在pwd字段上，跟進到源碼中，前文也提到該漏洞的利用是經過反序列化的，所以問題應該同樣出現在session儲存后以及取出時候出現的問題，我們先進入到joomla存放session會話數據的session表中，
? ? 通過這張表我們發現，session數據在序列化之后會儲存到數據庫中，并且登陸失敗的用戶也會被記錄，這也是為什么該exp不需要身份驗證吧。
? ? 回到joomla儲存機制的本身，一開始我以為跟8562一樣是對‘|’的過濾不充分導致的反序列化漏洞，看了下公布的文章和EXP，問題出在了read()和write()兩個函數中，在儲存和讀取時候序列化問題導致能夠繞過代碼。
? ? ? ? 著重read()以及write()的str_replace函數中，mysql沒法處理空字符，他就將chr(0)*chr(0)在存入的時候變成\0\0\0取出來之后在替換回chr(0)*chr(0)。那么這時候問題就來了 \0\0\0長度為6，序列化之后s:6而chr(0)*chr(0)序列化之后s:3,攻擊者可以惡意構造輸入\0\0\0輸入導致反序列化時由于被程序替換,會將后面的3個字符當作一起使用。這時候第二段字符就逃逸成功了。然后通過構造惡意代碼就能達成攻擊。
? ? ? ? 那么我們應該如何構造pop攻擊鏈呢
關于該漏洞的pop攻擊鏈跟CVE-2015-8562是一樣的JDatabaseDriverMysqli->__destruct->disconnect->call_user_func_array。通過控制參數值構成一個回調后門達到攻擊。這里需要讀者自行查閱了。? ? ? ??
