我是怎么挖到NASA上的P1漏洞的？

在本文中，我将详细介绍如何发现并成功利用一个本地文件包含（LFI）漏洞，最终在 Bugcrowd 上获得 P1 级别的严重性评级。

正文

在深入漏洞细节之前，我们先来了解一下本地文件包含（LFI）是什么。

本地文件包含（LFI）是一种服务器端漏洞，允许攻击者通过应用程序包含本地文件。当 Web 应用程序在动态加载文件时未对输入进行充分验证，便可能导致该漏洞的产生。成功利用 LFI，攻击者可读取敏感系统文件、获取源代码，甚至在某些情况下实现远程代码执行（RCE）。

常见的 LFI 测试 Payload 示例：

../../../../etc/passwd ../../../../etc/hosts ../../../../var/log/apache2/access.log 

在 2020/2021 年 NASA 加入 Bugcrowd 漏洞披露计划之前，我已在其系统中发现并提交了多种安全漏洞，包括：反射型 & 存储型 XSS、不安全的直接对象引用（IDOR）、个人身份信息（PII）泄露，其他关键安全漏洞。

然而，我希望找到更具影响力的漏洞。因此，我在相同域名上进行了长期测试。

起初，我发现了一个自反射型 XSS（Self-XSS），但该漏洞难以扩大危害，即便结合 CSRF 或 Clickjacking 也无法有效利用。因此，我继续深挖系统的其他潜在漏洞。

在分析 Web 端交互时，我注意到一个用户注册页面允许用户与 NASA 数据库通信。我尝试进行 SQL 注入，但由于 NASA 采取了严格的安全措施，未能成功。

然而，一个细节引起了我的注意——网站上提供了一段视频教程，讲解如何与数据库进行查询交互。在观看教程时，我发现该文件是从 FTP 服务器下载的，而该 FTP 服务器又与一个 S3 存储桶相连。

意识到这一点后，我开始进行被动爬取，并使用 Burp Suite 仔细分析捕获的请求。其中，一个特定请求引起了我的注意，而这正是突破口！

这个请求负责从 FTP 服务器下载 .TAR 文件，而该 FTP 服务器实际上是由 S3 提供支持。但与常规情况不同的是——它并不是一个标准的 GET 请求，因此 Burp Suite 无法自动爬取该参数。

在拦截该请求后，我注意到了一段关键的文件路径参数：

/FTP/some/some/some/some/file.tar.gz

该参数似乎可用于操控文件路径。于是，我尝试插入经典的 LFI payload：

/etc/passwd

我成功获取了 /etc/passwd 文件的完整内容！

在确认 LFI 存在后，我进一步测试了对 S3 存储桶的写入权限，结果表明存储桶不可写。

但即便如此，该漏洞已足够严重，因为攻击者可利用其访问：系统关键文件（如 /etc/passwd、/etc/hosts）、后端环境配置信息以及可能包含凭据或 API 密钥的日志文件。

更令人震惊的是，我最初认为该漏洞仅限于认证用户访问，但经过进一步测试后发现，未经认证的用户亦可利用，这意味着攻击者可通过简单的 cURL 请求直接利用漏洞，极大提升了漏洞的危害性。

原文始发于微信公众号（玲珑安全）：我是怎么挖到NASA上的P1漏洞的？