CTFHub 信息泄露通关笔记5：备份文件下载 vim文件

本文通过CTFHub的备份文件下载-vim文件关卡的渗透实战，详细分析了Vim编辑器生成的两种备份文件（交换文件.swp和备份文件~）的区别及安全风险。重点阐述了因Vim异常退出导致的.swp文件残留可能引发的源码泄露问题，并通过CTF靶场实战演示了渗透测试流程：1）使用dirsearch等工具扫描发现.swp文件；2）下载并恢复交换文件内容；3）从恢复的源码中获取flag。最后总结了防御建议，包括及时清理临时文件、配置Web服务器禁止访问备份文件等。文章揭示了开发运维中容易被忽视但危害显著的低技术风险。

一、vim备份文件

在开发或运维过程中，管理员经常需要直接在线修改服务器上的配置文件（如 .php, .py等）。常用的编辑器有 vim, nano, emacs 等。这些编辑器为了应对意外退出（如网络断开、误操作），会提供备份机制，自动生成一个备份文件。Vim 是一种文本编辑器，本篇文章讲解vim的备份文件，共有两种情况。

1、交换文件 (Swap File)：

作用：在使用编辑文件时，它会在当前目录中自动生成一个以.swp结尾的临时交换文件，用于备份缓冲区中的内容，以便在意外退出时可以恢复之前编辑的内容。当完成编辑并保存退出后，临时交换文件将会被删除；但如果 Vim 异常退出，那么这个临时文件就会留在硬盘中，攻击者可以通过访问这个临时文件来获取原始文件的内容。这样即使系统崩溃，你也能从交换文件中恢复大部分工作。
命名规则 ：.filename.ext.swp（点号开头，原文件名后加 .swp）。
如果意外退出，再次用 vim 打开原文件时，会提示你恢复。

2、备份文件 (Backup File)：

作用：如果你使用 vim 并设置了 :set backup，那么在保存原文件时，vim 会将修改前的原文件保留为一个备份文件。
命名规则 ：filename.ext~（在原文件名后加一个波浪号 ~）。

3、区别

Vim 的备份文件 filename.ext~ 与 Vim 的交换文件（.filename.ext.swp）二者虽均为 Vim 生成的辅助文件，但核心用途与格式完全不同，需明确区分，具体如下表所示。

对比维度	`filename.ext~`（备份文件）	`.filename.ext.swp`（交换文件）
生成时机	保存文件（`:w`）前，生成原文件副本	打开文件（`vim filename`）时，生成临时交换文件
核心用途	保留编辑前文件副本，用于恢复旧内容	实时缓存编辑过程中的内容，防止意外崩溃丢失
文件格式	纯文本格式，内容与原文件完全一致，可直接读取	二进制格式，需用 `vim -r` 恢复后才能查看
文件名特征	无前置 `.`，非隐藏文件（如 `index.php~`）	有前置 `.`，默认隐藏文件（如 `.index.php.swp`）
清理触发	需手动删除，Vim 不会自动清理	正常退出 Vim（`:q`）后会自动删除，异常退出（如断电、强制关闭）才残留

4、原因分析

.index.php.swp 信息泄露的本质是Vim 异常退出后残留的交换文件被未授权访问，其核心原因包括开发者操作不当、服务器配置疏漏和安全意识不足。这类风险虽然技术复杂度低，但危害不容忽视，尤其是在包含敏感信息的场景下。防御的关键在于编辑完成后及时清理交换文件，或通过服务器配置限制对这类文件的访问。详细的原因可分为以下几点：

异常退出导致文件残留

开发者在服务器上直接使用 Vim 编辑网页文件（如 index.php）时，若发生意外中断（如 SSH连接断开、强制关闭 Vim），.index.php.swp 会被保留在网站根目录下。
Web 服务器配置不当

大多数 Web 服务器（如 Nginx、Apache）默认不会限制对 .swp 后缀文件的访问，也不会将其识别为需要解析的脚本文件，导致攻击者可以通过 HTTP 请求直接下载该文件。
开发者安全意识不足
- 未意识到 Vim 会生成交换文件
- 编辑完成后未检查并清理残留文件
- 直接在生产环境的 Web 目录中编辑代码，而非通过本地编辑后上传
文件权限设置问题

残留的 .index.php.swp 通常继承了 Web 目录的权限（如 www-data 用户可读写），导致 Web 服务器进程可以将其作为静态文件提供下载。

二、渗透实战

1、打开靶场

打开关卡如下所示，提示信息为"当开发人员在线上环境中使用 vim 编辑器，在使用过程中会留下 vim 编辑器缓存，当vim异常退出时，缓存会一直留在服务器上，引起网站源码泄露。"，提示本关卡可以利用vim编辑过程中产生的的.swp结尾的临时交换文件进行渗透测试。点击打开题目，此时系统自动创建Docker环境，下图蓝色部分的URL地址就是靶场环境。

打开靶场URL（challenge-f585cb72e60b3e70.sandbox.ctfhub.com:10800），进入了备份文件下载-vim页面，提示"flag在index.php源码中"，具体如下所示。

复制代码

