加密解密

关注公众号 jb51net

关闭
网络安全 > 加密解密 >

针对Linux系统全盘加密的启动攻击

脚本之家

攻击

由于市面上没有现成的工具能够执行这种攻击,所以我们自己制作了工具,并把它命名为EvilAbigail。Evil maid攻击可以针对任何操作系统。此次的研究我们针对的是使用LUKS全盘加密的Linux系统。

一般来说,当Linux系统使用了全盘加密后,会由一小块分区还是没有加密,这个区域就是用来解密和引导加密磁盘的。这个分区会挂载在/boot,并且包含内核和初始RAM磁盘(initrd)。虽然攻击内核或者bootloader也是可行的,但是我们还是针对initrd进行了攻击。

initrd是指一个临时文件系统,它在启动阶段被Linux内核调用。initrd主要用于当root文件系统被挂载之前,进行准备工作。initrd 中包含了是解密和挂载root文件系统所需要的目录和可执行程序的最小集合。一旦initrd任务完成,它就会执行pivot_root,从而将initrd根文件系统卸载掉,并挂载真正的根文件系统。

一般来说,initrd是一个通过gzip压缩的cpio镜像。我们测试的基于Debian的操作系统是这样,但基于RedHat的操作系统 (Fedora, RHEL, CentOS)现在使用的是dracut,包含一个未压缩的cpio镜像。基于Debian的initrds 会用ash shell脚本执行启动,而dracut则会用systemd和它所关联的配置方法。

为了执行我们的攻击,我们选择使用一个基于LD_PRELOAD的bootkit,但是其实也可以注入恶意的内核或可执行文件中。我们使用LD_PRELOAD的主要目标是对刚刚解密完成的root文件系统中的第一个可执行文件注入一个共享对象。第一个可执行文件通常是/sbin/init,PID一般会是1。进行攻击最简单的方法就是修改init脚本,导出这个环境变量,这样执行pivot_root的时候环境变量就设置好了。因为当文件系统更改的时候还得在合适的时候(解密之后)把共享对象复制到新系统中。把以下这两行放入initrd的init脚本中,插在切换文件系统之前:

cp /hack.so /${rootmnt}/hack.so
export LD_PRELOAD=/hack.so

之所以这样可行是因为真正的root文件系统是在临时root文件系统下解密挂载的,这先于pivot,并且rootmnt变量是用挂载点位置填充的。但是,在这之前需要把目标文件系统重新挂载成读写,因为默认是只读的。在我们的例子中我们对init脚本进行了修改,修改了脚本分析内核命令行的地方,因此无论提供的参数是什么,root文件系统都是读写方式挂载。另一种方法是在注入的命令中添加mount -o remount,rw /${rootmnt}。

不过基于dracut的initrds中不存在注入点,因为init的可执行文件是个二进制文件而非shell脚本。这就给我们带来了三个问题,只有克服了这三个问题我们才能够注入到pid 1进程中。

三个问题

第一个问题是有关复制我们的二进制文件到解密的root文件系统中。这个问题是三个问题中最好解决的一个。我们可以加两个ExecPre指令到负责pivote文件系统的systemd服务文件中。这基本就相当于前面提到的插入脚本的方法。第一个命令会以读写方式重新挂载root文件系统,第二个执行复制操作。

第二个问题有关LD_PRELOAD。因为我们不是在修改shell脚本,我们不能把环境变量传递给这个进程(因为它是由内核调用的),因此加载我们的共享对象就有点棘手了。最简单的办法就是,先把init二进制文件移动到另一个位置,然后在它原来的位置插入我们自己的shell脚本,最后再执行原来的二进制文件。我们只需要两行代码,第一行导出LD_PRELOAD,第二行执行原来的systemd二进制文件。请注意,这样注入的是initrd中的pid 1进程,而不是最终root文件系统的pid 1。

第三个问题就是,在调用switch-root命令之前,systemd会用clearenv()函数清除所有环境变量。因为这个函数是标准库的一部分,我们就可以重写这个函数,让被注入的进程会调用我们的函数而不是原来的函数。我们不关心真正清除环境变量,我们写的clearenv()函数会清除所有环境变量,然后把我们的LD_PRELOAD变量注入到环境中。由于clearenv()只会被调用一次,我们的修改不会导致任何副作用。

解决了以上这三个问题之后,我们的共享对新就会被复制到加密的root文件系统中,我们的LD_PRELOAD会被注入到目标文件系统的pid 1进程中。接下来我们就可以获取用于解密的用户密码。

对于Debian的initrds,可执行文件会要求用户输入密码,然后解密、挂载root文件系统。我们可以把我们的脚本注入到pipeline进程中从而获取密码。

至于systemd,它会通过Unix domain sockets使用一种更复杂的进程间通信。我们选择攻击文件系统的挂载,而非这个进程。这又是一个库函数,它在动态加载库中,从systemd里调用,所以我们可以hook这个函数。解密硬盘的函数叫做crypt_activate_by_passphrase。这个函数会把密码作为char数组。通过hook这个函数,我们可以获取到密码。我们要包裹这个原来的函数,所以我们用dlsym打开真正的函数,并且调用它。不过在此之前我们会保存密码以便以后取回。

为了“保存”密码,我们简单地把密码加到我们之后要复制到root文件系统的共享对象中。之所以选择这种方法是因为我们已经知道这个文件存在,并且会被复制过去。采用这种方法还会减少我们接触到的磁盘文件的数量。为了获取密码,我们之后会读取我们自己文件末尾(通过LD_PRELOAD变量定位),然后把它设置为我们的反弹shell中PASSWORD环境变量的值,因此(以meterpreter为例)通过‘getenv PASSWORD’命令可以获取用于解密磁盘的密码。由于我们所有的目标主机都默认安装了python,所以我们就使用了python meterpreter反弹shell。

解决方案

解决这种问题有很多方法。但是即使使用了这些解决方法,如果攻击者能够物理接触计算机,并且有足够的时间重刷BIOS/UEFI,那也是防不住的。

第一种方法是把bootloader、内核和initrd放在外置的U盘上,然后从U盘上启动从而替代/boot分区。但对用户来说这个方法很糟糕,因为他们离开笔记本的时候要记得拔掉U盘,如果没有卸载的话还要安全卸载/boot分区。更新的时候也很麻烦,要插上U盘才能更新initrd/内核。

另一种方案则是彻底关闭从外置媒体启动系统。这样就不存在自动化攻击的可能性了,但是某些情况下,如对于包含shell的Debian initrds,还是可以从initrd人工挂载和修改initrd的。这可以通过自动键盘式设备完成,这样就绕过了无法通过外置媒体启动系统的限制。

另外,还可以开启BIOS启动密码,这样没有密码的人就无法启动计算机了。

不过如果攻击者有足够的时间把硬盘拆下,然后用他们自己的笔记本启动硬盘的话,后两种方案也不管用了。

最后,最安全的方案就是将SecureBoot拓展到initrd。SecureBoot可以验证bootloader和内核,如果能够验证经过签名的initrd的话,要不留痕迹地在/boot分区修改任何东西都会很困难。但是如果攻击者可以通过刷BIOS/UEFI关闭secureboot的话,这种方案也没用了。

防止这类攻击最好的方法就是不要让你的设备落入攻击者们的手中,我们的PoC攻击可以在2分钟内攻陷所有的目标主机,但在现实世界中,攻击者也可以做出攻击特定目标的payload,这样的payload只用几秒就可以攻击设备。

以上就是本文的全部内容,希望对大家的学习有所帮助。