如何提取D-Link解密密钥

阅读量    63962 |

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

译者注:直接英译中后语句太过拗口,在不改变原意的情况下做了些许调整

原文:How-To: Extracting Decryption Keys for D-Link

如何提取D-Link解密密钥

当我们在分析固件镜像时,遇到的最常见障碍之一便是加密。虽然已经有一些方法可用于解密固件镜像,但今天我们仍将简要介绍一下,如何提取D-Link部分路由器型号中的加密密钥,特别是D-Link DIR-X1560。该设备与 D-Link DIR-X5460是同一代路由器的一部分,最近,针对该设备,德国流行技术杂志Chip和IoT Inspector联合对其进行了Wi-Fi路由器相关的安全检查。

 

01-D-Link路由器固件加密

D-Link倾向于用自定义的固件更新文件格式,来加密他们的固件镜像。许多DIR系列的D-Link路由器,使用带有SHRS头的固件更新文件格式:

00000000  53 48 52 53 01 13 91 5D 01 13 91 60 67 C6 69 73 SHRS‘]‘`gÆis

这种固件格式及加密方案已经被公开记录。一位名叫0xricksanchez 的研究者,发布了一篇非常棒的writeup,记录了如何发现SHRS固件镜像(包含DIR-3060,我们已经发布了一篇相关advisory)中密钥的过程。他们从imgdecrypt二进制文件中提取出了加密密钥和初始向量IV,此二进制文件可以通过类似系列型号中的URAT shell获得。

然后,最近我们遇到了DIR-X系列的路由器,它们的固件头有一点不同。

00000000  65 6e 63 72 70 74 65 64  5f 69 6d 67 02 0a 00 14  |encrpted_img....|

头部就是一个encrpted_img字符串,然后紧跟其后的是镜像大小字段(32位大端模式)。

SHRS固件镜像的key不适用于这些encrpted_img 镜像,因此我们需要找到另一种方法,将解密密钥从这种加密格式的设备中提取出来。

 

02-密钥在哪里?

显然,我们无法从加密的固件镜像中提取加密密钥,因为它是加密的。所以,我们需要找到另一种方法来获取密钥key。

如果我们能够在设备上以某种方式执行代码,那么就很简单了。如有足够的本地权限,我们可以在设备运行时,访问设备上的所有内容。这是解密后的固件镜像。

如果设备制造商最近才引入固件加密,则可以追踪尚未加密的老版本固件镜像(很可能是引入加密之前的固件版本),并检查是否可以从中提取出密钥key。

直接读取设备的flash内存,是我们可以采用的另一种技术。在flash中固件不太可能被加密。拆开其中一个设备,卸掉flash内存芯片,转储内存后再读取文件系统。但是这样破坏性太太了,设备很昂贵,一旦损坏将大大浪费。

在这里,我们不会深入探讨这些问题,因为其他人已经做过了。关于这个问题Zero Day Initiative有一篇详细的文章,当你在解决固件加密时,可以考虑这个方法。

 

03-Shell中的操作

在我们的例子中,通过UART调试接口可以轻松得到DIR-X1560设备的shell。获取到交互式shell后,就可以轻松dump出整个文件系统。使用内置的busybox tarnc命令可以很容易地做到这一点。首先在设备上设置监听器:

nc –nvlp [PORT] > filesystem.tar.gz

然后在设备上运行以下指令,只写明想要传出的根目录即可。

tar -cvz /bin/ /data/ /etc/ /etc_ro/ /lib/ /libexec/ /mnt/ /opt/ /sbin/ /usr/ /var/ /webs/ | nc [IP ADDRESS] [PORT]

最终,将得到tar.gz压缩文件,包含文件系统中任何你想要的部分,然后通过网络传输出来。

 

04-发现在何处解密

不同于“SHRS”固件镜像,没有明显的imgdecrypt二进制文件可供关注。因此我们可以跟踪固件上传过程,看是否可以定位到在哪里解密。

幸运的是,固件头部的字符串,可以作为独特的关键字,帮助我们在文件系统中找到相关程序。

$ grep -r encrpted_img
Binary file bin/fota matches
Binary file bin/httpd matches
Binary file bin/prog.cgi matches

在此我们找到了两个二进制程序 prog.cgifota,二者可能以某种方式来处理加密过的固件镜像。

progl.cgi中,根据字符串encrypted_img,我们可以很容易的追踪到固件上传的地方。

通过跟随固件被加密部分的指针变量,发现函数FUN00033144被调用,此指针是其第一个参数。

在这个函数内部,出现一个极有可能是固件解密的函数: gj_decode()

 

05-深入库文件

gj_decode()函数被定义在libcmd_util.so文件中,此函数代码不多,但关键的是,其内部调用了两个加密相关的函数: aes_set_keyaes_cbc_decrypt。这两个函数也被定义在上述库文件中,但我们没必要深究这二者。因为它们的函数名已经给予了很多信息:像是CBC模式下的AES加密。

我们可以看到,aes_set_key()的第二个参数可能是AES密钥,而 aes_cbc_decrypt 的第二个参数可能是初始向量IV。

这里的反编译代码有点乱,但不要太在意细节,直接看代码逻辑。有两个do-while循环,将数据从全局变量复制到本地缓冲区,这些循环在全局地址的字节上迭代,直到到达某个特定的结束地址。

key_lockey_loc + 4是指向本地缓冲区的指针变量,第一个循环中,00031ba3地址处的数据拷贝到key_loc+4直到00031bc3地址,而第二个循环,00031bc5地址处的数据拷贝到key_loc直到00031bd5地址(还注意到:这两个本地指针分别是aes_cbc_decrypt()和aes_set_key()的第二个参数)

的确如此,在地址00031ba3处,可见有一个字节数组。

同样在00031bc5地址处,也可见类似的形式。

因此,我们可以假设AES密钥位于 00031ba3,而初始向量IV位于 00031bc5

今天我们在这不会公布真实的密钥,但是那些关注且跟随者应该有能力将密钥提取出来,如他们而言,这是留给有兴趣读者的练习。

 

06-节省时间和脑力

通过使用CyberChef,我们可以快速、轻松地验证假设。大多数情况下,当我想要快速解决密码学相关问题时,我都会打开这个工具。它由英国GCHQ编写,如果对公务员写的东西持怀疑态度,大可不必,它只是用纯JavaScript编写,可以在你想要的任何浏览器中运行。

复制加密固件镜像中的第一个0x1000左右字节的数据,作为16进制的ASCII粘贴到CyberChef输入中,再结合我们提取的密钥和IV,通过CyberChef的“AES Decrypt”操作,就可以得到一个理想的结果。

在这里我们可以看到UBI数据块的头部数据,说明我们正在完全的解密整个固件更新包。

一旦我们知道密钥和IV是有效的,那么很容易就可以编写一个完整的解密脚本。在这种情况下,在我们得到一个完整且正确的镜像之前,还有几个小的问题需要克服,比如数据对齐,但这些都很容易解决。

 

07-结论

在许多情况下,嵌入式设备中的固件被加密并不是一个很难解决的问题。一旦可以获取到物理设备,解密过程就可以大大简化。值得记住的是,嵌入式设备的固件加密主要在固件更新包中实现,而很少在存储级别实现,这一点与移动电话和笔记本电脑的最新实现相反,这二者常见的加密方法是全磁盘(至少是磁盘的重要部分)加密。

这种设置在未来可能会改变,至少是部分改变。例如,Android从4.4开始就支持 全磁盘加密 ,从7.0开始支持基于文件的加密。自Android 10以来,就需要基于文件的加密。然而应该注意的是,术语“完整磁盘”加密在Android中具有误导性,即加密的只是data/userdata分区。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多