http://challenge-f585cb72e60b3e70.sandbox.ctfhub.com:10800/

2、信息搜集

（1）DirSearch工具

通过目录扫描工具对challenge-f585cb72e60b3e70.sandbox.ctfhub.com:10800进行渗透，这里选择使用dirsearch工具进行渗透，尝试发现隐藏文件或目录，并通过 -i 200 参数设定只输出服务器返回状态码为200（成功）的扫描结果，命令如下所示。

复制代码

python dirsearch.py -u http://challenge-f585cb72e60b3e70.sandbox.ctfhub.com:10800/ -i 200

python dirsearch.py: 调用Python运行的dirsearch工具。
-u <URL>: 指定要扫描的目标URL。
-i 200: 这是一个过滤器（--filter-code的缩写），告诉工具在输出结果时只显示那些响应状态码为200（即请求成功）的路径，屏蔽404错误等其他无效信息，使结果更清晰。

dirsearch的扫描结果如下所示，在网站根目录下发现了.index.php.swp文件。

（2）Dirmap工具

通过目录扫描工具对challenge-f585cb72e60b3e70.sandbox.ctfhub.com:10800进行渗透，这里选择使用dirmap工具进行渗透，命令如下所示。

复制代码

python dirmap.py -i http://challenge-f585cb72e60b3e70.sandbox.ctfhub.com:10800/ -lcf

其中-lcf（--loadConfigFile）： 该参数表示加载项目根目录下的 dirmap.conf 配置文件，使用文件中定义的详细扫描规则（如字典模式、递归扫描、请求头设置等）。dirmap的扫描结果如下所示，在网站根目录下发现了.index.php.swp文件。

3、下载.index.php.swp

在url后面输入/.index.php.swp，构造完整的URL地址，具体如下所示。

复制代码

http://challenge-f585cb72e60b3e70.sandbox.ctfhub.com:10800/.index.php.swp

访问如上URL地址后页面提示是否下载.index.php.swp文件，点击确认保存文件，如下所示。

4、获取flag

（1）方法1：文本编辑器直接打开

打开.index.php.swp文件，即可查看到flag值，如下图所示。

（2）方法2：vim恢复后打开

在本地Linux环境中使用命令 vim -r index.php 进行恢复，vim会自动解析交换文件并还原出原始文件内容。执行Vim 恢复 index.php.swp（交换文件）命令时系统输出的提示，核心含义是 "交换文件恢复完成，需确认内容并处理残留文件"。提示如下所示。

点击回车，如下所示，可以通过vim查看和编辑恢复成功后的index.php，成功获取到flag。

5、总结

总结CTFHub"备份文件下载"系列题型的渗透流程，具体如下所示。

第一步：信息收集与探测

渗透开始于高效的信息收集。我们首要目标是探测目标网站可能存在的备份文件。这些文件通常由 vim 等编辑器自动生成，常见形式包括：.index.php.swp (交换文件)、index.php~ (备份文件)、index.php.bak 或整站压缩包如 www.zip。我们使用目录爆破工具（如 dirsearch、dirmap、gobuster）并配合包含这些常见后缀的专用字典，对目标URL进行扫描。同时，手动尝试访问这些常见路径也是一个快速有效的方法。关键在于覆盖全面的文件名和后缀组合，不遗漏任何可能的备份痕迹，为下一步分析奠定基础。

第二步：获取与分析备份文件

一旦扫描器发现或手动尝试确认了备份文件的存在（例如通过HTTP状态码200成功下载了 .index.php.swp），立即下载该文件。接下来需要从中恢复出原始源代码。对于 .swp 文件，最佳方式是在本地Linux环境中使用命令 vim -r index.php 进行恢复，vim会自动解析交换文件并还原出原始文件内容。如果是 .bak 或 ~ 文件，可能直接就是可读的源代码。恢复后，使用文本编辑器或代码编辑器仔细审计源代码，这是发现敏感信息的关键一步。

第三步：代码审计与利用构造

仔细审计恢复得到的源代码，寻找两样东西：一是直接的Flag，可能以明文形式硬编码在配置变量或注释中（如 $flag="ctfhub{...}"）；二是更深层的安全风险，如数据库连接字符串、API密钥、隐藏的管理功能入口，或具体的代码风险（如SQL注入、命令注入、文件包含）。例如，若发现 system($cmd); 且 $cmd 参数可控，则可能存在命令注入。审计的目标是找到利用点，并据此构思如何构造攻击载荷（Payload）来读取文件、执行命令或获取数据库中的Flag。

第四步：获取Flag与总结

根据代码审计的结果，实施最终的利用。如果Flag直接写在代码里，直接提交即可。如果发现了数据库密码，则尝试连接数据库执行查询。如果找到了命令注入点，就构造Payload（如 ?cmd=cat /flag）在目标服务器上执行命令，直接获取Flag。成功后，应回顾整个渗透过程：备份文件泄露源于不当的服务器配置（未禁止访问备份后缀）和不良的运维习惯。作为防御方，应在Web服务器配置中拒绝访问 .swp、~、.bak 等后缀的请求，并避免在生产环境直接使用编辑器修改文件。