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

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

发现阶段

八月的挑战名为 CatFlix AI，允许访问者流式传输 AI 生成的猫视频。从第一眼看来，访问者需要在观看平台上的任何视频之前登录。

技术指纹识别

使用 BuiltWith 和 Wappalyzer 等工具，我们可以轻松确定 Next.js 用于应用程序的前端和后端。

源代码分析

进一步浏览页面，我们还可以找到对源代码的引用。解压缩源代码文件的内容证实了我们最初发现的应用广泛使用 Next.js。

NoSQL 注入

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

基本 NoSQLi 利用

然而，经过进一步考虑，我们认为这个 NoSQLi 无法帮助我们获得文件系统访问权限。

NextJS 中间件

我们的下一个主要关注点是middleware.ts文件。这个位于/src/middleware.ts的特殊文件允许开发人员在返回响应之前运行代码。

中间件配置错误

除了安全头之外，中间件似乎还执行一些分析功能。以下代码片段检查是否存在 UTM 参数之一。当满足此条件时，将返回带有请求头的完整响应。

Next.js 中间件的一个未记录功能允许我们让NextResponse.next()处理某些头，包括 Location 响应头，这可能会触发内部重定向。

利用 NextJS 中间件中的 SSRF

服务器端请求伪造漏洞允许攻击者代表易受攻击的应用程序、服务或服务器请求外部资源。

访问内部资源

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

端口扫描

使用 Ffuf 或 Burp Suite 等工具，我们可以暴力破解端口号并寻找任何命中。使用此方法，我们可以轻松确定 Jenkins CI/CD 在端口 8080 上运行。

将 SSRF 升级为 RCE

从这一点开始的利用很简单，因为 Jenkins 具有内置的 Groovy 脚本控制台，允许开发人员评估代码，包括执行系统命令。

命令执行

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

POST /?utm_source=meta HTTP/2Host: challenge-0825.intigriti.ioUser-Agent: curl/8.14.1Accept: */*Location: http://localhost:8080/scriptContent-Type: application/x-www-form-urlencodedContent-Length: 50
script=println('whoami'.execute().text)

获取 flag

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

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

POST /?utm_source=meta HTTP/2Host: challenge-0825.intigriti.ioUser-Agent: curl/8.14.1Accept: */*Location: http://localhost:8080/scriptContent-Type: application/x-www-form-urlencodedContent-Length: 50
script=println('cat /app/flag.txt'.execute().text)

结论

在许多情况下，未经清理的用户输入直接传递给评估函数调用，这是所有注入攻击的常见根本原因。通过仔细审查服务器端代码，我们能够识别、验证并武器化几个注入漏洞来实现命令执行。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

办公AI智能小助手

公众号二维码

网络安全技术点滴分享