IoT设备常见Web Server漏洞挖掘思路分析

在IoT小设备中由于运行资源（CPU、存储、内存等）受限，通常会使用轻量级的 Web server，例如uHTTPd、lighttpd、micro_httpd、mini_httpd、GoAhead、boa等，其中uHTTPd、lighttpd此类Web server通常不会由开发者修改源码新增功能代码，而是纯粹作为一个类似流量转发的框架；而micro_httpd、mini_httpd、GoAhead、boa此类通常是由开发者将一些业务代码集成到Web server中，导致在server代码中产生漏洞的概率增大。

本文由于篇幅原因，仅仅针对IoT小设备（光猫、路由器、摄像头等）中常见的两个开源Web server框架GoAhead和mini_httpd，分别从源码处理数据、漏洞存在点、经典CVE漏洞分析这三个方面，浅析其漏洞挖掘思路。

本文不会完全分析Web server代码实现、架构，而是聚焦于安全研究较为关注、通常由开发者实现的数据包处理部分。文章的大概阐述思路如下：

1. 首先结合源码说明数据包处理特性，主要涉及鉴权、路由处理；

2. 简述数据包处理中可能存在的漏洞点；

3. 结合经典漏洞进行分析。

GoAhead是一个轻量化、适用于嵌入式设备的Web server，采用C语言编写，代码量不大，具有高度的可移植性和扩展性。GoAhead支持多进程、多线程，能够处理大量的并发连接，支持SSL/TLS加密和基本的身份认证，支持CGI、ASP，满足了绝大部分的Web server业务场景。

GoAhead由Embedthis Software LLC开发，早年间是完全开源的，可以直接在Github上下载到源码。但是在2022年的时候，似乎转为了商业定制，官方在Github删除了代码库，因此在Github上无法下载，但是在Gitee上还有镜像库。下载地址：GoAhead: GoAhead WebServer。

在D-Link的主流路由器中，例如DIR系列，很多使用了GoAhead作为Web Server；除此之外还有Tenda、NETGEAR、BEC等许多厂家都有在其设备中使用GoAhead。

GoAhead会对数据包按照优先级进行顺序处理，处理方式是通过注册的回调函数：

• 优先级为1注册的回调函数：所有数据包都需要首先经过该回调函数进行处理，此处也通常被用来做数据包鉴权、请求路径合法性判断、未授权访问路径定义等等；

• 优先级为0注册的回调函数：通常用来定义认证后可访问到的接口逻辑实现；

• 优先级为2注册的回调函数：处理没有匹配到注册路径的数据包，也就是非法路径的数据包。

重要的参数：

• char_t *urlPrefix：指定URL的前缀，也就是需要处理的URL开头部分；

• int (*handler)：URL对应的回调函数；

• int flags：URL处理优先级标志，有如下的两个选择：

• #define WEBS_HANDLER_FIRST 0x1：所有的数据包都会通过该回调函数进行处理；

• #define WEBS_HANDLER_LAST 0x2：没有回调函数匹配的数据包会通过该回调函数进行处理。

如下是一个设备DIR-878，固件版本1.02B02中的GoAhead反编译代码，可以看到GoAhead对于数据包是否已经通过认证，是通过注册一个flags=WEBS_HANDLER_FIRST=1的回调函数websSecurityHandler来进行验证的，这意味着所有的数据包都会通过函数websSecurityHandler进行处理，验证数据包发送者的权限。

例如对一个请求的完整处理过程：使用POST请求访问/HNAP1/

1. 首先数据包会进入函数webAuthHandler：请求路径鉴权、请求路径合法性判断等

2. 根据一层路径/HNAP1/，匹配回调函数websFormHandler：

3. 然后在回调函数websFormHandler进行进一步的业务代码处理。

对于GoAhead的漏洞挖掘，一般的思路是：

1. 根据关键字符串定位到GoAhead的版本，看是否收到历史漏洞的影响，其中CVE-2017-17562和CVE-2021-42342都是发生在由于对CGI环境变量处理不当导致的远程代码执行；

2. 分析路径鉴权模块，例如websUrlHandlerDefine中对路径鉴权是否存在绕过、缓冲区溢出；

