从.DS_Store泄露到阿里云WAF绕过：一次完整的企业级渗透测试实战复盘

1. 项目概述：一次由信息泄露引发的深度渗透

最近在复盘一次授权的渗透测试项目，整个过程颇具戏剧性，也让我对“细节决定成败”这句话有了更深的理解。目标是一个部署在阿里云上的企业级Web应用，防护措施看起来相当到位，不仅有阿里云WAF（Web应用防火墙）在前端拦截，后端架构也采用了主流的开发框架。常规的漏洞扫描和手工测试都收效甚微，WAF的规则非常灵敏，稍微有点攻击特征的请求就会被立刻阻断。就在测试陷入僵局时，一个看似不起眼的文件泄露，却成了打开整个系统后门的钥匙。这个文件就是.DS_Store。

对于不熟悉的朋友，.DS_Store是苹果 macOS 操作系统在访达（Finder）中浏览文件夹时自动生成的隐藏文件，用于存储该文件夹的显示属性，比如图标位置、背景图片等。开发者或运维人员如果在使用Mac电脑开发或维护服务器时，不小心将包含.DS_Store文件的目录同步或上传到了Web服务器，就会造成信息泄露。这个文件本身不包含业务逻辑，但它会“记录”所在目录下的文件列表结构。攻击者一旦获取到它，就能像拿到一张“藏宝图”，清晰地看到服务器某个路径下有哪些文件，包括那些本应隐藏的配置文件、备份文件、甚至源码文件。

这次实战的核心，就是如何利用这张“藏宝图”（.DS_Store泄露），结合对阿里云WAF规则的理解，一步步绕过防护，最终实现从外部信息泄露到获取服务器后台权限的完整路径。整个过程涉及信息收集、WAF特性分析、漏洞利用链构造等多个环节，非常适合希望提升实战能力的安服人员、红队队员以及想了解现代WAF绕过思路的开发者参考。

2. 核心思路与踩点过程解析

2.1 初始信息收集与WAF识别

测试开始，我首先对目标域名进行了基础的信息收集。使用nmap进行端口扫描，发现开放了80（HTTP）和443（HTTPS）端口。访问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?file=user_uploaded_file.pdf。

我尝试构造一个请求，将file参数的值改为../../application/config/database.php，即进行目录遍历，试图读取配置文件。毫不意外，这个请求立刻被阿里云WAF拦截了，因为../是典型的路径遍历攻击特征。

WAF绕过开始了。我的思路是，不对抗WAF的规则，而是寻找WAF规则与后端应用解析之间的差异。常见的绕过方法有：

1. 编码绕过：对攻击载荷进行URL编码、双重URL编码、十六进制编码等。我尝试%2e%2e%2f（../的URL编码），被拦截。
2. 等价替换：使用....//（在中间插入多余字符，某些后端会归一化）或..;/，也被拦截。
3. 参数污染：添加多个同名参数，如file=valid.pdf&file=../../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应用同机，这大大降低了利用难度。我编写了一个利用该框架已知反序列化链的PHPGGC（PHP 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 -u=s -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文件泄露，但最终却导致了整个后台沦陷。这中间暴露了多个层次的安全问题：

1. 开发环境文件泄露（.DS_Store）：这是最初始的入口。开发或运维人员缺乏安全意识，将包含敏感信息的本地环境文件同步到了生产服务器。
2. 不安全的文件存储：将数据库备份文件.zip存放在Web可访问目录，且无任何访问控制，属于严重的管理疏忽。
3. 配置信息硬编码：数据库密码、加密密钥等敏感信息直接写在源码配置文件中，一旦源码泄露（如通过.DS_Store找到路径并利用漏洞读取），秘密将不复存在。
4. WAF绕过与输入过滤不全：WAF虽然拦截了标准的攻击模式，但应用自身对file参数的净化逻辑存在缺陷，未能有效处理边界情况（如路径末尾添加/.），导致防御被绕过。这属于“过度依赖WAF，自身代码安全不足”的典型。
5. 中间件配置不当：Redis服务设置空密码并监听在本地，为反序列化漏洞的利用提供了便利条件。
6. 存在已知框架漏洞：未及时更新框架或组件，使用了存在已知反序列化漏洞的旧版本。
7. 权限提升漏洞：自定义的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泄露”这类隐蔽入口和由此引发的连锁风险。

这次实战再次证明，安全是一个整体链条，任何一个环节的薄弱都可能被攻击者作为突破口，并利用其他环节的疏漏将影响无限放大。从一张被遗忘的“藏宝图”开始，到最终掌控后台，每一步都利用了不同层面的安全缺失。对于防御方而言，修补漏洞固然重要，但建立并执行一套覆盖开发、部署、运维全流程的安全规范，才是治本之策。