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

IoT 1周前 admin
54 0 0

前  言

在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篇

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。

01

数据包处理逻辑


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

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

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

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

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

重要的参数:

  • 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进行处理,验证数据包发送者的权限。

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

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

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

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

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

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

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

02

漏洞挖掘思路


对于GoAhead的漏洞挖掘,一般的思路是:

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

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

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


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

03

案例分析


案例1:GoAhead环境变量注入漏洞(CVE-2017-17562)

CVE-2017-17562是发生在版本3.6.5之前的远程代码执行,当CGI功能被启用且采用了动态so加载,由于处理环境变量时直接将请求参数键值对设置并传递到CGI,如果使用了LD_PRELOAD,使用POST请求方式可以将代码通过标准输入传递到CGI的/proc/self/fd/0,然后导致远程代码执行。


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


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

版本字符串定位


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

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

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


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


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

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

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

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

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

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


案例2:发生在websSecurityHandler中的认证绕过(CVE-2020-15633)

该漏洞是发生在LAN口的一个登录认证绕过漏洞,影响设备DIR-867、DIR-878、DIR-882,固件版本1.20B10_BETA。漏洞产生的原因是在处理HNAP请求的过程中,验证用户登录逻辑时处理不当,使用strstr函数来检查无需验证权限的接口,导致可以构造特定URI来绕过身份认证,从而访问敏感接口。


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

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

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

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

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

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

actions_list中的字符串表如下:

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

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


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

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

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

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


案例3:发生在函数websSecurityHandler中的认证绕过(CVE-2020-8864)

CVE-2020-8864是发生在固件版本为 1.10B04 的 D-Link DIR-867、DIR-878 和 DIR-882 路由器的认证绕过漏洞。该漏洞是由于HNAP请求中处理登录密码时缺乏对空密码的正确处理而导致的,攻击者可以利用该漏洞进行命令执行。


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

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

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

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

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

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

参考POC构造如下:

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


其他漏洞

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

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

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

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


mini_httpd篇

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


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

01

数据包处理逻辑


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

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

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

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

  • 随后解析header,主要实现是通过while循环继续逐行解析header中的字段,包括AuthorizationContent-LengthContent-TypeCookieUser-Agent等等常见的字段。


如下是handle_request函数中读取请求行,获取到请求method_strpathqueryprotocol

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

然后是while循环处理header,获取字段。在源码中包括:AuthorizationContent-LengthContent-TypeCookieHostIf-Modified-SinceRefererReferrerUser-Agent这些字段。

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

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

  • 请求方法method是否合理:GETHEADPOSTPUTDELETETRACE

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

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


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


权限检查的流程则是:

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

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

02

漏洞挖掘思路


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

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

IoT设备常见Web Server漏洞挖掘思路分析
  • 函数handle_request中的逻辑是由开发者定义,因此可能发生缓冲区溢出、命令注入等常见漏洞形式;

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


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


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

03

案例分析


案例1:mini_httpd任意文件读取漏洞(CVE-2018-18778)

CVE-2018-18778是mini_httpd自身的一个任意文件读取漏洞,1.30(最新版本)之前的版本都会收到影响。在mini_httpd开启虚拟主机模式的情况下,用户请求http://HOST/FILE将会访问到当前目录下的HOST/FILE文件。


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

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

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

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

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


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

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

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

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


案例2:发生在函数auth_check中的认证绕过(CVE-2021-35973)

发生在netgear wac104设备、固件版本1.0.4.15之前的身份认证绕过漏洞,漏洞产生的原因是在鉴权过程中,使用了strstr来判断:如果请求uri中包含currentsetting.htm,设置无需认证标志。因此攻击者可以在需要鉴权的uri中包含currentsetting.htm标志,从而达到认证绕过的目的。


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

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

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

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

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

2. SOAPAction相关,设计的初衷应该是可以访问任意SOAPxml

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

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

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

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

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

IoT设备常见Web Server漏洞挖掘思路分析
  • 获取到的path在内存中大概是:uricurrentsetting.htm,这导致,strstr函数返回一个非空值,就设置了g_bypass_flag,从而通过了auth_check

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


案例3:发生在函数handle_request(CVE-2021-34979)

发生在NETGEAR R6260,固件版本V1.1.0.78_1.0.1中,处理SOAPAction标头由于未判断全局数组spapServiceName的边界,导致越界写。写入的数据会以环境变量的形式传递到setupwizard.cgi中,进而造成缓冲区溢出。


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

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

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

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

总  结

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


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


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


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

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

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






【版权说明】

本作品著作权归OneShell所有

未经作者同意,不得转载

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

OneShell


天工实验室安全研究员

专注于 IOT 设备的漏洞挖掘和利用。


往期回顾

01
探索 D-Bus 跨进程消息传递中的安全风险
02
Windows Hypervisor & 内核调试的几种常见/不常见方法
03
FortiGate SSLVPN CVE-2024-21762漏洞利用分析
04
Ghidra脚本编写:从IR到反编译C


IoT设备常见Web Server漏洞挖掘思路分析
每周三更新一篇技术文章  点击关注我们吧!

原文始发于微信公众号(破壳平台):IoT设备常见Web Server漏洞挖掘思路分析

版权声明:admin 发表于 2024年4月3日 上午11:31。
转载请注明:IoT设备常见Web Server漏洞挖掘思路分析 | CTF导航

相关文章