看雪论坛
发新帖
12

[原创]DLink路由器固件的一次分析记录

gjden 2016-4-25 16:14 20722
DLink路由器固件的一次分析记录


   一、前言
 
   去年DLink被爆了多个命令注入漏洞,于是我打算分析验证一下这些漏洞,不过在分析过程中有一些意外的收获,通过IDA分析时发现了DLink的多个缓冲区溢出漏洞。但是后来发现这些漏洞在新版本的固件中被修复了,这就意味着这些漏洞已经被厂商知晓并进行了修补。
   虽然DLink犯了很多低级错误导致了一系列本应该避免的漏洞,但是并不意味着其他路由器厂商也不会犯,甚至在各种物联网设备固件中,这类低级编码错误比较普遍。
 
   二、准备
 
   首先找到了两篇分析DLink路由器的文章
   一篇是Craig 的<<Hacking the D-Link DIR-890L>>
   http://www.devttys0.com/2015/04/hacking-the-d-link-dir-890l/
   一篇是360的文章
   http://bobao.360.cn/news/detail/1433.html

   巧合的是作者Craig当天出这篇漏洞细节的文章时,360在同一天得到DLink公司感谢信。不过这两篇讲的都是HNAP协议的命令注入漏洞,我在分析同一版本的时候发现,该HNAP协议还存在多个溢出漏洞,但是当我决定验证一下该漏洞时,才知道该漏洞新固件版本中已经被修复了。最后从网上找到了漏洞通报。

   

   链接:http://www.07net01.com/2015/07/885184.html
 
   另外,我从同事那里借了一台DLink路由器来做测试,该路由器型号为DIR-806
   DLink路由器的正面,有六根天线。

   
 
   背面如下:

   

   首先我需要确认该路由器的固件版本号,这需要登录到路由器上查看。从路由器工具栏下的固件更新项可以看到,固件版本为1.00,固件时间为2013的,那么可以肯定的是该固件也存在我想要验证的漏洞。

   

   因此,该路由器应该会支持该漏洞的测试和验证,但是后来测试该版本似乎会有一点不同,当然漏洞还是差不多,只是字符处理上有一点不同而已。
 
   三、固件分析

   首先我需要得到固件,一种方法是拆开路由器,通过串口、JTag来获取或者直接读flash。不过幸好DLink提供有官网的更新固件。目前我通过如下链接下载了890L_103的固件,更高版本的固件已经修补了该漏洞。
 
