n8n 未初始化接管到读取 Flag Writeup

n8n 未初始化接管到读取 Flag Writeup

适用范围：仅限授权的 CTF / 靶场环境 。

题目地址：http://8.147.132.32:44303/setup

一、题目概览

这道题的核心不是传统的爆破，也不是复杂的内存漏洞，而是一个非常典型、非常适合新手练手的思路：

目标服务是一个还没有完成初始化的 n8n 实例。

如果一个 n8n 实例还没有创建首个管理员账户，那么访问者往往可以直接完成初始化流程，创建第一个 owner。拿到 owner 权限后，就可以进入后台，新建工作流，调用危险节点，最后把服务器里的 flag 读出来。

这题的完整利用链可以概括成一句话：

识别框架 -> 判断未初始化 -> 接管 owner -> 创建工作流 -> 执行系统命令 -> 定位并读取 flag

---

二、先说结论

最终拿到的 flag 是：

flag{2b92ff9b-e402-4747-8578-3964687d3b6d}

---

三、做题思路总览

很多新手一看到一个 Web 题网址，就会下意识开始扫目录、测注入、跑爆破。这样不一定错，但效率通常不高。

这题更好的思路是：

1. 先访问页面，判断这是个什么系统。
2. 再确认它是不是"首次启动还没初始化"。
3. 如果是，就优先尝试接管首个管理员。
4. 拿到后台权限后，不要乱点，先想"怎样最短路径接触服务器本地文件系统"。
5. 发现有 Execute Command 这类危险节点时，就已经很接近终点了。

这一点非常重要：

CTF 不是让你无脑乱试，而是训练你快速识别"最短利用链"。

---

四、第一步：访问站点，识别框架

先打开题目给出的地址：

http://8.147.132.32:44303/setup

页面加载后，可以看到明显的初始化表单，大致内容是：

• Set up owner account
• Email
• First Name
• Last Name
• Password

如果这时只看页面文字，我们已经能初步怀疑：这不是普通业务系统，而是某个后台管理或自动化平台的首次安装页面。

继续查看响应内容，很容易在首页 HTML 里发现以下特征：

<title>n8n.io - Workflow Automation</title>
<meta name="n8n:config:rest-endpoint" content="cmVzdA==">

这基本就能确认：

目标是 n8n。

什么是 n8n？

n8n 是一个自动化工作流平台。你可以把它理解成"可视化脚本编排系统"。

它有几个对攻击者来说非常关键的特点：

• 有 Web 后台
• 有用户和项目体系
• 可以创建工作流
• 某些节点可以直接执行系统命令
• 某些版本或某些部署方式下，初始化阶段容易被外部接管

所以一旦发现目标是 n8n，优先就应该考虑：

能不能绕过登录，或者直接拿到首个管理员。

---

五、第二步：确认是否处于"未初始化"状态

对于这一步，最有价值的接口之一是：

/rest/settings

访问后，可以看到关键字段：

{
  "data": {
    "versionCli": "1.118.2",
    "userManagement": {
      "showSetupOnFirstLoad": true,
      "authenticationMethod": "email"
    }
  }
}

这里最关键的是：

"showSetupOnFirstLoad": true

这表示：

这个实例还处于首次初始化阶段，系统希望当前访问者去完成 owner 账户创建。

这是整道题最关键的突破口。

新手一定要记住这一点

很多系统"有没有漏洞"，并不取决于它用了什么高深技术，而取决于它有没有完成正确配置。

在这题里，真正的问题不是某个复杂的 RCE 0day，而是：

服务被公开部署了，但首个管理员还没创建。

这类错误在 CTF 和真实误配置场景里都很常见。

---

六、第三步：接管首个 Owner 账户

既然页面已经显示了 Set up owner account，那就说明前端一定会调用某个接口，把表单数据提交到后端。

分析前端资源后，可以定位到真正的接口：

POST /rest/owner/setup

提交的数据大致是：

{
  "email": "ctf20260426@example.com",
  "firstName": "Ctf",
  "lastName": "Player",
  "password": "Abcd1234Z"
}

创建成功后，服务端会返回新建 owner 用户的信息。

这里有一个实战细节

这题里直接用普通 curl 去打这个接口时，服务端一度返回了 500。

但在浏览器上下文里用页面自己的请求流程去发，接口返回了 200，并成功创建了 owner。

这说明什么？

说明在做题时，不要把"我用一种方式失败了"误认为"这个点不能用"。

很多前端应用会带一些默认请求头、上下文、会话处理逻辑，浏览器内发送和外部裸请求并不完全等价。

创建成功后，我们就拿到了一个 owner 账户，相当于已经进入题目的后半段。

---

七、第四步：确认已经登录，并拿到会话

接管 owner 后，可以看到后台首页内容，说明当前浏览器已经处于已登录状态。

例如页面中会出现：

Welcome Ctf!
Create Workflow
Credentials
Executions
Variables

这时进一步查看浏览器 cookie，可以拿到认证 cookie，例如：

n8n-auth=...

有了这个 cookie，后面就能稳定调用后台接口，例如：

• /rest/workflows
• /rest/users
• /rest/projects
• /rest/executions

这一步的意义是：

从"浏览器里能点"升级为"我可以直接调用后台 API 自动化做事"。

---

八、第五步：进入后台后，先别急着乱跑

很多新手在这里容易犯两个错误：

1. 进后台后四处乱点，没有明确目标。
2. 看到一堆菜单就头大，不知道哪里最可能出结果。

正确思路应该是：

我现在最想要什么？

答案很简单：

我想让服务器替我读取本地文件。

