阳江市网站建设_网站建设公司_电商网站_seo优化

郑重声明：本文所涉安全技术仅限用于合法研究与学习目的，严禁任何形式的非法利用。因不当使用所导致的一切法律与经济责任，本人概不负责。任何形式的转载均须明确标注原文出处，且不得用于商业目的。

🔋点赞| 能量注入 ❤️关注| 信号锁定 🔔收藏| 数据归档 ⭐️评论| 保持连接💬

🌌立即前往👉🚀

​​

▶ 信息收集
▶ 漏洞检测
▶初始立足点 ➢ Web漏洞利用修改 ➢🔥🔥🔥
▶ 权限提升
▶ 横向移动
▶ 报告/分析
▶ 教训/修复

目录

1.修改漏洞利用脚本

1.2 Web漏洞特点概述

1.2.1 修改漏洞时的关键考虑因素

1.2.2 选择漏洞利用并修改代码

1.2.2.1 寻找漏洞利用代码

1.2.2.2 分步修改漏洞利用代码（44976.py）

1.修改目标url地址和协议

2.处理SSL证书验证问题

3.更新身份验证凭证

1.2.2.3 修改完成确认

1.2.3 运行漏洞利用代码（发现报错）

1.2.3.1 问题描述

1.2.3.2 代码问题解析

1.2.3.3 理解split()方法

1.基础用法示例

2.与漏洞代码的关联的分析

1.2.3.4 排查程序中的split()

1.代码逻辑解析

2.分析实际的变量location

3.得出结论：CSRF参数名不匹配

1.2.4 运行漏洞利用代码（成功）

1.2.5 获取shell

欢迎❤️ 点赞 | 🔔 关注 | ⭐️ 收藏 | 💬 评论

1.修改漏洞利用脚本

在之前的内容主要是详细讲解了内存损坏漏洞（缓冲区溢出）的利用脚本的修改。从本文开始，讲解Web漏洞的利用脚本修改。CVE-2018-1000094：CMSMS 2.2.5代码执行漏洞。

1.2 Web漏洞特点概述

Web应用程序漏洞通常不涉及内存损坏，因此不受操作系统保护机制（如DEP和ASLR）的影响，这也使得它们更容易被重复利用。这类漏洞常导致：

• 🗃️数据库信息泄露

• 💻对底层系统的完全控制

1.2.1 修改漏洞时的关键考虑因素

即使我们在Web攻击中可能不需要处理十六进制编码的Payload，但正确阅读代码并理解在编辑过程中必须考虑的事项非常重要。修改Web攻击时，需系统性地思考以下问题：

• 🛡️公共漏洞利用通常不考虑：
  Web应用防火墙(WAF)、目录访问控制(.htaccess)等防护措施，因环境差异大，一般不在漏洞作者的考虑范围内。

• 🔧修改重点：
  理解代码逻辑、明确触发流程、调整请求结构与认证方式是成功利用的关键。

1.2.2 选择漏洞利用并修改代码

📋攻击场景概述

1.2.2.1 寻找漏洞利用代码

CMS Made Simple 2.2.5版本似乎存在远程代码执行漏洞RCE，并且Exploit-DB上有公开的利用工具可用（代码链接：CMS Made Simple 2.2.5漏洞利用脚本）。如下图（红框），是一个身份验证后的RCE漏洞。

恰好，在枚举的过程中，我们在另外一台机器上发现了有效的应用凭证（admin / HUYfaw763）。

我们的计划是：将通用的公开利用工具适应我们的目标，获得远程代码执行，并最终上传一个能够控制服务器的Webshell。

​​

以上内容总结如下：

1.2.2.2分步修改漏洞利用代码（44976.py）

1.修改目标url地址和协议

我们检查原始代码，看到base_url变量需要调整以匹配实际环境：

​​修改后，反映我们的虚拟机目标：

​

✅关键改动：协议从HTTP改为HTTPS，IP地址更新为目标实际地址。

2.处理SSL证书验证问题

访问目标网站（https://192.168.50.120/admin）时出现SEC_ERROR_UNKNOWN_ISSUER错误 →远程主机上的证书无法验证。

需要在漏洞利用代码中考虑到这一点，即：忽略SSL证书验证。具体来说，漏洞利用使用RequestsPython库与目标进行通信。利用代码在第34行、55行和80行上进行了三次POST请求：

​

解决方案：在Requests库中忽略SSL验证，将verify参数设置为“False”，SSL证书将被忽略。如下图，新增红色字体内容即可实现忽略SSL验证：

​

3.更新身份验证凭证