ftp://ftp2.dlink.com/PRODUCTS/DIR-890L/REVA/DIR-890L_REVA_FIRMWARE_1.03.B07.ZI
 
   下载固件并解压后,我们得到固件文件DIR890A1_FW103b07.bin,通过binwalk我们可以看到如下信息:
 
   
 
   其中我们可以看到该固件采用的是Squashfs文件系统,那么这好办了,可以直接使用binwalk提取该文件系统。
   binwalk -Me DIR890A1_FW103b07.bin

   

   但是binwalk提取Squashfs文件系统会出问题,它无法解析文件系统数据。

   

   好在他已经把该文件系统数据提取出来,最开始我试图通过unsquashfs来分析该文件系统,但是仍然失败,不过它提示了如下信息:

   

   意思是可以直接用gzip来解压,但在我使用gzip解压时任然有问题,最后通过7z来成功提取出了Dlink的文件系统。如图可以看出这个一个标准的linux文件根目录:

   
 
   首先我需要关注的是一个处理web服务的程序,该程序开启各种服务端口,并且为外部访问提供配置,修改等服务。该文件存在于htdocs目录下:

   

   四、路由服务模块分析

   通过IDA直接打开该文件,可以很清晰的看到该文件通过传入参数处理各种服务,其中 HTTP 和UPnP服务接口在之前的版本中存在命令注入漏洞和信息泄露漏洞,可以参考如下链接:
   http://www.s3cur1ty.de/node/703
   http://www.s3cur1ty.de/node/714
   hnap还有一个命令注入的漏洞,这个漏洞在如下链接中有清晰的表述:
   http://www.devttys0.com/2015/04/hacking-the-d-link-dir-890l/
   此版本我打算分析一下hnap服务的处理,hnap是一种基于 HTTP-SOAP 实现的网络管理协议。DLink使用类似如下的方式来处理该协议命令:
   GET /HNAP1 HTTP/1.1
   Authorization:Basic YWMEHZY+
   Cookie:udi=xyzzzz
   Accept-Encoding: identity
   Soapaction: "http://purenetworks.com/HNAP1/GetDeviceSettings"
   Host: 192.168.0.1:80
   Connection: close

 
   HTTP协议中使用了Soapaction来处理hnap请求
   首先,通过IDA反汇编后,可以在主函数中很快的找到该服务的handler函数。

   

   如果你和我的版本相同的话,可以直接根据地址定位到此处。Ok,接下来进入该handler看看。

   

   从代码中可以看出,该服务文件通过获取环境变量来得到HTTP头部相关信息,我们直接F5来看更加明了

   

   从这里可发现环境变量"HTTP_SOAPACTION"就是用来获取hnap请求命令的。Dlink接下来通过strstr来进行过滤,如果我们hnap请求里不包含字符串

   "http://purenetworks.com/HNAP1/GetDeviceSettings"

   那么会试图进行登录请求处理

   http://purenetworks.com/HNAP1/Login

   登录处理会获取cookie相关的参数并进行处理,从我分析的结果来看,好像没有发现什么。

   

   如果既不是hnap请求,也不是登录请求,那么程序会将"HTTP_COOKIE"、"HTTP_HNAP_AUTH"、"HTTP_SOAPACTION"这三个环境变量的值传入函数sub_19BB8.如下图所示:

   

   接下来,我进入到该函数进行仔细分析。这个函数的三个参数都是我们可以控制的,所以如果函数里面存在问题,那么就有戏了。当我进入该函数一看,吓了一跳,这一个函数不止一个漏洞。该函数首先需要保证cookie和auth不能为空,并且cookie必须存在”uid=”的字符串才能够继续执行。否则会直接返回。因此要构造poc,如下显蓝色标记的是必须的。

   GET /HNAP1 HTTP/1.1
   Authorization:Basic YWMEHZY+
   Cookie:udi=xyzzzz
   Accept-Encoding: identity
   Soapaction: "http://purenetworks.com/HNAP1/GetDeviceSettings"
   Host: 192.168.0.1:80
   Connection: close


   那么通过如下分析你可以构造自己poc来触发这些漏洞。

   1.首先是auth参数的处理,此参数处理直接使用strtok()函数来分割,分割通过空格来实现。
 
   

   R2中存储的目的地址,该地址为堆栈地址,其堆栈空间长度固定为512个字节,看到这里就你可以邪恶的一笑了。
   我们只需要构造一个字符串,将该字符串以构造为如下:

   Authorization:Basic YWMEHZY+0Xaa{800}

   然后通过python脚本将构造的请求包提交给路由器,我们就能看到该路由器崩溃的效果。
 
   2.然后是hnap命令的处理问题,该函数处理hnap命令字符串时,同样没有进行长度验证,通过strcat函数将hnap命令字符串连接到同样一个缓冲中。

   

   看到了吧,又是一个缓冲区溢出。
 
   3.这还没有完,该函数除了将分割的第二个字符串无限制的拷贝到堆栈外,当cookie的uid有效时,他还会将其拷贝到堆栈的另外一个缓冲区里
   首先将该字符串通过atoi()函数进行转换,得到一个整数,然后将该整数与堆栈中的一个值进行比较,如果比这个值大,则会将其通过函数strcpy拷贝到堆栈中。我们知道atoi函数对于诸如此类的字符串:
   “12aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”
   同样会成功的返回12,那么我们可以构造一个255开头的长字符串来触发溢出。

   

   当然该函数可能还有其他地方会出现异常和漏洞,但是我的分析也在此处完结了,剩余的时间就是去验证一下漏洞了。