那接下来要找的，就是能触发服务器本地执行的功能。

在 n8n 里，最自然的办法就是：

创建工作流，然后寻找能执行命令的节点。

---

九、第六步：新建一个工作流

进入后台后点击 Create Workflow，系统会新建一个空白工作流。

通过后台接口也能看到新工作流，例如：

{
  "id": "Aup58XBFUvENIps2",
  "name": "poc3",
  "active": false
}

这里我们只需要一个最小工作流，不需要复杂逻辑。

最小利用链设计

最简单的工作流结构就是：

Manual Trigger -> Execute Command

含义分别是：

• Manual Trigger：手动点击执行时触发
• Execute Command：在服务器上执行系统命令

这条链足够短、足够稳定，也非常适合新手理解。

---

十、第七步：验证命令执行能力

不要一上来就直接赌 flag 路径。

正确做法是先用一个非常温和、非常容易验证的命令，确认链路真的打通了。

例如：

pwd

把它填进 Execute Command 节点后运行，返回结果为：

/home/node

这一步证明了三件事：

1. Execute Command 节点真的可用。
2. 命令是在目标服务器本地执行的。
3. 当前工作目录大概率是 /home/node。

对于做题来说，这已经是一个很强的定位信息了。

---

十一、第八步：枚举 Flag 的可能位置

既然当前目录是 /home/node，那么接下来可以先做轻量枚举，而不是立刻全盘爆搜。

我这里使用的思路是：

1. 先查环境变量里有没有 FLAG
2. 再查常见命名的文件路径

使用的命令示例：

env | grep -i FLAG
find / -maxdepth 4 -type f 2>/dev/null | grep -Ei "flag|ctf" | head -50

这次执行后，返回结果里出现了很关键的一行：

/home/node/flag

这说明真正的 flag 文件就在当前用户目录下，名字也非常直接。

为什么这一步很重要？

因为它体现了一个很实用的习惯：

先定位，再读取。

如果你直接无脑 cat /flag、cat /root/flag、cat /home/ctf/flag，运气不好就会浪费很多时间。

而先做一次轻量枚举，通常能很快把范围缩到一个非常小的集合。

---

十二、第九步：读取真正的 Flag

既然已经知道文件在：

/home/node/flag

那最后一步就很直接了，把命令改成：

cat /home/node/flag

再次执行工作流后，返回：

flag{2b92ff9b-e402-4747-8578-3964687d3b6d}

题目到这里就结束了。

---

十三、完整利用链复盘

把整个过程压缩成最简洁的链路，就是下面这 7 步：

1. 打开题目页面，识别出目标是 n8n
2. 调用 /rest/settings，发现 showSetupOnFirstLoad: true
3. 确认实例未初始化，可以创建首个 owner
4. 调用 POST /rest/owner/setup，完成 owner 接管
5. 进入后台，新建工作流
6. 构造 Manual Trigger -> Execute Command
7. 通过命令执行定位并读取 /home/node/flag

如果把它再抽象一层，这题考的其实是三类能力：

• 框架识别能力
• 初始化状态判断能力
• 拿到后台后快速转化为系统级读取能力

---

十四、这题的核心知识点

1. 未初始化接管

很多后台系统第一次启动时，会要求创建首个管理员账户。

如果这个过程暴露在公网，就可能被任何访问者接管。

2. 权限升级思路

这题并不是从低权限一步步提权，而是直接从"未初始化"跳到了"owner"。

这说明：

做题时要先找逻辑上的大入口，而不是默认从最小洞一点点抠。

3. 工作流平台的风险点

像 n8n 这种自动化平台，一旦后台失守，危险性通常比普通 CMS 更高。

原因是它们往往自带：

• 文件读写能力
• 外部请求能力
• 命令执行能力
• 凭据存储能力

所以接管后台后，很多时候就已经接近系统权限了。

4. 轻量枚举优先

在读 flag 前，我没有一上来就全盘乱搜，而是先用：

• pwd
• 环境变量检查
• 小范围 find

这是一种更稳、更快的打法。

---

十五、给新手的做题建议

建议 1：先读页面，不要先上工具

很多题目一开始就把重要信息写在页面里了。

这题的 /setup 页面本身就在告诉你：系统还没初始化。

建议 2：看到框架名，要马上联想到通用攻击面

这题里识别到 n8n 后，就应该立刻想到：

• 登录面
• 初始化面
• REST API
• 工作流执行
• 危险节点

这就是框架指纹带来的价值。

建议 3：每一步都先做"最小验证"

例如：

• 先看能不能创建 owner
• 再看 cookie 是否有效
• 再建最小工作流
• 再执行 pwd
• 最后再读 flag

这样做的好处是，任何一步失败，你都知道问题出在哪里。

建议 4：不要把"命令执行"想得太复杂

在 CTF 里，只要能稳定跑出一条简单命令，比如：

pwd

那后面通常就是信息收集问题，而不是漏洞利用问题了。

---

十六、最终答案

flag{2b92ff9b-e402-4747-8578-3964687d3b6d}

---

十七、总结

这是一道非常适合新手建立"完整攻击链意识"的题。

它没有把难点放在花哨 payload 上，而是把重点放在：

• 你能不能认出这是 n8n
• 你能不能意识到实例还没初始化
• 你能不能把后台权限快速转化成命令执行
• 你能不能用最短路径把 flag 读出来

如果你是刚开始做 Web / 云原生 / 自动化平台相关 CTF 的新手，这题非常值得反复复盘。因为它训练的不是某一个孤立技巧，而是：

从页面现象到框架判断，再到权限接管，最后到落地利用的整条链路思维。