1. 项目概述一次由信息泄露引发的深度渗透最近在复盘一次授权的渗透测试项目整个过程颇具戏剧性也让我对“细节决定成败”这句话有了更深的理解。目标是一个部署在阿里云上的企业级Web应用防护措施看起来相当到位不仅有阿里云WAFWeb应用防火墙在前端拦截后端架构也采用了主流的开发框架。常规的漏洞扫描和手工测试都收效甚微WAF的规则非常灵敏稍微有点攻击特征的请求就会被立刻阻断。就在测试陷入僵局时一个看似不起眼的文件泄露却成了打开整个系统后门的钥匙。这个文件就是.DS_Store。对于不熟悉的朋友.DS_Store是苹果 macOS 操作系统在访达Finder中浏览文件夹时自动生成的隐藏文件用于存储该文件夹的显示属性比如图标位置、背景图片等。开发者或运维人员如果在使用Mac电脑开发或维护服务器时不小心将包含.DS_Store文件的目录同步或上传到了Web服务器就会造成信息泄露。这个文件本身不包含业务逻辑但它会“记录”所在目录下的文件列表结构。攻击者一旦获取到它就能像拿到一张“藏宝图”清晰地看到服务器某个路径下有哪些文件包括那些本应隐藏的配置文件、备份文件、甚至源码文件。这次实战的核心就是如何利用这张“藏宝图”.DS_Store泄露结合对阿里云WAF规则的理解一步步绕过防护最终实现从外部信息泄露到获取服务器后台权限的完整路径。整个过程涉及信息收集、WAF特性分析、漏洞利用链构造等多个环节非常适合希望提升实战能力的安服人员、红队队员以及想了解现代WAF绕过思路的开发者参考。2. 核心思路与踩点过程解析2.1 初始信息收集与WAF识别测试开始我首先对目标域名进行了基础的信息收集。使用nmap进行端口扫描发现开放了80HTTP和443HTTPS端口。访问Web界面是一个设计精美的企业门户网站。随即我尝试了一些基础的探测请求。一个非常明显的特征出现了当我在URL参数中尝试注入一个简单的单引号‘或sleep()函数时请求被立即阻断页面返回一个统一的错误提示页面上面带有阿里云云盾的标识。这明确告诉我目标站点的流量正经过阿里云WAF。阿里云WAF作为一款成熟的商业产品具备基于规则库和机器学习的行为检测能力对SQL注入、XSS、命令执行等常见攻击的拦截非常迅速和准确。注意在实战中确认WAF的存在和类型是第一步。不同的WAF如阿里云WAF、腾讯云WAF、Cloudflare等有其特定的指纹和行为模式。通过触发一个低危但特征明显的攻击观察返回头的Server字段、错误页面内容、拦截延迟等可以辅助判断。常规的扫描器跑了一遍结果很“干净”除了几个低危的信息泄露如robots.txt暴露了后台登录路径/admin外没有发现可直接利用的高危漏洞。直接访问/admin是一个登录界面尝试弱口令和简单的爆破也被WAF轻松拦下。局面似乎陷入了僵局WAF像一堵坚实的墙挡住了所有正面进攻的路径。2.2 发现关键的.DS_Store泄露点当正面强攻无效时横向的信息收集就变得尤为重要。我开始检查那些容易被忽略的角落。我使用了dirsearch这类目录扫描工具但配置了较低的速率和随机的User-Agent以避免被WAF的风控策略封禁IP。在扫描过程中我特别注意那些常见的备份文件、配置文件后缀如.bak,.swp,.git,.svn等。转机出现在一次针对静态资源目录的深度扫描中。在目标站点的/static/uploads/目录下这是一个常见的用户上传文件存储路径扫描器返回了一个状态码为200的.DS_Store文件。我立刻手动访问https://target.com/static/uploads/.DS_Store浏览器果然开始下载这个文件。拿到.DS_Store文件只是第一步我们需要解析它。由于它是二进制格式不能直接阅读。我使用了一个Python工具ds_store可通过pip安装来解析pip install ds_store python -m ds_store --extract /path/to/downloaded/.DS_Store解析后工具输出了该/static/uploads/目录下的文件列表。令人惊喜的是列表里除了正常的图片文件外还有一个名为202405_backup.sql.zip的文件。这很可能是一个数据库备份文件我尝试直接访问https://target.com/static/uploads/202405_backup.sql.zip文件竟然可以被直接下载。这属于典型的安全配置失误开发人员将备份文件放在了Web可访问目录并且没有设置访问权限控制。3. 利用泄露信息构造攻击链3.1 分析备份文件与获取突破口下载并解压202405_backup.sql.zip后我得到了一个数百兆的SQL文件。快速浏览文件头部确认了这是MySQL数据库的备份包含了完整的表结构和数据。我重点关注了用户表通常名为users,admin,members等。很快我找到了管理员表admin_user里面包含了用户名、密码哈希MD5、邮箱等字段。其中有一个用户名为sysadmin。密码哈希值是32位的MD5字符串。MD5虽然已被证明可碰撞但对于强密码的破解依然需要时间。我并没有急于去在线解密或跑彩虹表而是继续在备份文件中搜索其他信息。在配置文件相关的SQL插入语句或系统设置表中我发现了更有价值的东西一段加密的密钥信息和一些像是系统日志的字段。结合代码注释备份文件中偶尔会包含我推测该系统使用了某开源框架并且为了“方便”将一些本应放在环境变量中的配置如数据库连接密码、加密盐硬编码在了某个配置文件中。而.DS_Store揭示的目录结构里正好有一个/config/目录。我立刻尝试访问https://target.com/config/返回403禁止访问这是正常的。但根据.DS_Store对上级目录的“记忆”我尝试访问https://target.com/.DS_Store想看看根目录下有什么。这次返回了404。我不死心尝试了常见的目录遍历组合如/public/.DS_Store,/app/.DS_Store最终在/application/.DS_Store处再次成功下载。解析这个.DS_Store我看到了config.inc.php,database.php等文件。直接访问这些文件路径由于服务器配置了PHP解析返回的是空白页或错误无法直接查看源码。这时我需要另一个技巧利用备份文件或版本控制泄露。我检查了是否有.git目录可惜没有。但我想起了刚才的备份SQL文件里提到了一个“本地调试配置文件路径”。3.2 绕过WAF实现源代码审计既然有配置文件路径的线索而直接访问又被阻挡我需要一种能“读取”服务器文件内容的方法。这时我想到了利用服务器本身可能存在的功能缺陷。我注意到该Web应用有一个“文件下载”功能用于下载用户上传的附件其URL格式类似/download?fileuser_uploaded_file.pdf。我尝试构造一个请求将file参数的值改为../../application/config/database.php即进行目录遍历试图读取配置文件。毫不意外这个请求立刻被阿里云WAF拦截了因为../是典型的路径遍历攻击特征。WAF绕过开始了。我的思路是不对抗WAF的规则而是寻找WAF规则与后端应用解析之间的差异。常见的绕过方法有编码绕过对攻击载荷进行URL编码、双重URL编码、十六进制编码等。我尝试%2e%2e%2f../的URL编码被拦截。等价替换使用....//在中间插入多余字符某些后端会归一化或..;/也被拦截。参数污染添加多个同名参数如filevalid.pdffile../../config.php看后端处理哪个。这次WAF放行了但后端应用只取了第一个参数下载了正常的文件攻击无效。关键的突破来自于对功能本身的观察。我发现在下载功能的页面源码里对文件名的展示处有一个文件名被截断的迹象。这提示后端可能对file参数进行了某种“净化”或“截断”处理。我猜测逻辑可能是获取参数 - 检查是否包含危险字符如../- 如果有则截断危险字符之前的部分或替换为空 - 拼接路径。我设计了一个测试载荷file../../../application/config/database.php/.。末尾的/.在很多路径处理函数中会被视为当前目录最终被归一化掉。但关键在于WAF的规则可能只匹配../../../这样的模式而../../../xxx/.可能不在其规则内或者优先级不同。我发送了这个请求。奇迹发生了WAF没有拦截服务器返回了404 Not Found。404是一个好迹象说明服务器尝试去寻找这个路径但没找到文件至少请求穿过了WAF到达了后端。我调整路径深度最终使用file../../application/config/database.php/.时服务器返回了200 OK并且内容是一串乱码。将响应体的Raw Data保存为.php文件后打开我看到了清晰的PHP源代码其中包含了数据库的明文用户名和密码实操心得WAF绕过往往不是找到某个“万能绕过符”而是理解特定WAF的规则逻辑和后端应用解析逻辑的差异。静态规则匹配../但../出现在特定位置或结合特定后缀时可能被放过。多观察应用自身的逻辑错误如截断、净化不全比盲目尝试编码更有效。4. 深入内网与权限提升4.1 数据库连接与扩大战果拿到数据库明文密码后我首先尝试从外部连接数据库。但通常云服务器的数据库如RDS只允许内网或特定IP访问。我通过读取的database.php配置确认数据库主机是localhost即和Web服务器在同一台机器上。这意味着我需要先获得一个在Web服务器上执行命令的能力才能访问数据库。此时我再次审视已经获得的源代码。在审计database.php同目录的其他配置文件时我发现了一个cache.php里面配置了Redis作为缓存并且密码为空Redis监听在127.0.0.1:6379。同时在代码审计中我发现了一处因为框架使用不当导致的反序列化漏洞点位于一个处理用户会话的类中该类可以从Redis中读取数据并进行反序列化。这个漏洞链变得清晰起来利用Web应用的反序列化漏洞我可以注入恶意序列化数据到Redis中然后触发该漏洞点实现远程代码执行RCE。由于Redis无密码且与Web应用同机这大大降低了利用难度。我编写了一个利用该框架已知反序列化链的PHPGGCPHP Generic Gadget Chains载荷通过一个存在SQL注入但被WAF拦截的端点将载荷写入到Redis的一个键中。然后访问触发反序列化的用户会话端点成功在服务器上执行了whoami命令返回了www-data用户权限。4.2 权限维持与横向移动获得www-data的shell后我首先进行了基础的信息收集uname -a查看系统版本。cat /etc/passwd查看用户列表。netstat -antp查看网络连接确认这是一台阿里云ECS并且发现了内网中还有其他IP如10.0.1.x网段的数据库和Redis服务。我上传了一个轻量级的、特征较小的反向Shell如用nc或socat编译的静态二进制文件建立了一个更稳定的连接。然后尝试权限提升。检查sudo -l发现www-data用户无权使用sudo。检查具有SUID权限的文件find / -perm -us -type f 2/dev/null发现了一个不常见的、由开发人员自己编译的日志清理工具该工具以root权限运行但在调用system()函数清理日志路径时未对用户输入做过滤。我通过操纵环境变量劫持了该工具执行的命令路径成功将其替换为/bin/bash从而获得了root权限。至此我已经完全控制了这台阿里云ECS服务器。在root权限下我查看了/home目录发现了其他用户的bash历史文件.bash_history在其中找到了连接内网数据库10.0.1.20的密码。利用这台已控的服务器作为跳板我连接了内网数据库发现了更核心的业务数据和其他系统的凭证。整个内网渗透的深度和广度因此得到了极大的扩展。5. 漏洞根源与安全加固建议5.1 本次渗透暴露的核心问题回顾整个渗透过程起点是一个微不足道的.DS_Store文件泄露但最终却导致了整个后台沦陷。这中间暴露了多个层次的安全问题开发环境文件泄露.DS_Store这是最初始的入口。开发或运维人员缺乏安全意识将包含敏感信息的本地环境文件同步到了生产服务器。不安全的文件存储将数据库备份文件.zip存放在Web可访问目录且无任何访问控制属于严重的管理疏忽。配置信息硬编码数据库密码、加密密钥等敏感信息直接写在源码配置文件中一旦源码泄露如通过.DS_Store找到路径并利用漏洞读取秘密将不复存在。WAF绕过与输入过滤不全WAF虽然拦截了标准的攻击模式但应用自身对file参数的净化逻辑存在缺陷未能有效处理边界情况如路径末尾添加/.导致防御被绕过。这属于“过度依赖WAF自身代码安全不足”的典型。中间件配置不当Redis服务设置空密码并监听在本地为反序列化漏洞的利用提供了便利条件。存在已知框架漏洞未及时更新框架或组件使用了存在已知反序列化漏洞的旧版本。权限提升漏洞自定义的SUID程序存在命令注入风险这是开发阶段安全编码意识缺失的体现。5.2 针对性的安全加固方案对于企业尤其是使用云服务的企业可以从以下方面加固避免类似风险资产清理与配置规范在构建和部署流程中强制清除.DS_Store,.git,*.swp,*.bak等无关文件。可以在CI/CD流水线中加入清理脚本或使用.gitignore等工具严格管理。严禁将备份文件、配置文件、日志文件等放置在Web根目录或可公开访问的路径下。应使用云存储OSS设置私有读写、服务器非Web目录并通过严格的权限控制如chmod进行保护。所有敏感配置数据库连接串、API密钥、加密盐必须使用环境变量或云产品如阿里云KMS的动态密钥管理服务绝对禁止硬编码。WAF策略与代码安全并重WAF应作为纵深防御的一环而非唯一防线。在启用云WAF的同时必须确保自身应用代码的安全性。对所有用户输入实施严格的“白名单”验证。例如文件下载功能只允许输入预定义的文件ID或经过严格校验的文件名哈希而非直接传递路径。使用安全的API进行文件操作如PHP的basename()结合白名单或使用框架提供的安全方法。中间件与数据库安全Redis、Memcached等内存数据库必须设置强密码并尽可能限制监听IP如127.0.0.1。阿里云Redis版默认提供VPC内网访问且支持密码应充分利用。数据库如RDS应配置为仅允许从应用服务器所在的VPC内网或特定安全组访问关闭公网IP。定期轮换数据库密码。漏洞管理与权限最小化建立软件成分分析SCA流程使用工具定期扫描项目依赖库中的已知漏洞并及时更新框架和组件。遵循最小权限原则。Web应用运行用户如www-data不应具有sudo权限或执行敏感系统命令的能力。自定义的运维工具如需高权限应进行严格的安全审计避免命令注入等漏洞。定期进行渗透测试和安全审计模拟攻击者视角主动发现“.DS_Store泄露”这类隐蔽入口和由此引发的连锁风险。这次实战再次证明安全是一个整体链条任何一个环节的薄弱都可能被攻击者作为突破口并利用其他环节的疏漏将影响无限放大。从一张被遗忘的“藏宝图”开始到最终掌控后台每一步都利用了不同层面的安全缺失。对于防御方而言修补漏洞固然重要但建立并执行一套覆盖开发、部署、运维全流程的安全规范才是治本之策。