關于工具 現有工具

　　現在，現成的污點分析工具已經有很多了。其中，我最感興趣的是Triton和bincat，因為兩者已經相當成熟。然而，我們卻無法使用這兩種工具，因為它們不支持目标設備所使用的MIPS架構。

　　使用angr進行符号執行測試

　　因此，我們把工作重點放在利用angr打造自己的工具上；angr是一個基于Python的二進制分析框架。我們之所以選擇angr，是因為它支持大多數架構，包括我們所針對的MIPS和ARM架構。早些時候，@puzzor曾經對angr進行了一些自定義修改，用于靜态污點分析：在angr的幫助下，通過符号執行模拟程序，然後根據生成的VEX IR程序跟蹤信息進行靜态分析。通過這種方法，我們成功地在測試固件中發現了命令注入漏洞。

　　然而，我們很快就遇到了一個問題：為了生成程序跟蹤信息，我們需要angr通過模拟每條指令來模拟每個函數，并使用符号執行來決定是否跟随一條分支指令。

　　具體來說，angr會維護一個狀态堆棧。一個狀态包含諸如寄存器值和内存内容方面的信息。因此，當模拟一個函數時，它隻會從一個狀态開始。當遇到一個分支指令時，如果angr不确定是否跟随該分支，angr将重複該狀态，其中一個将跟随該分支，而另一個則不跟随。

　　大多時候，函數中都會存在循環。如果循環條件是基于一些用戶的輸入，那麼，狀态的堆棧就會“爆炸”。由于angr将始終不确定是繼續還是從循環中跳出，所以，它會不斷複制狀态。此外，還需要注意的一件事是，這些狀态并不是同時模拟的。相反，每次隻有一個狀态被模拟。在這種情況下，需要很長的時間才會有一個狀态達到易受攻擊的代碼；或者，如果該函數根本沒有易受攻擊的代碼，那麼，模拟過程可能永遠不會終止。

　　作為一個符号執行框架，angr提供了多種可定制設置（稱為模拟技術）來決定先模拟哪個狀态。并且，在嘗試了許多不同的技術後，我們仍然無法改善執行時間。

　　例如，在為待分析二進制代碼中的每個函數設置了2分鐘的超時的情況下，有時候即使經過了2小時，仍然無法完成對二進制文件的分析（因為如果一個函數沒有漏洞，它将一直模拟執行下去，直到超時位置）。更糟糕的是，angr中存在一個未知的内存洩漏問題，所以，2小時後，電腦的内存早就耗盡了……

　　别忘了，我們之前的目标是希望這個工具比手工方式更快一些。所以，通過這種方式是不可能的，所以，我們繼續尋找改進方法或替代方案。

　　應用angr的Reaching Definition分析技術

　　最終，我們偶然發現了這個漏洞後，燃起了我們對于angr的Reaching Definitions分析技術的熱情，于是仔細閱讀了下面的資料：

　　◼A reaching definition engine for binary analysis built-in in angr

　　◼Handle function calls during static analysis in angr

　　◼CSE545 Guest Lecture: Binary Analysis

　　Use-def關系

　　總之，這種分析方法将生成函數中原子之間的use-def關系。在這裡，所謂原子類似于變量，并且，原子也具有各種類型，如寄存器、棧變量、堆變量。實際上，隻要把原子看作變量，事情就很簡單了，下面，我們舉例說明：

　　在上面的函數中，存在一個明顯的命令注入漏洞：含有漏洞的代碼為system(command)，其中注入的命令來自querystring的參數name。在這個函數中，querystring和其他原子之間的use-def關系如下所示：

　　首先，我們看到querystring被定義為函數vuln的參數，并被get_querystring_value函數作為參數querystring使用。除此之外，函數get_querystring_value還定義了一個參數name。最後，get_querystring_value函數定義了一個返回值，并用到了上面定義的兩個參數。

　　然後，通過下圖我們可以看到，在調用sprintf函數時，還用到了name變量（函數get_querystring_value的返回值）和一個字符串echo %s /tmp/log。這一次，情況略有不同。因為我們知道sprintf函數的第一個參數是目标，所以，我們必須對command進行适當的定義，從而讓它全面使用提供給spritnf函數的2個參數，而不是僅使用返回值。生成的use-def關系如下所示：

　　使用相同的概念，通過這種分析方法可以為函數中的所有原子生成相應的use-def關系。正如我們在上面看到的，這種關系可以被建模為一個圖：“使用”用邊表示，“定義”用節點表示。 因此，我們可以将其轉換為圖分析問題。

