其他分享
首页 > 其他分享> > 从云AK泄露利用看企业特权管理

从云AK泄露利用看企业特权管理

作者:互联网

从云AK泄露利用看企业特权管理

目录

    - 缘起

    - 当前主流AK泄露检测方式

    - 防止AK滥用的关键要素?

    - 哪些算特权账号管理?

    - 如何做特权账号管理?

        - 特权管理与堡垒机、IAM、零信任的关系?

        - 特权管理是否应该侵入到业务流程中?

如果你是一名黑客,你是试图直接攻击一个层层加固、布满各种检测技术、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

 

但是,这种方案的问题也很明显:

  1. 对于非git平台上传的代码无法检测。代码管理平台那么多,不是每个都集成了AK明文检查。而且git平台的合作伙伴数量也很有限,并没有覆盖企业用户的核心供应商,这是非常致命的问题。而且在越来越多的企业信息管理趋严,禁止员工将代码上传公共平台的情况下,这个方案的效果将比较有限。
  2. 内部人员被网络钓鱼、社会工程后泄露的AK无法及时发现。极有可能发一个免费领云平台代金券的钓鱼邮件就能收获到一堆的AK,参照某学校发邮件领月饼的测试。
  3. 这种检测方式无法检测通过第三方系统暴露的AK,云平台AK应用范围极为广阔,云厂家在努力构建生态的同时,各种生态的合作伙伴水平参差不齐,容易成为整个环节的短板,一旦发生从第三方泄露的事件,极有可能又会产生对云平台的信任危机,以及最终责任难以追溯。
  4. 最后还是跟第三方有关,用户在开放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框架中常用到的本地账号、域账号、云账号。并且能够做到:

  1. 能够协助企业管理人员识别分散在内部各种系统中的特权账号-包括root账号、公用账号、高权限管理员、SSH密钥、证书、API key等等。
  2. 持续监控账号状态,包括账号的权限变更、轮换记录、使用范围等信息。
  3. 根据账号的权限等级和用途,将特权账号的使用监控起来,审计特权账号的所有使用记录,包括特权账号的登陆设备、访问源、访问目的、访问时间、访问数据范围等信息,及时发发现对关键文件和目录的未授权访问和/或更改。
  4. 最好能根据账号的使用记录自动学习生成每个账号的安全策略。再通过人的运营来补齐管理策略。
  5. 能对特权账号的可疑行为进行告警。必要时并可以联动其他设备,阻断恶意的访问行为。对可疑的活动进行阻断或放行后,能持续更新账号安全策略。

 

特权管理与堡垒机、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

5、 https://medium.com/swlh/aws-access-keys-leak-in-github-repository-and-some-improvements-in-amazon-reaction-cc2e20e89003

 

标签:账号,AK,平台,从云,权限,泄露,特权
来源: https://www.cnblogs.com/pmyewei/p/16701274.html