网络渗透测试报告

拿到授权书那天，网络客户只给了一个IP段和一句话：“看看能捅多深。渗透”目标是测试一家做跨境电商的中型公司，对外暴露的报告资产不多，但运维习惯很差——这是网络我在信息收集阶段就嗅到的味道。

扫端口用了不到二十分钟。渗透22、测试80、报告443、网络3306、渗透6379，测试标准配置，报告没什么惊喜。网络但3306对公网开放，渗透而且MySQL版本是测试5.7.26，这个版本有个老毛病：如果root用户允许远程连接且密码强度不够，基本等于把门钥匙插在锁上。我试了三组弱口令，第三组进去了——root/root123。运维大概率是图省事，本地测试环境直接同步到了生产。

数据库里翻到了用户表，密码是MD5加盐，盐值硬编码在代码里。更糟的是，我通过数据库的LOAD_FILE()读到了/etc/passwd，确认了系统用户列表。其中有个deploy用户，家目录下有个.ssh文件夹。虽然读不到私钥内容，但知道用户名和路径，已经足够策划下一步。

从数据库跳到系统，走的是Redis未授权访问。6379端口没设密码，我写入了一个SSH公钥到/root/.ssh/authorized_keys，但root登录被禁止。换了个思路，用Redis的config set dir配合config set dbfilename写了一个webshell到网站根目录。权限是www-data，但足够我翻代码了。

代码里藏着更致命的东西：支付接口的密钥直接写在config.php里，AWS的Access Key也在环境变量文件里明文放着。我试着用这个Key调了一下S3的list-buckets，返回了三个存储桶，其中一个叫backup-prod，权限是public-read。里面躺着最近七天的数据库全量备份，压缩包没加密。

到这里其实已经可以收工了。但我想看看内网边界，于是用webshell做代理，扫了内网C段。发现一台Jenkins，版本2.204，存在未授权访问的脚本命令行。通过它执行了反弹shell，拿到了内网一台跳板机的权限。跳板机上挂着运维的SSH私钥，没有密码短语。用这把钥匙，我登录了核心交换机。

整个链条里，最讽刺的是：客户花了钱买了WAF，规则配得很全，但WAF后面全是裸奔的服务。边界防护做得像铁桶，内部横向移动却像逛自家后院。我把报告初稿发过去的时候，技术负责人沉默了很久，最后问了一句：“那个Redis，我们以为只在内网用。”

渗透测试不是找漏洞比赛。这次能一路打穿，靠的不是什么高级0day，全是配置错误和运维惰性。弱口令、未授权、明文密钥、过度开放的端口——每一条单独看都不致命，串起来就是一条完整的攻击链。客户后来把所有公网数据库端口关了，Redis加了密码，S3桶改成私有，Jenkins升级到最新版。但我知道，只要运维习惯不改，下一个“以为”还会出现。

报告最后一页我写了一句非标准的话：“你们的安全预算，至少三分之一应该花在让开发记住‘不要硬编码密钥’上。”不知道他们听进去没有。

(责任编辑：探索)