3. 分析其他路径定义函数，看路径的回调函数中参数处理是否存在漏洞。

根据笔者对GoAhead的处理经验，其一般都存在认证后相关的命令注入、缓冲区溢出等常见漏洞，但GoAhead的鉴权是一个比较难绕过的点，使用的鉴权方式越简单、额外判定越少，越难绕过。

案例1：GoAhead环境变量注入漏洞（CVE-2017-17562）

Goahead的版本号确定，可以通过搜索字符串GoAhead-Webs，可以确定版本，从而判断是否受到历史漏洞的影响。

版本字符串定位

漏洞发生的本质是因为使用了不可信任的HTTP请求参数作为初始化CGI脚本的环境变量。GoAhead调用CGI之前，会使用函数cgiHandler将用户提交的参数存入环境变量数组envp中，并只使用了简单的黑名单过滤REMOTE_HOST和HTTP_AUTHORIZATION两个环境变量。CVE-2021-42342是对补丁的绕过，此处不再详细阐述。

对于此漏洞的利用，先补充下CGI调用的相关基础知识。Web server为了增加自身数据处理的可扩展性，会采用CGI（Common Gateway Interface，通用网关接口）标准启动外部程序处理用户的请求，并将外部程序处理数据的结果通过Web server返回给用户。Web server会将用户提交的数据通过环境变量和标准输入传递给程序，程序执行完毕之后通过标准输出传递给Web server，然后Web server再返回给用户。

因此，针对该漏洞的一种利用方式就是通过POST请求头设置环境变量LD_PRELOAD为CGI程序自身的标准输入（即POST请求体），CGI程序运行时就会自动加载请求体中构造的动态链接库。

如下，先定义一个构造函数，该函数会先于CGI程序的main函数被调用。

使用如下命令构造出动态链接库，使用cat命令测试，的确能够运行。

然后使用curl构造POC如下，发送请求后可以看到的确执行了动态链接库中的函数并输出结果。此处对POC简单解释下，GoAhead调用CGI程序前，会对CGI程序的环境变量和标准输入进行设置。data-binary参数是将payload.so作为CGI程序的标准输入；LD_PRELOAD=/proc/self/fd/0，则是让CGI程序在运行时从自身的标准输入加载动态链接库，也就是POST请求体中传入的payload.so。

案例2：发生在websSecurityHandler中的认证绕过（CVE-2020-15633）

设备采用lighttpd作为Web server，根据配置会将HNAP请求转发到程序/bin/prog.cgi进行处理，prog.cgi是基于GoAhead开发。在文章开头提到过使用lighttpd作为Web server，将流量根据业务场景通过规则进行转发，此处就是一个典型的示例：将所有HNAP1相关的流量使用fastcgi转发到了/bin/prog.cgi中进行处理，这样使得架构更加模块化、处理逻辑更清晰。

漏洞触发过程的函数调用如下：

1. 在函数sub_423ECC中，会使用函数strstr比较环境变量REQUEST_URI（也就是请求路径）中是否含有字符串列表actions_list中的字符串，然后触发到return 0；

actions_list中的字符串表如下：

2. 然后返回到函数sub_4249EC，触发该函数继续返回0；

3. 再返回到函数websSecurityHandler中，使得该认证函数返回0，达到认证绕过；

综上所述，对于路由/HNAP1/，只需要在uri后添加?GetCAPTCHAsetting或者任意其他字符串列表的中字符串，就可以达到认证绕过访问该接口的目的，参考POC如下：

案例3：发生在函数websSecurityHandler中的认证绕过（CVE-2020-8864）

此处同样采用固件版本为1.10B02的D-Link DIR 878中的prog.cgi对漏洞进行分析。触发漏洞的函数调用路径如下，比上一个漏洞深入了一层函数调用。

在函数sub_423304中会根据请求参数调用不同的函数，当action=login的时候，进入函数hnap_login进行认证处理。

函数hnap_login是寻常的账号、密码验证流程，大概简化的流程就是先从请求中获取账号、密码，然后比较账号是否为Admin/admin，先获取密码长度然后调用strncmp比较密码是否正确。但是如果输入密码为空则会导致strncmp比较通过。