替换默认凭证为枚举获得的实际凭证，这些在第15行和第16行分别定义为用户名和密码的变量中。代码原来：

​

修改后，即之前枚举过程中发现了有效的应用凭证（admin / HUYfaw763）。

​

📊修改前后对比汇总：

1.2.2.3修改完成确认

完成上述三项修改后，对漏洞利用脚本进行另存为44976_modified.py。它已适配目标环境：

• 🎯精准定位：正确指向目标服务器

• 🔓绕过障碍：处理了SSL证书问题

• 🚪通过认证：使用有效凭证登录

• ⚡保持有效：原始Payload仍可正常执行系统命令

💡核心要点：成功的漏洞利用修改需要准确的环境匹配、灵活的协议处理和有效的身份认证。这三项修改确保了公开漏洞利用工具能在特定目标环境中成功执行。

最终的漏洞利用应如下所示：

​

​

​

1.2.3 运行漏洞利用代码（发现报错）

1.2.3.1问题描述

运行修改后的脚本44976_modified.py，提示程序在第24行的parse_csrf_token函数执行过程中触发异常。如下图：

​

🔍错误分析

1.2.3.2代码问题解析

# 问题代码示例 def parse_csrf_token(location): csrf_param = "csrf_token" # 当location中不包含"csrf_token="时，split()只返回一个元素 return location.split(csrf_param + "=")[1] # ❌ 索引[1]不存在！

🎯故障根源

• 错误假设：代码假定location字符串中必定包含csrf_token=参数

• 实际场景：目标服务器的响应可能不包含预期的CSRF令牌参数

• 分割结果：split()方法在未找到分隔符时，只返回原始字符串的单元素列表

1.2.3.3理解split()方法

split()是Python字符串的内置方法，用于按照指定分隔符切割字符串，返回一个列表。

1.基础用法示例

​

📊split()方法工作流程

原始字符串："Kali*-*Linux*-*Rocks" ↓ 分隔符："*-*" ↓ 切割操作 ↓ 结果列表：['Kali', 'Linux', 'Rocks']

🔢列表索引规则

⚠️关键注意事项

• 当分隔符不存在于字符串中时，split()返回只包含原字符串的单元素列表

• 索引访问越界会导致IndexError: list index out of range错误

• Python列表索引从0开始，而非1

2.与漏洞代码的关联的分析

在parse_csrf_token函数中：

location.split(csrf_param + "=")[1] # 高风险操作！

此代码隐式假设：

1. location中一定包含csrf_param，这就是分隔符；

2. 分隔符后的内容必定存在

当这两个假设不成立时，就会触发索引越界错误（因为没有第二个元素）。

1.2.3.4 排查程序中的split()

1.代码逻辑解析

csrf_param = "__c" # ⚠️ 硬编码的CSRF参数名 def parse_csrf_token(location): return location.split(csrf_param + "=")[1] # 提取token值 # 预期格式：...__c=token_value...

📝函数功能与流程（以上内容解析）

2.分析实际的变量location

为了更好地理解IndexError，在利用脚本的返回指令之前，parse_csrf_token函数中添加一个print语句：

现在运行利用程序，在调用分割方 法之前显示完整的字符串。原来如此~

3.得出结论：CSRF参数名不匹配

⚡核心问题：硬编码假设失效

漏洞利用代码预期使用__c作为CSRF参数名，但目标系统实际使用的是_sk_，导致字符串分割失败和索引越界错误。

📊预期 vs 实际对比

🎯问题根源推测

1. 版本差异：漏洞代码基于的CMS版本与目标版本不同

2. 配置差异：目标系统采用了不同的安全配置或自定义设置

3. 环境变化：安装过程或后续更新改变了默认参数名

这个案例凸显了环境适配在漏洞利用中的重要性——即使核心漏洞存在，周边细节的不匹配也可能导致利用失败。

1.2.4 运行漏洞利用代码（成功）

接下来，更改csrf_param变量以匹配CMS响应，并找出利用是否有效，把_sk_ 作为分割符。

修改后，将执行修改后的利用：

错误不再显示，我们收到一条消息告诉我们攻击成功了。现在我们可以使用类似curl的工具连接到这个PHP shell（https://192.168.50.45/uploads/shell.php），并提供一个系统命令作为Payload来验证攻击。

1.2.5 获取shell

加入cmd后的命令：

太棒了！利用成功了，我们现在有一个Webshell。

欢迎❤️ 点赞 | 🔔 关注 | ⭐️ 收藏 | 💬 评论

每一份支持，都是我持续输出的光。