　　在污點分析術語中，source點是程序中産生污點數據的地方，而sink點是污點數據可能到達也可能不到達的地方。污點分析是确定來自source點的數據是否到達sink點。在上面的例子中，get_querystring_value函數是source點，因為它從用戶輸入中提取一些值，而system函數是sink點。就本例來說，來自source點的數據确實到達了sink點。

　　在我們的use-def圖中，我們可以确定source點和sink點的定義（即節點），然後用一些啟發式方法遍曆該圖，以确定source點的數據是否被sink點所使用。如果是，那麼我們就把source點标記為易受攻擊的，并繼續對其進行篩查。

　　工具總結

　　總而言之，我們的工具首先利用angr的Reaching Definitions分析方法，生成一個由路由器固件中的函數的組成的use-def關系圖。然後，對該圖進行相應的分析，以檢測可能的安全漏洞，比如，如果（來自source點）用戶輸入到達一個危險的函數（即sink點），如system函數，我們就認為發現了一個潛在的安全漏洞。

　　實際上，我們的工具與CodeQL或Joern等引擎的功能非常類似，隻是我們的工具缺乏強大的查詢界面而已。

　　測試結果 前面我們曾提到，使用符号執行的方法時，有時分析一個程序需要花費2個多小時。但是，使用上面介紹的方法，分析同樣的程序隻需2分鐘左右就能搞定了。所以，這看起來的确是一個不錯的工具。 在對該工具進行改進以消除假陽性并覆蓋更多的假陰性後，我們在DLink和PROLiNK路由器上進行了測試。

　　PROLiNK PRC2402M

　　使用該工具，我們立即發現了近20個命令注入漏洞，其中10個不需要身份驗證，可以直接通過WAN接口進行訪問。我們馬上向PROLiNK報告了這些漏洞，他們也很快做出了回應。在這些漏洞被修複後，我們申請了相應的CVE編号，它們分别為CVE-2021-35400到CVE-2021-35409。 下面是一些易受攻擊的代碼片段，其中source點和sink點分别是：

　　◼Source點：web_get

　　◼Sink點：system, do_system, popen

　　硬編碼的密碼，還是後門？ 在這個過程中，我還發現了一些其他的安全漏洞。似乎有一個硬編碼的密碼或後門密碼，可以用來登錄到路由器的管理面闆：管理頁面将用戶提供的密碼的md5哈希值發送到login.cgi進行驗證，相應的僞代碼如下所示：

　　然而，在它後面還有一段可疑的代碼：

　　通過将user作為密碼，我們竟然成功登錄到管理頁面。通過這種方式登錄後，顯示的儀表闆會略有不同，它似乎比通過實際密碼登陸的用戶提供的功能要少。然而，我們仍然可以訪問http://prc2402m.setup/setting.shtml，這就足以控制路由器的設置了。

　　我們向供應商報告了這一情況，他們很快就更新了固件。為了确定該後門已經消失，我再次打開了同一個函數。這次，我并沒有再看到strcat(salted_password, user)，卻看到了以下内容：

　　實際上，通過nvram查找Password_backup的值也不是什麼難事。

　　我們很快又向供應商報告了這個問題。幸運的是，經過再次修複後，已經找不到Debugdoor或後門密碼了。

　　基于堆棧的緩沖區溢出 由于缺乏邊界檢查，我們還發現了許多基于堆棧的緩沖區溢出漏洞。通過利用這些漏洞，攻擊者可以覆蓋堆棧上的返回地址，從而獲得對程序執行的控制。在上面的一些命令注入的例子中可以看到，用戶的輸入是通過sprintf函數而不是snprintf函數複制到一個字符串中的。

　　拒絕服務漏洞 在測試緩沖區溢出漏洞的PoC時，我還發現了一個漏洞，它導緻路由器停止響應請求，直到用電源按鈕手動重啟為止。在下面的僞代碼中，cli_num被作為參數傳給/sbin/sta_qos.sh腳本。

　　通過檢查腳本内容，我發現以下for循環，其中$sta_num用于保存cli_num的值。

　　如果cli_num是一個很大的值，例如999999999，那麼這個腳本幾乎會永遠困在循環中，實際上，這就是陷入了一個無限的循環。通過向路由器發送這樣的請求，會有很多這種腳本被執行并卡在循環中。 一段時間後，路由器會停止響應任何請求，這時，隻能通過手動重啟，它們才能再次正常工作。

