加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 电商 > 正文

奇虎360陈思雨:通过漏洞组合利用实现企业内网入侵

发布时间:2021-01-11 00:09:00 所属栏目:电商 来源:网络整理
导读:《奇虎360陈思雨:通过漏洞组合利用实现企业内网入侵》要点: 本文介绍了奇虎360陈思雨:通过漏洞组合利用实现企业内网入侵,希望对您有用。如果有疑问,可以联系我们。 作者简介: 陈思雨(RickGray) 奇虎360 高级安全研究员 奇虎 360,Web 攻防团队 0keeTeam

在漏洞组合的例子中.这是 Java 反序列化执行命令的实例,上面是简单的代码.通过简单的操作,对用户输入的值进行反序列化的操作.下面通过传递一串特殊构造后的代码,在下面成功地触发命令执行漏洞.这个例子讲的是攻击和分布式框架.

3.2 窥探Celery中的消息队列

Celery 是 Python 中非常流行的分布式任务框架.Celery 消息队列间,通过队列的形式实现分布式任务的下滑.既然有消息的传递和分发,就会涉及到消息的封装.

一般分布式架构中都必须得有这两个东西,Celery 的框架中它所支持的消息中间件有 ?RabbitMQ、Redis、MongoDB,它所支持的消息封装方式,pickle、json、msgpack,yaml.

通过序列化操作将具体的任务信息进行封装,然后发送给中间件,中间件根据消息的具体路由信息,传递给具体的集群解析消息,并执行.

刚才所写到的 Celery 任务下发到流程中和刚刚提到的框架组成中,我不知道大家是否发现有比较明显的安全隐患.如果 Redis 和 pickle 存在安全隐患,如何结合这两点攻击后面所在的集群呢?

Redis 作为 Celery 中间件的时候,它的消息存储形式怎样?去除掉一些必要的字段后,我们可以看到在 Redis 中消息 JSON 的形式存储.比较关键的地方,它的 BODY 字段存储信息是 Celery 在任务下发那端,通过序列化的方式所形成的封装数据.

在默认配置下,Celery 又是使用 pickle 进行消息封装.Worke 端在得到消息后,会根据相应的配置反序列化,这一串数据.

简单的在 Worker 端可以用这个代码表示,通过 pickle 反序列化消息中的 boby 字段.

如果我们有可能去控制消息中间件,并且往其中写入我们想要的数据,这时候worke端反序列化的时候,就有可能反序列化我们注入的消息.

我们这里已经可以控制中间件,攻击者构造一个包含有恶意数据的消息,把它输入到消息中间件中,消息中间件根据攻击者所制造的路由信息会发送给 worke 端,worke 端根据配置反序列化这一串数据.如果整个流程都成功地话,worke 会有反序列化的漏洞.

3.3 脆弱的中间件

在上一个例子中,我也提到了 Redis 服务有大量的数量在互联网上暴露,并且存在未授权访问的问题.在 Celery 支持的中间件应用中,有 Redis 和 Mongo,它也是未授权访问的重灾区.

根据扫描统计,还有1.4万个 MongoDB 未授权暴露在官网上.有 Redis 未授权和 MongoDB 未授权存在着,数量也是非常大的.可以认为在未授权的 Redis 和 Mongo 中,确实存在着一些作为 Celery 中间件的应用.

如何从2.9万个未授权的服务中,鉴别这些服务是否作为Celery中间件而存在.如何检测 Celery 中间件在 Redis 和 MongoDB 中.我对 Redis 和 Mongo 进行分析,Celery 默认队列名是 Celery,你在写程序或者功能实现的时候可能有其它的队列,有队列A或者队列B,在这个地方可以存在 kombu binding.

3.4 Dancing on Internet

本地起了 Redis 服务,作为 Celery 的中间件.Celery 通过类型查看,存储的是具体的任务队列,保存在列表中.binding.Celery 字典的形式存在,保存的是路由的信息在里面.MongoDB 中 Celery 表现的形式,有刚刚提到的名称.我们如何结合这些安全问题攻击分析师框架呢?

需要具备几个条件,在使用 Celery 框架实现的应用中,它确实配置了 pickle 的消息封装方式进行处理.但经过了解,在 4.0.0 版本情况下 Celery 使用了 pickle 进行消息封装.

我们有可能控制消息中间件进行消息注入的操作,刚才写到了我们可以在1.5万个 Redis 和1.4万个 MongoDB 中,找出作为 Celery 中间件的应用进行攻击的尝试.

如果这一系列的流程都顺利,Worker 会解析攻击者注入的消息和数据,成功的触发一个反序列化的操作.成功的 Worker 会执行攻击者预先设定的指令和命令,不成功的肯定不受影响.

我们在针对这些命令检测的时候,如何判断漏洞是否有触发呢.我们需要在外网的回联服务器,我们在进行远程命令执行检测的时候,我们会将执行的命令设置为往我们服务器上发连接的具体形式.

我当时在进行全网验证的时候,设置了往我的服务器上进行简单的回联.在所执行的命令中进行标志位的处理,回联回来当时所在的用户是什么,我攻击的中间件IP和类型是什么.

我攻击的类型是 Redis,或者是 MongoDB.前面是 Worker 端执行的时候代表的用户,这是中间件的 IP 地址,这是中间件的具体应用类型.

这是这边的 IP 地址是 Worker 端回联的时候所在的 IP 地址,通过这两条消息的对比,我们可以看到在往 90.156 进行注入的时候,后端有两个不同的 Worker 触发了漏洞,并进行了回联,xx.xx.78.211 和 xx.xx.84.216.

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读