入侵全球最大的航空公司和酒店奖励平台

引言

在 2023 年 3 月至 2023 年 5 月期间，我们在 Points.com 平台上发现了多个安全漏洞。Points.com 是众多航空公司和酒店会员奖励计划的后端服务提供商。相关漏洞可能被攻击者利用，从而获取用户的敏感账户信息，包括姓名、账单地址、脱敏后的信用卡信息、电子邮箱、电话号码以及交易记录。更为严重的是，攻击者还有可能通过这些漏洞从用户账户中非法转移积分，甚至获得对全球管理员后台的未授权访问权限。

一旦攻击者成功入侵后台，将能够获取完整的管理权限，执行积分发放、奖励计划管理、客户账户操作等一系列管理员操作。

在收到我们的漏洞报告后，Points.com 团队迅速响应，在不到一小时内逐一确认了每条报告内容。随后，他们立即下线相关站点开展全面调查，并及时修复了所有已识别的安全问题。

报告概览

目录遍历漏洞致使可查询 2200 万条订单记录（2023 年 3 月 7 日）我们提交的首个漏洞报告为一个未认证的 HTTP 路径遍历漏洞。攻击者可通过该漏洞访问一个内部 API，从中查询包含约 2200 万条订单记录的数据。这些记录涉及敏感信息，包括部分信用卡号、家庭住址、电子邮箱、电话号码、奖励积分账号、客户授权令牌及其他交易详情。该 API 每次请求返回 100 条记录，攻击者可借助排序参数遍历整个数据集，或通过姓名、邮箱等字段精确查询特定用户信息。

仅凭奖励账号与姓氏即可泄露客户信息并转移积分（2023 年 3 月 7 日）我们提交的第二个漏洞涉及认证绕过。攻击者仅需掌握客户的奖励积分账号和姓氏（这两项数据可通过前述漏洞获得），即可利用一个配置错误的 API 将用户的航空里程积分转出。更严重的是，攻击者还可据此生成完整的账户授权令牌，进而访问订单历史、账单详情、联系方式，并对账户信息及积分进行操作。

针对上述两个漏洞，Points.com 团队在 10 分钟内迅速响应，立即将相关站点下线，并快速完成修复工作，站点随后顺利恢复上线。

Virgin 奖励计划密钥泄露，攻击者可冒充维珍航空调用 API（添加/移除积分、访问客户信息、修改计划设置等）2023 年 5 月 2 日，我们在 Points.com 托管的一处 Virgin 奖励计划网站中发现某接口泄露了 “macID” 和 “macKey” 凭据。这组凭据用于维珍航空通过 Points.com API 进行身份验证。攻击者可利用泄露的密钥对 HTTP 请求进行签名，从而冒充维珍航空合法身份，全面调用 “lcp.points.com” API，执行包括客户账户访问、积分增减、奖励计划设置调整等敏感操作。

Points.com 团队在收到报告后一小时内完成漏洞修复。

新方法实现对 United MileagePlus 积分的转移与账户信息访问（2023 年 4 月 29 日）2023 年 4 月 29 日，我们发现了另一个严重漏洞，影响对象为美国联合航空的奖励系统。攻击者只需知晓目标用户的奖励账号与姓氏，即可生成其账户授权令牌。通过该漏洞，不仅可以转移账户内积分，还可模拟用户身份登录多个 MileagePlus 相关应用，潜在影响包括 MileagePlus 管理后台。与此同时，该漏洞还可泄露用户姓名、账单地址、脱敏信用卡信息、电子邮箱、电话号码以及交易记录。

报告发出后，Points.com 团队在 10 分钟内响应，并立即将相关网站下线，问题随后得到快速修复。

利用弱 Flask Session 密钥完全接管全球管理后台及 Loyalty Wallet 面板（2023 年 5 月 2 日）2023 年 5 月 2 日，我们发现 Points.com 用于统一管理全球航空客户与账户的后台系统，其 Flask 会话密钥竟被设置为“secret”。在此基础上，我们成功对自己的 Cookie 进行重签名，并获取了超级管理员权限。

获得权限后，我们可以访问后台所有核心功能，包括用户信息查看、手动发放奖励、修改积分兑换比例（例如将 1 积分兑换为 100 万积分），以及其他高级功能接口，如促销活动管理、品牌参数设置、重置奖励计划凭据等。若被恶意利用，该权限甚至可能被用来吊销现有奖励计划凭据，进而在短时间内造成航空公司整个奖励系统瘫痪。

尽管我们在凌晨 3:30（CST）提交了该漏洞，Points.com 团队依然在一小时内迅速响应，立即下线系统并更换密钥。

