从云AK泄露利用看企业特权管理
|
目录 |
|
- 缘起 |
如果你是一名黑客，你是试图直接攻击一个层层加固、布满各种检测技术、24小时人员职守的系统并窃取数据。还是选择通过社会工程学的方式获取系统账号后，如入无人之境地查看、下载数据。
大多数情况从外部发起攻击都需要经历建立据点、搜寻目标、获取权限、拿到数据的几个阶段。对于一个基础安全牢固且运营良好的系统而言，直接攻击将耗费大量的时间和精力，而通过社工等方式获取系统特权账号则成了一条捷径。
缘起
云环境相比传统环境，新增的一大风险即用户Access key的泄露风险。AK是应用程序调用云平台API时使用的认证凭据。一个用户的AK泄露往往代表用户在云平台最高权限的泄露，云环境中所有计算、存储资源对入侵者门洞大开。非法利用者甚至不需要为此单独开发工具，直接使用现成的产品就能直接获取用户在云内的所有资源列表。
将AK导入商用的产品后可轻松获取用户云上资源
入侵者实际能做的还远不止这些。包括轻易查看当前用户所有的数据资产，在主机资产上执行任意命令，修改存储访问权限，数据库账号创建、提权，增加高权限用户，删除日志等等，可谓是无所不能。所以不能简单地将云平台的AK当作单个系统的顶级权限，而是云上所有资源的顶级权限。这也注定了用户在云上的AK将成为攻击者的重点目标。
AK功能强大，基本上管理员账号能做的AK都能做
当前主流AK泄露检测方式
从Gartner预言至少90%的云安全事故是因为用户的错误配置导致，到CSPM成为热门。AK泄露的检测其实并不是一个全新的领域。但是现有对于云平台AK泄露的手段主要还集中在检测代码泄露这一个途径上。
将仓库克隆到本地后就可以通过正则表达式来搜索，当时实际的扫描会更复杂一点，github承载的代码已经非常庞大了。
这种检测方式主要思想为：每次用户commit代码，添加新的文件或修改现有的文件时，密钥泄漏检测模块就会被启动。扫描被硬编码到代码中的Access Key和Access Secret字符串，将疑似AK的字符串发送给对应合作伙伴处进行确认，一旦合作伙伴匹配上真实的AK，即认为发生了AK明文泄露。随后对AK的拥有者发送邮件告警。
按照这位老哥在这里的测试，他故意提交包含AWS明文AK的代码到github平台测试恶意攻击者利用的时间。从提交代码到收到AWS 平台发出的AK泄露告警邮件，中间时间间隔不到1分钟。
而需要注意的是代码提交6分钟后，故意泄露的AK已经被3个攻击者利用，而且产生了查询S3存储桶的日志记录。
之所以有6分钟的延迟，还是因为github平台 commit 的事件订阅流有5分钟延迟。也就是说扣掉这5分钟延迟，攻击者和git平台几乎同时发现用户泄露的明文AK（扣除发邮件的时间，可能github平台稍快一点？不过重点还是在于攻击手段之普遍）。
这种通过扫描程序员代码中硬编码AK的检测技术，有点类似于密码撞库，其优点在于：
1、能在AK泄露的第一时间尽早发现，运气好的话AK此时还未被真正利用，给AK拥有者留了一定的反应时间。但是鉴于恶意使用者的扫描速度，以及从收到通知到完全禁用AK中间的操作时间，这个时间还是不容乐观，最好能通过SOAR工具进行自动化响应。
2、可检测的AK种类不局限于单个平台。目前国内的阿里云、腾讯云、京东云的AK都在github官方支持的范围内。https://docs.github.com/en/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-partner-patterns
但是，这种方案的问题也很明显：
- 对于非git平台上传的代码无法检测。代码管理平台那么多，不是每个都集成了AK明文检查。而且git平台的合作伙伴数量也很有限，并没有覆盖企业用户的核心供应商，这是非常致命的问题。而且在越来越多的企业信息管理趋严，禁止员工将代码上传公共平台的情况下，这个方案的效果将比较有限。
- 内部人员被网络钓鱼、社会工程后泄露的AK无法及时发现。极有可能发一个免费领云平台代金券的钓鱼邮件就能收获到一堆的AK，参照某学校发邮件领月饼的测试。
- 这种检测方式无法检测通过第三方系统暴露的AK，云平台AK应用范围极为广阔，云厂家在努力构建生态的同时，各种生态的合作伙伴水平参差不齐，容易成为整个环节的短板，一旦发生从第三方泄露的事件，极有可能又会产生对云平台的信任危机，以及最终责任难以追溯。
- 最后还是跟第三方有关，用户在开放AK给第三方时，如果没有做到良好的访问控制，不受监控的第三方可能滥用AK权限读取和保存过多原本它不应该读取的数据。
当然除了代码库扫描以外，还有其他的检测方式，比如通过浏览器插件来扫描隐藏在跨源http请求中的AK，但这些方案目前都还不是企业级方案。
防止AK滥用的关键要素？
AK滥用的问题需要从平台方和用户方两边共同解决。平台方需要提供足够多的安全措施，而用户则需要做好特权的管理。
1、默认安全：安全与开放和便利天然就是对立的，从云平台的角度来说对于开放API的范围以及开放的形式需要更加谨慎。高危的功能以什么形式开放，执行权限和编辑权限是否同时对外开放等。应该经过充分的安全评估后，再决定对外开放的范围。
2、分权。避免权限滥用最重要的就是做分权，这是API设计思想层面的改造。在给子账号分配权限时，将API分为读、写操作能达到及格的水平。按API业务属性和管理属性区分会更适合。参照三权分立的思想，创建密钥、重置主机密码这类授权类的读写API，与资源列表、弹性配置等业务数据类的读写API分开。上传任意自定义脚本与运行已经上传脚本的权限分开。最安全的方式也是云平台推荐的方式即删除主AK，只保留子AK。
3、审计和检测。对于AK的利用行为进行审计，记录下请求发起方的角色、调用的记录、读取的实例范围等内容。用以评估是否有AK在用户不知情的情况下被调用。在这基础上可以进一步基于行为进行调用风险的检测，对于某些特定的API调用序列进行告警，高风险API的调用告警。这一点似乎还没有哪一个云平台做到足够的重视。
4、访问控制。平台方有义务提供足够多的访问控制手段，包括不限于单独限制每一个AK访问源IP、访问时间段、可以访问的资源集/资源id、可以调用的API的范围。尽量从API权限层面缩减暴露面，减少不必要的访问风险。不过这么基础的能力，目前却只有华为云做了，而且不能单独对AK进行设置。限制key的使用范围是非常有必要的，但是访问控制不能解决所有的问题。因为高权限的key始终存在泄露的风险，除非高权限的key不存在。
这些都是在git平台泄露检测以外，出于安全的主观视角去考虑应该如何防止最高权限被滥用。当前主流云平台可提供的检测方案与理想还存在不小的差距，更别提还有很多云平台连AK泄露检测都还没有。
对于企业用户而言问题要更棘手一点，AK只是特权账号的一种，分散在各级系统、产品、控制台中的特权账号依旧无法得到有效管理。用户也无法被动指望自己的所有供应商都提供足够的特权管理手段。站在用户的角度来看，特权账号的管理必须是一个统一的产品，而不是松散的产品集合。但是目前并没有一个产品能够提供所有的保护手段。
哪些算特权账号管理？
特权账号广泛分布在企业内部的各个操作系统、应用程序中，而一旦发生云平台AK这种顶级权限的泄露将危害无穷。按照权限级别，大致可以分为以下3类。
根据账号的属性分，大致可以分为4类。
对于特权账号的管理，重点则在于对这4类账号中的高特权的管理员账号进行识别和管理。
如何做特权账号管理？
特权管理的思路本质上与管理其他的资产没有太大的区别。为了达到最佳效果，特权管理解决方案应该至少接入ATT&CK框架中常用到的本地账号、域账号、云账号。并且能够做到：
- 能够协助企业管理人员识别分散在内部各种系统中的特权账号-包括root账号、公用账号、高权限管理员、SSH密钥、证书、API key等等。
- 持续监控账号状态，包括账号的权限变更、轮换记录、使用范围等信息。
- 根据账号的权限等级和用途，将特权账号的使用监控起来，审计特权账号的所有使用记录，包括特权账号的登陆设备、访问源、访问目的、访问时间、访问数据范围等信息，及时发发现对关键文件和目录的未授权访问和/或更改。
- 最好能根据账号的使用记录自动学习生成每个账号的安全策略。再通过人的运营来补齐管理策略。
- 能对特权账号的可疑行为进行告警。必要时并可以联动其他设备，阻断恶意的访问行为。对可疑的活动进行阻断或放行后，能持续更新账号安全策略。
特权管理与堡垒机、IAM、零信任的关系？
堡垒机、IAM、零信任都属于特权管理的一部分，在特权管理的实施层面提供支持。这些产品在各自领域都能发挥特权访问控制的能力，应该利用他们自身的认证、审计和管控能力，保证特权管理策略落地。
而零信任平台则是在将来最有希望能够成为统一大PAM的平台。只是目前的阶段还挣扎在权限控制的大坑里。
特权管理是否应该侵入到业务流程中？
对于特权管理平台的建设，是否应该做一个大而全的系统，不仅仅是监控特权账号的滥用，还要深入到特权账号的整个生命周期中，将特权账号创建、使用、删除、审计全部管理起来？
我个人认为在初期没有必要，不要过度追求一个完美的系统。不同类型的账号管理方式差异很大，包括认证方式、密码轮换策略、访问控制策略等都不相同。如果在一开始就将所有的东西集成在一个大的平台内，会导致这一个平台的工程量和建设周期被无限拉长，且变得过于依赖执行层面的设备，然后面临大量定制开发。
相反通过采集这些特权账号的使用日志，通过大数据的方式检测特权账号的生成、使用、泄露。以及特权账号，会更容易落地。并且可以与恶意行为关联起来。
这个世界总会有新的变化，你无法阻止它们。安全不是阻止未知的事物或做一些很酷的新事物。决定你能做什么不能做什么，并集中精力把基本的事情做好。
参考资料：
1、Privileged Attack Vectors
2、Detecting and Mitigating Secret-Key Leaks in Source Code Repositories
3、 https://www.anquanke.com/post/id/275261 云主机AK/SK泄露利用
4、 https://docs.github.com/en/developers/overview/secret-scanning-partner-program Secret scanning partner program
标签：账号,AK,平台,从云,权限,泄露,特权 来源： https://www.cnblogs.com/pmyewei/p/16701274.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。