　　時間線 ●6月9日：向供應商報告了10個命令注入漏洞。

　　●6月11日：供應商修複了相應的漏洞。

　　●6月11日：建議供應商使用一些額外的過濾器來防止此類漏洞。

　　●6月28日：供應商根據我們的建議進行了修複。

　　●7月9日：向供應商報告了另外3個漏洞（後門、緩沖區溢出、DoS）。

　　●7月23日：供應商進行了修複。

　　DLink DIR-1960 除了PROLiNK路由器外，我們還在DIR-1960固件上運行了該工具。這一次，該工具返回了近200個檢測結果。然而，在對結果進行篩查後，發現隻有4個是通過HNAP API的命令注入漏洞（我們已經在前面報告過了），并且所有這些都需要認證。(由此看來，在消除假陽性方面，還有很大的改進空間！)

　　對于HNAP，這裡簡單介紹一下：它是Home Network Administration Protocol的首字母縮寫，它實際上就是一個基于SOAP的協議，用于與路由器管理面闆進行通信。

　　DLink DIR-X1560 接着，我決定也在DIR-X1560固件上試一下這個工具。上面的兩個路由器都是基于MIPS架構的，但DIR-X1560是在ARM處理器上運行的。通過稍加調整，該工具就可以正确地分析基于ARM的固件。由此證明，這個工具具有很好的架構兼容性，這讓我很開心。

　　然而，由于抽象層很多，識别固件上的漏洞并不那麼簡單。有鑒于此，該工具在固件逆向工程中提供了巨大的幫助。我不确定固件所基于的框架的确切名稱，但我設法在GitHub上找到了一些源代碼，這非常有幫助，因為其中含有許多注釋。我在源代碼中找到的最接近的術語是CMS（CPE管理系統）、CPE（客戶駐地設備）和TR-069。但是，請注意，此repo不包含任何特定于dlink的代碼，因此需要執行一些逆向分析。

　　在我看來，它類似于MVC（模型-視圖-控制器）架構，盡管它也可能不是這樣的。

　　關于術語和縮略語的進一步解釋，請參考這裡。

　　DAL（數據聚合層）API，顧名思義，是用來與數據進行交互的，主要是傳遞路由器的配置。但是數據的實際存儲是由MDM（内存數據模式）和ODL（對象調度層）API完成的。DAL使用cmsObj_get和cmsObj_set函數（或其變體）作為與MDM/ODL的接口，以獲取或設置某些對象的值。例如，獲取IP_PING_DIAG MDM對象并将其存儲在ipPingObj中，然後在修改後将其保存回來的代碼如下所示：

　　下面解釋用到的參數：

　　◼MDMOID_DEV2_IP_PING_DIAG：一個枚舉變量，指定訪問IP_PING_DIAG對象。

　　◼iidStack：一些我們不需要關心的内部數據。

　　◼ipPingObj：IP_PING_DIAG對象的内容。

　　除此之外，還有RCL（運行時配置層）和RUT（運行時使用工具）API。每個MDM對象（例如MDMOID_DEV2_IP_PING_DIAG）都有一個相應的RCL處理程序（rcl_dev2IpPingDiagObject）。每次調用cmsObj_set時，ODL都會調用該對象的RCL處理程序，它又會進一步調用RUT的實用工具函數。

　　通過逆向分析，我們發現其工作流程如下所示：

　　1、用戶提出一個POST請求，與HNAP API進行交互（例如SetTimeSettings）。

　　2、HNAP API處理程序調用DAL API（例如：cmsDal_setNtpCfgDLink_dev2）。

　　3、DAL API調用MDM/ODL API（cmsObj_set）來設置MDM對象（例如Dev2TimeDlinkObject）。 例如 cmsObj_set(MDMOID_DEV2_TIME_DLINK, &iidstack, 0, &timeDlinkObj)

　　4、ODL API調用RCL處理程序（例如rcl_dev2TimeDlinkObject）。

　　5、RCL處理程序調用RUT API（例如rut_TZ_Nvram_update）。

　　如果我們查看上面提到的HNAP和RUT函數，我們會看到：

　　經過漫長的旅程，NTPServer參數最終出現在一個傳遞給system的命令中。

　　正如我們在上面看到的，用戶輸入字符串（來自 HNAP）途徑許多函數後，最終到達system調用（在RUT中），從而導緻命令注入漏洞。如果我手動查看固件，除非我很幸運，否則我幾乎要花很長時間才能找到它。然而，在這個工具的幫助下，雖然無法直接實現HNAP到RUT的連接，但至少我能把相關的DAL函數列出來看看，從而節省了我很多時間。