调查 Points.com

近年来，随着机票价格不断上涨，我开始逐渐接触到所谓的“信用卡薅羊毛”社区。这个圈子里的人通过精打细算地使用各类信用卡和制定消费策略，积累奖励积分，再将其兑换为机票、酒店等服务。从黑客的视角来看，这类系统格外引人关注：它们所承载的“积分”本质上是一种接近真实货币的数字资产，只需一步操作即可用于实际消费。随着我对这些系统的使用日益频繁，内心也愈发好奇：这些复杂精细的奖励机制背后，究竟是怎样的技术架构在支撑运转？

带着这份好奇，我联系了 Ian Carroll。他是一位资深的航空系统安全研究者，同时也是航空奖励积分兑换平台 seats.aero 的创始人。在沟通中，我表达了自己希望深入探索奖励计划基础设施安全漏洞的意愿。我们的交流非常顺利，后来又邀请了另一位黑客 Shubham Shah 加入。他在航空领域的漏洞研究同样经验丰富。我们三人随后组建了一个聊天小组，正式开启了对积分系统生态安全漏洞的系统研究。

刚开始调研，我们便注意到一个有趣的现象：几乎所有大型航空公司的奖励计划，其后端服务几乎都由同一家企业提供支持——Points.com。无论是我曾乘坐的航司，还是业内广泛使用的各类里程计划，其技术底座大多指向这家公司。可以说，Points.com 是全球奖励计划基础设施的中枢企业，几乎掌控着这一领域的运行命脉。更令人惊喜的是，Points.com 对安全研究持开放态度，官方甚至明确表示欢迎提交漏洞报告，这为我们的探索提供了充分的正当性和价值空间。

这一切是如何运作的？

在 GitHub 上搜索了一番，并花了数小时翻阅与 Points.com 相关的文档后，我们意外发现了一个专门面向奖励计划开放的 API，它部署在名为 lcp.points.com 的子域名下。在查阅公开代码仓库的过程中，我们偶然发现了这套 API 的接口文档链接——虽然该文档早已从官网下架，但幸运的是，我们在 archive.org 上找到了其归档备份。

这份归档文档详细描述了奖励计划如何通过该 API 实现用户认证、积分发放、积分转移和积分消费等一系列核心功能。对我们而言，这无疑是理解整个奖励计划基础设施运作逻辑的重要突破口，也为后续漏洞研究奠定了坚实基础。

我们最初的设想是：“有没有可能伪装成某个奖励计划的身份，来调用这个 API 呢？”

带着这个问题继续深挖，我们很快发现了一个名为 console.points.com 的网站。这个平台允许公众注册并创建所谓的“骨架账户”（skeleton accounts）——即奖励计划的初始配置模板，待管理员审核通过后才能正式启用。

这个发现意义重大，它表明并非所有与 Points.com API 对接的行为都需要事先建立企业合作关系或签署协议。至少在某个阶段，任何人都可以提交注册申请，创建一个处于“半激活”状态的奖励计划账户。这不仅为我们进一步探索系统权限边界与身份认证机制提供了突破口，也揭示了企业级积分系统在开发流程中可能暴露的开放接口设计。

成功登录 console.points.com 门户后，我们确认这个平台是专为奖励计划运营方设计的管理后台。在这里，奖励计划可以初始化并管理类似 OAuth 的应用程序。每个应用在创建时，系统都会分配一组 API 密钥，用于与托管在 lcp.points.com 上的 Loyalty Commerce Platform（LCP）API 进行交互。

随后，我们对该门户加载的 JavaScript 文件进行了深入分析。结果显示，console.points.com 不仅面向外部合作方开放，更被 Points.com 内部员工用于执行各种管理任务，包括客户账户处理、奖励计划配置，甚至控制网站的核心组件和功能模块。这意味着一旦获得该门户的访问权限，潜在的攻击面将远远超出单纯的测试环境，有可能波及整个生产系统。

更为关键的是，我们在分析过程中还发现了与 lcp.points.com API 通信所依赖的身份认证机制——OAuth 2.0 的 MAC（Message Authentication Code）认证方案。

每个在 console.points.com 注册的应用程序都会被分配两个关键字段：

• macKeyIdentifier：类似于 OAuth 中的 client_id，用于标识请求方的身份；

• macKey：类似于 client_secret，用于对请求进行签名，以验证调用者的合法性。

借助这两个凭据，我们可以对 HTTP 请求进行签名，从而以合法身份调用 lcp.points.com 上的忠诚度平台 API，实现对用户账户、积分发放与转移等核心功能的访问与控制。

