GitHub Organization提权漏洞分析与利用教学

1. 背景知识

1.1 GitHub Organization角色体系

GitHub Organization是GitHub提供的一种账号管理模式，适用于团队协作开发：

• Organization：代表一组共同拥有多个项目的用户，提供成员分组管理工具
• Owner：组织所有者，拥有最高权限，可以：
  • 查看和编辑所有组织和仓库数据
  • 不可逆地删除整个组织及其所有数据
• Member：组织成员，权限最低的角色
• Outside collaborator：外部协作者，只能访问特定仓库
• Team：由多个Member组成的团队，可以参与多个仓库的管理

1.2 权限管理模型

GitHub Organization通常采用基于Team的权限控制模型：

• 将成员归类到不同Team中
• 通过Team控制对不同仓库的访问权限
• 这种模型理论上可以限制成员权限，防止权限扩散

2. 漏洞发现过程

2.1 初始发现

研究者在GitHub的"第三方访问策略"设置中发现：

• 该设置通过OAuth应用防止成员向不受信任的第三方授予仓库访问权限
• 启用后，需要Owner批准OAuth权限请求

2.2 集成应用(Integration App)分析

研究者发现集成应用与OAuth应用类似，但代表组织而非用户操作：

• 检查"第三方访问策略"是否适用于集成应用
• 发现组织成员理论上不能请求安装GitHub应用

2.3 安装过程分析

在集成应用安装过程中，关键URL结构：

https://github.com/apps/:app_name/installations/new/permissions?target_id=:id

其中target_id可以是：

• organization_id
• 安装应用身份的account_id

3. 漏洞利用技术

3.1 基本利用方法

1. 以组织成员身份访问应用安装页面
2. 修改URL中的target_id参数，替换为另一个组织的ID
3. 虽然成员理论上只能安装应用到自己的仓库，但实际上可以安装到整个组织

3.2 提权技术

安装集成应用后，可以获得敏感权限：

• 授予所有组织成员和团队的写权限
• 通过API以所有者身份邀请新成员加入组织

关键API操作：

1. 利用服务端API添加或更新组织成员身份
2. 以所有者身份邀请其他用户加入组织

4. 漏洞影响分析

4.1 受影响范围

所有允许成员创建仓库的组织都受影响，因为：

• 成员可以通过创建虚拟仓库来安装应用
• GitHub默认支持此功能
• 大多数组织启用此功能

4.2 攻击面

潜在攻击者包括：

1. 组织内的仓库管理员
2. 入侵组织成员账户的外部攻击者
   • 组织成员越多，攻击面越大
   • 例如300名成员的组织有300个潜在攻击入口

5. 漏洞修复与防御

5.1 GitHub的修复时间线

1. 2017/11/11 凌晨3:30 - 漏洞初报
2. 2017/11/11 晚上8:30 - 深入发现提权漏洞
3. 2017/11/13 早上5:30 - GitHub分析漏洞
4. 2017/11/14 下午1:40 - 发放$10,000赏金
5. 2017/11/15 - 新版本中修复漏洞
6. 2017/12/1 - 彻底修复

5.2 防御建议

组织管理员应采取以下措施：

1. 限制成员创建仓库的权限
2. 定期审核已安装的GitHub应用
3. 监控组织成员变动
4. 启用双因素认证
5. 教育成员关于安全风险

6. 漏洞挖掘方法论

6.1 关键思路

1. 对比不同功能的安全控制差异（OAuth应用 vs 集成应用）
2. 关注权限边界检查（成员 vs 所有者）
3. 分析安装流程中的参数篡改可能性
4. 验证API的实际权限控制

6.2 测试技巧

1. 修改关键ID参数测试越权
2. 检查安装后的实际权限是否超出预期
3. 验证API操作是否遵循声明的权限模型
4. 尝试从低权限账户执行高权限操作

7. 总结

这个GitHub Organization提权漏洞展示了：

1. 权限模型实现中的不一致性
2. 安装流程中的参数篡改风险
3. API权限控制的不足
4. 最小权限原则的重要性

该漏洞的发现和报告过程也体现了：

1. 系统化安全研究的方法
2. 漏洞的逐步深入挖掘
3. 负责任的披露流程
4. 厂商对安全研究的认可（$10,000赏金）