　　DAL和RCL/RUT之間的關系 在這裡，我們進一步考場一下DAL API與RCL/RUT API的關系。其中，cmsDal_setNtpCfgDLink_dev2（如前所述由HNAP API調用的DAL API）的僞代碼如下所示：

　　上面的代碼片段展示了DAL函數設置/更新MDM對象的典型過程。請注意，cmsObj_get是以值為0x416的MDMOID（MDM對象ID）進行調用的。由于沒有源代碼，我隻看到值（0x416），而沒有看到枚舉名稱（MDMOID_DEV2_TIME_DLINK），這些都是從固件中的函數名稱和一些字符串推斷出來的。

　　如前所述，當cmsObj_set被調用時，ODL API将調用相應的RCL處理程序，在這種情況下是rcl_dev2TimeDlinkObject。我沒有研究cmsObj_set的實現細節，因為它相當複雜——需要執行許多檢查和函數調用。如果你有興趣，可以考察這一行，它将調用RCL處理函數。

　　獲得MDMOID和RCL處理程序之間的映射關系并不困難，因為它存儲在固件的OID表中，具體如下所示：

　　在這個表中，我們很容易看出0x416是TimeDlink MDM對象的MDMOID，而rcl_dev2TimeDlinkObject是RCL處理程序。在這裡，我們也看到了一個叫做STL處理程序的東西，但是它并沒有做太多事情。

　　現在，RCL處理程序rcl_dev2TimeDlinkObject看起來像下面這樣：

　　我們看到，newMdmObj被傳遞給易受攻擊的函數rut_TZ_Nvram_update（前面講過）。而這個newMdmObj正是剛才DAL函數傳遞給cmsObj_set的那個timeDlinkObj。所以，DAL和RCL的關系如下圖所示：

　　DAL會為cmsObj_set提供一個MDMOID和一個對象，然後

　　◼MDMOID決定調用哪個RCL處理程序

　　◼該對象被交給RCL處理程序進行處理

　　我們看到，從一個DAL函數中，找出哪個RCL函數被調用并非難事，因為我們不僅有MDMOID，而且還可以參考上面的OID表。但在尋找命令注入漏洞時，步驟就反過來了。

　　首先，通過這個工具，我找到了可能有漏洞的RCL/RUT函數，source點是函數的參數，sink點是system函數（或其變體）。這裡沒有什麼新東西。但是現在，我需要找到訪問相關MDM對象的DAL函數。換句話說，就像上面一樣，雖然我知道MDMOID，但這次，我不是找RCL處理程序，而是回答下面的問題：哪些DAL函數用這個MDMOID調用cmsObj_set？

　　起初，我使用的是一種笨方法：逐一查看cmsObj_set的交叉引用，直到找到一個被調用的MDMOID正确為止。因為這裡的交叉引用太多，足足有200多個，幾分鐘後，我就放棄了。所以，我決定用這個工具來幫助我過濾出使用某個MDMOID的函數。特别是，我隻關心作為字符串/緩沖區的MDM對象字段。如果一個字段保存一個整數值，那麼它對于命令注入或緩沖區溢出其實是沒有用的。

　　回顧一下，一個MDM對象的字符串字段是這樣設置的：

　　所以，我不需要對這個工具做太多的修改，隻需把source點設置為cmsObj_get，把sink點設置為cmsMem_free即可。結果，我成功了。對于每個MDMOID，我過濾出了修改相關MDM對象的幾個DAL函數。然後，我檢查這些DAL函數的交叉引用，看它們是如何被HNAP API調用的，以找出用戶輸入是如何被傳入MDM對象的。 借助于這個工具，工作效率獲得了巨大提升，最後，我成功地在這個固件中找到了4個命令注入漏洞。

　　小結 目前，該工具仍處于開發的初級階段：隻能挖掘命令注入漏洞。此外，在分析像DIR-X1560這樣複雜的固件時，仍然需要做一些手工工作，因為它不能自動判斷出哪些HNAP函數是易受攻擊的。我會繼續對這個工具進行改進，希望有一天它能協助發現其他類型的漏洞，如固件中的緩沖區溢出、UAF等漏洞。

　　最後

　　我整理網絡安全相關的學習資料，有需要的可以關注私我或

　　【網安資料】

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!