这个工具专门用于寻找路由器中的安全漏洞( 四 ) _安全漏洞

文章插图

关于术语和缩略语的进一步解释，请参考这里。
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看起来像下面这样：