如何快速挖掘设备逻辑洞

前言

接触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。

链接

项目地址：https://github.com/fxc233/fdcalls