这一步的突破，为我们进一步解构积分系统的认证机制与授权逻辑提供了真正意义上的“钥匙”。

平台采用基于 OAuth 2.0 MAC 的认证机制，对我们而言其实是一道不小的门槛。一方面，这意味着我们需要额外编写脚本，对每一个 HTTP 请求进行签名封装，才能进行有效的 API 模糊测试（fuzzing）；另一方面，也意味着密钥本身永远不会直接出现在 HTTP 请求中，而仅用于计算签名。这大大限制了我们在攻击链中对密钥的直接获取。

举个例子：即便我们在某个航空公司奖励计划的网站中发现了 SSRF（服务器端请求伪造）漏洞，所能截获的也只是服务器发起请求时生成的签名，而非用于签名的 macKey 本身。因此，我们无法通过中间人或间接访问方式，利用 SSRF 漏洞进行横向移动或模拟请求，认证机制在这方面设下了一道天然屏障。

尽管如此，我们还是投入了大量时间，对该 API 进行了 fuzzing 测试——使用 Python 编写的签名脚本，一次次地手动构造并签名请求，逐步试探可能存在的逻辑漏洞。然而，遗憾的是，我们并未发现典型的认证绕过路径。虽然我们能够轻松枚举出其他航空公司程序的数值 ID，但并未找到明显的 IDOR 或权限提升等核心漏洞点。

在意识到正面突破的难度后，我们决定转换思路——开始研究那些已经上线的航空公司奖励计划是如何实际集成和使用 Points.com 提供的基础设施的。我们希望能从真实的业务部署中寻找新的突破口。

探索 United Airlines（美联航）的积分管理网站

我们注意到，美联航（United Airlines）的 MileagePlus 奖励计划是由 Points.com 提供技术支持的。基于这一点，我们决定对相关的应用程序进行测试，最终找到了一个专门用于购买、转移和管理 MileagePlus 里程的网站：

https://buymiles.mileageplus.com/united/united_landing_page/#/en-US

在对该站点进行一番模糊测试（fuzzing）后，我们很快发现，尽管这个域名看起来归属于 United Airlines，但其背后的实际托管方却是 Points.com。这一发现非常关键——它意味着该站点的业务逻辑和权限控制，可能主要依赖于 Points.com 提供的统一平台，而非美联航自行维护的系统。

这一点引起了我们的高度兴趣。我们随即开始对该站点的功能流程进行深入测试，试图搞清楚它的身份认证机制背后是否存在潜在漏洞可供利用。

我们继续正常使用 buymiles.mileageplus.com 网站，并在尝试购买里程的过程中，观察到了以下流程：

1.点击 buymiles.mileageplus.com 网站上的 “Buy miles” 按钮。

2.页面会将我们重定向到 www.united.com，要求输入 United MileagePlus 用户名和密码，以完成类似 OAuth 的认证流程。

3.在认证成功后，通过 redirect_uri 参数，我们会被重定向回 buymiles.mileageplus.com。此时，网站使用我们在 www.united.com 认证后获得的授权令牌，发起以下 HTTP 请求：

POST /mileage-plus/sessions/sso HTTP/2  Host: buymiles.mileageplus.com  Content-Type: application/json  {"mvUrl":"www_united_com_auth_token"}

响应如下：

HTTP/2 201 Created  Content-type: application/json  {"memberValidation": "points_com_user_auth_token"}

使用上述响应中返回的 memberValidation 令牌，我们继续向以下端点发送另一个 HTTP 请求，其中 memberDetails 字段包含了返回的 memberValidation 令牌：

POST /payments/authentications/ HTTP/2  Host: buymiles.mileageplus.com  Content-Type: application/json  {"currency":"USD","memberDetails":"points_com_user_auth_token","transactionType":"buy_storefront"}

响应如下：

HTTP/201 Created  Content-type: application/json  {"email": "[email protected]", "firstName": "Samuel", "lastName": "Curry", "memberId": "EH123456"}

完成 OAuth 授权流程后，我们发现 memberValidation 令牌实际上是 Points.com 平台分配给航空公司租户用户的认证令牌。只要拥有该令牌，我们就可以多次使用它进行 API 调用，代表该用户进行身份验证。

如果我们能够为其他用户生成这个令牌，就能代替他们执行各种操作，比如转移航空里程、获取个人信息等。随着我们对航空公司网站与 Points.com 基础设施集成方式的了解不断加深，这也逐渐成为我们研究的重点之一。

在下一篇文章中，我将介绍我发现各大严重漏洞的详细步骤，点个免费赞或分享吧~