❽⁄₈ ⟦ OSCP ⬖ 研记 ⟧ 修改漏洞利用脚本 ➱ Web漏洞利用修改

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

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

🌌 立即前往 👉 🚀

▶ 信息收集

▶ 漏洞检测

▶ 初始立足点 ➢ Web漏洞利用修改 ➢🔥🔥🔥

▶ 权限提升

▶ 横向移动

▶ 报告/分析

▶ 教训/修复

1.修改漏洞利用脚本

[1.2 Web漏洞特点概述](#1.2 Web漏洞特点概述)

[1.2.1 修改漏洞时的关键考虑因素](#1.2.1 修改漏洞时的关键考虑因素)

[1.2.2 选择漏洞利用并修改代码](#1.2.2 选择漏洞利用并修改代码)

[1.2.2.1 寻找漏洞利用代码](#1.2.2.1 寻找漏洞利用代码)

[1.2.2.2 分步修改漏洞利用代码（44976.py）](#1.2.2.2 分步修改漏洞利用代码（44976.py）)

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

2.处理SSL证书验证问题

3.更新身份验证凭证

[1.2.2.3 修改完成确认](#1.2.2.3 修改完成确认)

[1.2.3 运行漏洞利用代码（发现报错）](#1.2.3 运行漏洞利用代码（发现报错）)

[1.2.3.1 问题描述](#1.2.3.1 问题描述)

[1.2.3.2 代码问题解析](#1.2.3.2 代码问题解析)

[1.2.3.3 理解split()方法](#1.2.3.3 理解split()方法)

1.基础用法示例

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

[1.2.3.4 排查程序中的split()](#1.2.3.4 排查程序中的split())

1.代码逻辑解析

2.分析实际的变量location

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

[1.2.4 运行漏洞利用代码（成功）](#1.2.4 运行漏洞利用代码（成功）)

[1.2.5 获取shell](#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攻击时，需系统性地思考以下问题：

🧩 考虑维度	❓ 关键问题
连接与协议	使用HTTP还是HTTPS？是否有自签名证书影响？
路径与路由	是否访问特定的Web应用程序路径或路由？是否依赖默认安装路径？
身份验证	是否为预身份验证漏洞？如需认证，利用程序如何实现登录？
请求构造	如何构造GET/POST请求？涉及哪些HTTP方法？
环境依赖	是否依赖默认的应用配置或默认设置？
防护机制	是否存在.htaccess、WAF等防护？因为公共漏洞利用脚本通常不考虑这些。

🛡️ 公共漏洞利用通常不考虑 ：

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

🔧 修改重点 ：

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

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

📋 攻击场景概述

要素	详情
发现目标	发现一台暴露的Linux主机，它运行Apache2服务器
识别应用	该主机上安装CMS Made Simple 2.2.5 (正在监听443端口)

1.2.2.1 寻找漏洞利用代码

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

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

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

以上内容总结如下：

|----------|------------------------------------|
| 漏洞类型 | 身份验证后的远程代码执行(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证书验证 。具体来说，漏洞利用使用Requests Python库与目标进行通信。利用代码在第34行、55行和80行上进行了三次POST请求：

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

3.更新身份验证凭证

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

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

📊 修改前后对比汇总：

修改项	修改前	修改后	目的
目标地址	示例IP与HTTP协议	实际IP与HTTPS协议	准确指向目标
SSL验证	默认验证证书	verify=False	绕过证书错误
登录凭证	默认/未知凭证	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函数执行过程中触发异常。如下图：

🔍 错误分析

故障点	具体表现	根本原因
第24行代码	`location.split(csrf_param +"=")[1]`	尝试通过第二个元素访问不存在的列表元素。使用split方法来切割存储在传递给parse_csrf_token函数的location参数中的字符串。
错误类型	IndexError: list index out of range	`split()`结果少于2个元素
函数功能	从location参数中解析CSRF令牌	字符串切割逻辑假设错误

1.2.3.2 代码问题解析

python 复制代码

# 问题代码示例
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']

🔢 列表索引规则

索引	对应元素	说明
0	'Kali'	第一个元素
1	'Linux'	第二个元素
2	'Rocks'	第三个元素

⚠️ 关键注意事项

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

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

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

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

在parse_csrf_token函数中：

python 复制代码

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

此代码隐式假设：

location中一定包含 csrf_param，这就是分隔符；
分隔符后的内容必定存在

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

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...

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

步骤	功能描述	示例
1	接收`location`参数（字符串）	`"page=admin&__c=abc123&action=edit"`
2	拼接分隔符`csrf_param + "="`	`"__c="`
3	按分隔符分割字符串	`split("__c=")`
4	获取分割后的第二部分	`[1]` → `"abc123&action=edit"`

2.分析实际的变量location

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

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

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

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

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

📊 预期 vs 实际对比

项目	漏洞利用代码预期	目标系统实际使用	结果
CSRF参数名	`__c`	`_sk_`	❌ 完全不匹配
完整参数格式	`__c=token_value`	`_sk_=token_value`	分割失败
split()结果	双元素列表	单元素列表	索引[1]越界

🎯 问题根源推测

版本差异：漏洞代码基于的CMS版本与目标版本不同
配置差异：目标系统采用了不同的安全配置或自定义设置
环境变化：安装过程或后续更新改变了默认参数名

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

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。

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

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