参考POC构造如下：

其他漏洞

GoAhead中由于很多业务代码是通过定义接口+回调函数的形式集成到自身，代码量增多导致发生漏洞的可能增大，如下是一些典型的GoAhead认证后漏洞，包含常见的漏洞缓冲区溢出、命令执行。

• CVE-2021-43474：D-Link DIR 823G中的认证后命令注入

• CVE-2020-10987：Tenda AC15中的认证后命令执行

• CVE-2018-11013：D-Link DIR 816A2中的认证后缓冲区溢出

mini_httpd是一个小型的HTTP服务器，它的代码非常小巧，仅有几千行代码，其可以在多种操作系统上运行，包括Linux、FreeBSD、Solaris、Windows等。mini_httpd支持动态内容的生成，包括CGI、SSI以及FastCGI，同时它也支持虚拟主机和基本的身份验证，这满足了绝大部分的IoT Web server应用场景，结合其小体量的代码，被广泛应用于嵌入式设备和低功耗系统中。

mini_httpd的代码下载地址：mini_httpd，目前在NETGEAR的路由器中常见mini_httpd作为Web server。

mini_httpd收到一个数据请求包后会fork创建一个子进程来进行处理，这种方式如果在高并发场景会在进程创建、销毁过程中消耗大量的资源，但是在并发量低的嵌入式设备已经够用了。

子进程中主要是通过handle_request函数来对数据进行处理的，主要是先解析请求行、再解析请求头。

• 读取请求的第一行，获取到请求行，然后从行中解析到请求方法protocol、请求路径path和查询参数query；

• 随后解析header，主要实现是通过while循环继续逐行解析header中的字段，包括Authorization、Content-Length、Content-Type、Cookie、User-Agent等等常见的字段。

如下是handle_request函数中读取请求行，获取到请求method_str、path、query、protocol。

然后是while循环处理header，获取字段。在源码中包括：Authorization、Content-Length、Content-Type、Cookie、Host、If-Modified-Since、Referer、Referrer、User-Agent这些字段。

获取到了如上的重要字段后，就开始对数据包的合法性进行判断，例如：

• 请求方法method是否合理：GET、HEAD、POST、PUT、DELETE、TRACE；

• 请求路径path必须以反斜杠/开头、对path进行目录穿越相关字符进行处理、检查文件是否存在；

• 然后根据path是文件夹或文件，分别调用do_dir和do_file进行处理，二者最终都会进行权限检查函数auth_check。

在权限检查函数auth_check中，输入为请求的path转换的实际路径file所在的文件夹dirname，如果权限检查通过，则继续直接随后的数据包处理流程；如果权限检查是否，则通过send_authenticate函数返回401，然后结束当前连接的生命周期。

权限检查的流程则是：

1. 如果dirname中没有.htpasswd文件，那么直接认证通过。就相当于是在需要授权访问的文件夹中添加该文件，不需要授权访问的文件夹中没有该文件；

2. 源码中采用的校验方式是BASIC认证，请求包中带上username和base64编码的password，然后和.htpasswd文件中保存的账号信息进行对比，如果比较通过则直接返回。

因此，平常漏洞挖掘中比较关心的登录认证流程就非常清晰：main -> handle_request -> do_file/do_dir -> auth_check。一般情况下，厂商会根据自己的业务逻辑修改相关的函数，但是根据源码我们还是能通过一些字符串特征来定位到关键函数，例如：

• 通过搜索index相关的页面字符串，可以定位到handle_request；

• 函数handle_request中的逻辑是由开发者定义，因此可能发生缓冲区溢出、命令注入等常见漏洞形式；

• 通过搜索字符串.htpasswd可以直接定位到do_file、auth_check函数。do_file函数中会检查请求文件是否为.htpasswd，auth_check函数则是需要读取账号信息、调用字符串比较函数等。

除此之外，mini_httpd 1.30之前的版本存在一个任意文件读取漏洞CVE-2018-18778，当设备开启虚拟主机模式的时候，可以通过构造空的HOST请求头和想要读取的文件作为请求资源，便能任意文件读取，随后将从源码简单分析漏洞原理。

