后台访问：Front Gate Tickets 中的未授权 SQL 注入漏洞

# 后台入场：Front Gate Tickets 未经验证的 SQL 注入 来源：https://ian.sh/frontgate 2026 年 1 月 7 日 如果你参加过美国的某个大型音乐节，那么你的门票很可能就是通过 **Front Gate Tickets**（FGT）售出的。FGT 是 Live Nation/Ticketmaster 的子公司，负责处理像 EDC、Bonnaroo、Outside Lands 等活动的售票和支付。我注意到，几乎每个我能找到的音乐节最终都会归结到少数几个 FGT 域名上，而且它们背后的系统看起来相当陈旧。没过多久，我就在核心设备 API 中发现了一个未经验证、极易利用的 SQL 注入漏洞，任何人都可以通过它读取整个 `fgs` 数据库，其中包含超过 500 张表，涉及客户信息、购票记录、员工凭据等等。通过读取密码重置表并兑换一个令牌，我能够以 Front Gate Tickets 管理员身份登录，从而对该平台上的每一个音乐节拥有写入权限。 ## Front Gate Tickets 与设备 API Front Gate Tickets 似乎同时运营着其活动的在线售票和线下实体票房基础设施。这意味着存在既面向消费者也面向现场工作人员（如票务扫描员、票房员工）的在线系统。我没能在消费者应用或管理工具中直接找到明显的问题。相反，当我用 `ffuf` 对 `fgtapi.frontgatetickets.com` API 进行枚举时，碰巧注意到任何包含 `device` 关键词的路径都会返回一个独特的错误信息，提示缺少 `deviceUID` 参数。看起来存在某种中间件，它会拦截所有涉及 `device` 关键词的请求，并根据提供的 `deviceUID` 返回对应设备的 ID 和名称，整个过程无需任何认证。 起初，我提供的 ID 无效，因此每次请求它都会在数据库中创建一个新设备，并返回一个新的设备 ID/名称。我本没抱太大希望，但还是决定检查一下是否存在 SQL 注入。`deviceUID` 为 `12345` 时正常返回，但 `deviceUID` 为 `12345'` 时请求挂起，永远不会完成。该参数似乎是直接被拼接到查询中的： `WHERE deviceUID=''` ## 绕过 WAF 该 API 使用了 AWS WAF，尽管我用 sqlmap 尝试了各种方法，但始终没有取得突破。我一度以为根本不存在 SQL 注入，差点放弃。WAF 会拦截注入的基本构造块。然而，作为最后的手段，我把这个端点交给了运行 Opus 的 Claude Code，它很快发现 WAF 只检查输入的“外层”。将相同的构造嵌套在派生子查询内部，就能顺利通过。 不过，这个 SQL 注入受到很大的限制，我无法直接读取查询的响应。为了逐位读取数据，我需要一个布尔盲注，利用输出中的设备名来读取结果。MySQL 给 Claude 提供了一个简单的方案：像 `'x'` 这样的字符串与数字相加会被强制转换为数值 `0`。因此，一个这样的 payload： `deviceUID = x'+(SELECT CASE WHEN <条件> THEN 1 ELSE 0 END)-- -` 会使 `WHERE` 子句解析为 `deviceUID = N`，其中 `N` 根据 `<条件>` 是否为真而变成 `0` 或 `1`。巧合的是，`0` 和 `1` 都匹配 `DEVICE` 表中的真实行，因此两种情况的响应截然不同： - **真**：响应包含 `MC70-023` - **假**：响应包含 `Intellitix Upload` Opus 自己编写了完整的利用链，我除了启动它之外几乎没做什么。与十年前手动玩 SQL 注入 CTF 相比，这真是轻松太多了！ ## 复现 ```bash curl -s "<endpoint>?deviceUID=x'+(SELECT CASE WHEN (1=1) THEN 1 ELSE 0 END)-- -" | grep -o 'MC70-023\|Intellitix Upload' # → MC70-023 (true) # 将 1=1 换成 1=2： # → Intellitix Upload (false) ``` ## 数据库中的内容 `fgs` 数据库有超过 500 张表。我只从其中几个表中读取了 1 到 5 条记录以验证影响。有几个表格外引人注目： - **员工凭据**——`FGS_USER`（`EMAIL`、`PASSCODE`、`PASSCODE2`、`PERMS_JSON`） - **客户信息与凭据**——`PERSON`（`EMAIL`、`PASSCODE`、`RESET_TOKEN`） - **实时令牌**——`RESET_TOKEN`、`API_TOKEN`、`OAUTH_SERVER_TOKEN`、`oauth_access_tokens` 该注入是只读的，但当你能够读取实时密码重置令牌表时，“只读”也并不能让人放心！ ## 从布尔盲注到音乐节管理员 `RESET_TOKEN` 列中保存着有效、可兑换的密码重置令牌。通过请求密码重置，然后利用注入读取一个令牌，我就能在不知道密码的情况下接管一个账户。从那以后，该平台让我能够完全访问所有使用 FGT 的音乐节。 似乎在某段时间里，他们不再为活动的后续年份重命名，因此 2025 年的活动已经有了 2026 年的新日期和门票。每个活动都打开了完整的票房界面：活动、库存、定价和结账。同一个账户可以直接搜索每个活动的客户数据库。搜索“chris”返回了数千条记录和订单信息，而且我可以为任何想要的活动发放无限数量的“免费”门票。 （图片） （图片） 我在此停手，没有查看超出确认问题所需之外的任何记录。事实已经很清楚：一个未经认证的扫描器 API 请求就足以让人成为 EDC、Bonnaroo 以及该平台上所有其他音乐节的管理员。 ## 影响 攻击者只需知道一个公开的设备端点，就可以： - 为任何使用 FGT 的音乐节生成免费门票 - 读取该平台上所有活动的客户信息和凭据 - 读取并兑换实时密码重置令牌，接管员工和客户账户 - 可能还有更多我未发现的危害！ 所有这一切都只需一个未经认证的 GET 请求，而且是在一个给予虚假安全感而非真正防护的 WAF 之后。 ## 披露 我将此问题报告给了 Front Gate Tickets 和 Live Nation。这两家公司都没有公开的安全联系方式——对于这种规模的公司来说令人失望——但我猜对了正确的邮箱地址。他们迅速解决了问题，并告知我他们很快会推出漏洞赏金计划。 ## 时间线 - **2026 年 4 月 25 日 07:02**：首次向 Front Gate Tickets / Live Nation 披露 - **2026 年 4 月 25 日 09:01**：厂商确认收到报告 - **2026 年 4 月 26 日 14:23**：厂商确认问题已修复 - **2026 年 7 月 1 日**：公开披露