前言
接觸iot也快有一年的時間了，一年來也挖掘了大大小小几十個洞，雖然能有些產出但是卻逐漸對人工審計感到無趣和疲憊。在此之間我也嘗試過透過使用汙點分析，fuzz等方法去進行自動化漏洞挖掘，但總因為目標不明確而導致挖掘效果不是很好。於是就產生了寫一款可以用來輔助跨檔案分析危險函式的工具的想法，正好最近在看到https://conference.hitb.org/hitbsecconf2023ams/materials/D1T1%20-%20Your%20Not%20So%20Home%20Office%20-%20Soho%20Hacking%20at%20Pwn2Own%20-%20McCaulay%20Hudson%20&%20Alex%20Plaskett.pdf時，看到了文章中dcalls這個工具。他的效果可以很好地滿足我之前的想法，但是這款工具貌似並沒有開源，於是我就自己嘗試去實現了一下這個工具。寫完之後感覺效果還行（但是由於時間匆忙，筆者能力有限等原因，此工具也存在很多bug，希望師傅們海涵），又恰好想起了當時自己剛入門iot，還不怎麼清楚如何進行漏洞挖掘時，不知從何下手卻又著急想要出一些成果的場景。於是寫下這篇文章，分享給剛入門，並且希望能快速挖掘到漏洞的師傅。
最常見的邏輯洞
在我看來，在一些中小型廠商的裝置中，最常見的邏輯洞應該是命令注入了。不僅exp簡單，並且危害大，經常可以很容易實現rce。想要快速尋找到命令注入漏洞，可以從一些危險函式下手，看看這些危險函式的引數是否可以被我們使用者控制。常見的危險函式如system，execve等。但是很多廠商會在自定義的動態連結庫中定義自己的函式，並且在其內部呼叫這些危險函式。往往這些函式是最有可能被我們忽略掉的，如果在審計時可以注意到這些函式那我們挖掘到漏洞的機率也就會大大提高了。
如何快速進行漏洞挖掘
fdcalls是我編寫的一款用來輔助我們尋找危險函式呼叫以及可能的危險函式的一款工具，已在github上開源（https://github.com/fxc233/fdcalls）。
接著我們就來看一下如何使用這個工具快速的發現可能的漏洞點，以及可能存在的危險函式。這款工具分為兩個模式，第一個模式僅匹配目標檔案可能存在命令注入漏洞的地方，並且返回漏洞點及危險函式呼叫鏈。如下圖，此時我們就可以去顯示的地址對是否存在漏洞做進一步的判斷。當然由於時間問題，我並沒有嘗試測過很多不同廠商的裝置，這就導致可能會在執行指令碼時多出一些錯誤資訊的提示，但是隻要指令碼不是中斷報錯，那麼就還是可以正常進行分析的。當然顯示出來的路徑也可能會存在誤報的現象。
第二個模式會顯示所有可能的危險函式。加上這個模式的原因是，因為筆者的能力有限，所以一些函式呼叫處可能處理的不是很好，故有一些危險函式雖然會被會被呼叫卻沒能在上面的路徑當中顯示出來。如下圖所示，我們可以看到可能存在的危險函式以及定義他們的動態連結庫。我們在模式以掃描出的路徑中不能發現漏洞或者掃描不出路徑時，可以去二進位制檔案中搜尋這些函式名，如果函式存在那麼也有存在漏洞的可能。
實戰應用
筆者這裡就拿在github上看到某個的今年新出的cve（https://github.com/kagehutatsu/IOT_Vulnerability/tree/main/LB-Link/WR450H/CVE-2023-26697），來看一下這個工具效果。看漏洞提交報告可知，漏洞函式是./lib/libshare-0.0.26.so裡的定義的bs_SetForwardingInfo。
我們分析的二進位制檔案是./bin/goahead，嘗試直接用工具掃描試試。
很可惜我們並沒能直接定位到漏洞函式呼叫的位置，不過好在我們能識別到存在這個危險函式，對我們漏洞挖掘還是能有一定的幫助的。
結語
祝各位師傅每天都能挖到新的0day。最後如果有師傅在使用這個工具是出現了bug，歡迎師傅們在github上提issue。