总之，mini_httpd主要容易发生漏洞的地方就是在处理数据包的函数handle_request处，因为此处是开发者主要添加自己代码的地方，例如对header的处理、认证的自我实现方式等等。

漏洞发生在数据包处理函数handle_request中。当处理完毕请求头后，获取到请求文件path，并根据请求文件path构造实际在磁盘中的文件路径file。

当设备开启虚拟主机模式的情况下，调用函数virtual_file进行处理。该函数中使用了snprintf构造路径，而且没有对参数f进行校验，因此当req_home如果等于空，那么就相当于直接访问请求文件路径f了。

此处补充下关于虚拟主机相关的概念。虚拟主机（Virtual Hosting）模式是Web服务器配置的一种方式，它允许服务器在同一物理服务器上托管多个网站域名。

在虚拟主机模式下，Web服务器在收到HTTP请求时会检查请求的Host头部，根据这个头部确定请求意图访问的是哪个虚拟主机。也就是说，攻击者可以向存在漏洞的mini_httpd发送HOST为空的请求头，并将想要读取的文件放在请求行的路径中，如下：

在mini_httpd 1.30版本中，对该漏洞进行了修补，大概就是在函数handle_request处理请求头的时候对HOST新增了一个检查，检查HOST是否为空，如果为空则同样返回400错误。

案例2：发生在函数auth_check中的认证绕过（CVE-2021-35973）

通过之前的源代码梳理，也明白了mini_httpd的登录认证流程，那么可以通过搜索字符串的技巧直接定位到auth_check函数。auth_check函数开头有一段导致后续认证绕过的逻辑，其中有一个g_bypass_flag=1时可以直接通过认证。

查看变量g_bypass_flag的交叉引用，赋值的地方一共包含如下的三处：

1. 当请求path中包含currentsetting.htm的时候；

2. SOAPAction相关，设计的初衷应该是可以访问任意SOAP的xml；

3. 请求path中包含setupwizard.cgi，但是随后的处理逻辑会调用exit退出，因此无法利用。这个可能是当设备首次启动、开始安装向导触发的。

再次返回到mini_httpd的源代码中，结合固件中的反汇编

• 首先通过查找method后的第一个空格、换行、制表符的方式，获取到path。但是随后没有对path中是否包含%00进行判断；

• 获取到的path在内存中大概是：uricurrentsetting.htm，这导致，strstr函数返回一个非空值，就设置了g_bypass_flag，从而通过了auth_check。

案例3：发生在函数handle_request（CVE-2021-34979）

越界写：发生在处理数据包的函数handle_request中，未判断边界。

后续调用setupwizard.cgi时，环境变量会传入，并且造成缓冲区溢出。

本文选取了GoAhead和mini_httpd两个IoT小设备中常见的Web server，结合源代码和经典CVE对其漏洞挖掘思路进行浅析。但是实际的漏洞挖掘过程中，可能开发者会对Web server的代码结合实际业务场景进行较大的改动，本文的浅显思路仅仅作为简单参考。

本文的漏洞示例基本上都是分析了server自身存在的漏洞以及认证时可能存在的漏洞，因为认证后相关的漏洞和设备的具体业务代码相关，和server原生的代码结构相关行不高。

回想刚开始挖小设备漏洞的时候，都是先找一些关键字符串、然后交叉引用找调用函数、调用函数再一层层交叉引用查看，这个逻辑对于找认证后漏洞没问题，但是如果想要找到认证前相关的漏洞，就要对server自身的代码结构有一定的了解，这样才能快速、精确定位到可能的漏洞点处。

进一步展开的话，对于GoAhead、mini_httpd此类集成业务代码的Web server，分析其数据包处理流程、鉴权处理流程对于漏洞自动化挖掘也是非常有帮助的，例如：

• 当开发者去除掉server的函数符号时，我们也可以根据函数调用图特征、关键字符串特征等快速判定具体是哪个开源server、版本是什么，进一步找到源代码为逆向分析提供帮助；

• 在静态分析的时候，确定好数据包的source点、鉴权函数路径、可能存在漏洞的sink点，通过污点快播快速判断指定Web server是否可能存在认证前的某些漏洞。

本作品著作权归OneShell所有

未经作者同意，不得转载