上传的附件:
本主题帖已收到 0 次赞赏,累计¥0.00
最新回复 (33)
qqsunqiang 2016-4-25 16:59
2
谢谢楼主,没人回啊。
fishleong 2016-4-25 17:24
3
先记一下,硬件不懂
川美 2016-4-25 22:10
4
不是很熟悉这一块,期待交流
6
shayi 2016-4-26 00:08
5
很好的一篇文章,看起来多数家用路由器的固件也是基于 linux 内核,它在现今各种嵌入式系统领域大行其道。
关于协议处理函数中,解析请求头中各字段的逻辑的反编译很直观,一目了然。
基本上又是字符串复制操作时,没有检查边界惹的祸;C 运行库中已经有那么多安全的字符串操作函数,偏偏要用 strcpy() ,好歹用个 strncpy() 也要安全一些吧
IDA 的强大在此体现:不管是 pe,elf,coff ,a.out 格式,还是原始的二进制文件(cgibin ?),没有明确定义的格式规范,都一律通吃!
天高 2016-4-26 00:13
6
mark
佐须之男 2016-4-26 02:32
7
很不错的文章,赞一个!
4
ycmint 2016-4-26 09:39
8
之前也写过一个 ,有时间放出来.....
12
gjden 2016-4-26 10:08
9
期待你的分析文...
1
beiyu 2016-4-26 11:52
10
期待你放出来分享。
2
pxhb 2016-4-26 12:19
11
长见识了,感谢分享
guobing 2016-4-27 18:10
12
来个自动化提取,FirmwareModKit,其实也是调用(binwalk),不用一步一步的搞了。
看着汇编是arm平台的呀,看到mips汇编都头疼。
12
gjden 2016-4-27 21:47
13
如果只是提取文件系统的话,binwalk用起来更灵活些,FirmwareModKit有时候会出莫名其妙的问题,不过FirmwareModKit用来重打包固件会很不错。
广岛秋泽 2016-4-28 19:54
14
so cool
alargel 2016-5-9 08:31
15
看了,顶!
好文!
scenic 2016-5-9 11:40
16
分析的不错
skywood 2016-5-9 15:17
17
感谢楼主的干货
1
飘云 2016-5-10 18:35
18
额,这个型号是arm平台? 入手个玩玩看~~
11
Netfairy 2016-5-12 23:24
19
这个 必须顶
太牛了
LOVEZ 2016-5-13 08:44
20
很详细 感谢分享
huluxia 2016-5-13 08:46
21
顶了!!
学习软件 2016-5-25 14:08
22
好文好文
1
dogudong 2016-8-9 10:13
23
擦,,正在分析dlink,谷歌了下purenetworks.com/HNAP1/Login找到这里了。希望不要撞洞啊
gowabby 2016-8-11 15:14
24
好赞,写的好细,刚准入收路由器测试
supertyj 2016-8-23 15:51
25
这东西不好用,很多解不开的,还得手动。
1
xdxdxdxd 2016-9-14 10:29
26
mips架构也有F5 需要啥版本?
2
Keoyo 2016-9-14 11:35
27
好文啊!大赞!!!
ID蝴蝶 2016-10-13 16:58
28
前辈您好,对于固件文件格式,其他的怎么办?例如CramFS文件格式,直接binwalk和7z提取的都有问题,7z在提取是提示有额外数据。我分析的这个固件是摄像头的,.dav格式的。
12
gjden 2016-10-14 17:02
29
很多dav格式的固件用binwalk的确无法抽取完整的文件系统,但是用递归抽取应该会提取出很多东西,具体看依据厂商而定了。
1
dalerkd 2016-10-14 20:54
30
文件系统分析mark,感谢分享(❁´ω`❁)
ID蝴蝶 2016-10-14 21:03
31
还望大牛明示,我也好找到地方使劲啊。谢谢大牛指点。
Da明星 2017-6-12 10:42
32

unsquashfs 160090.squashfs 报错如下

Parallel unsquashfs: Using 2 processors

lzma uncompress failed with error code 0

read_block: failed to read block @0x5dffc2

read_fragment_table: failed to read fragment table index

FATAL ERROR:failed to read fragment table


simpe 2017-7-24 13:12
33
楼主,平时怼路由器都是  实体吗?会不会先用qemu模拟啊?我想先模拟  调试调试漏洞  再上实体,但是对模拟路由器不太会,不知道楼主能不能指点一下
12
gjden 2017-7-24 14:50
35
simpe 楼主,平时怼路由器都是 实体吗?会不会先用qemu模拟啊?我想先模拟 调试调试漏洞 再上实体,但是对模拟路由器不太会,不知道楼主能不能指点一下
模拟可以用firmadyne
返回



©2000-2017 看雪学院 | Based on Xiuno BBS | 微信公众号:ikanxue
Time: 0.016, SQL: 12 / 京ICP备10040895号-17