【云安全】关于云上攻防AccessKey标识特征整理（附实战案例2篇）

前言

对于云场景的渗透，现在已经层出不穷，获得AK和SK，也是云安全渗透中重要的一环。

通常，我们会在一些敏感的配置文件或者通过未授权访问、任意文件读取漏洞等方式，来寻找AK和SK。

通常情况下咱们通过正则匹配式来寻找AK和SK的，如下：

 (?i)((access_key|access_token|admin_pass|admin_user|algolia_admin_key|algolia_api_key|alias_pass|alicloud_access_key|amazon_secret_access_key|amazonaws|ansible_vault_password|aos_key|api_key|api_key_secret|api_key_sid|api_secret|api.googlemaps AIza|apidocs|apikey|apiSecret|app_debug|app_id|app_key|app_log_level|app_secret|appkey|appkeysecret|application_key|appsecret|appspot|auth_token|authorizationToken|authsecret|aws_access|aws_access_key_id|aws_bucket|aws_key|aws_secret|aws_secret_key|aws_token|AWSSecretKey|b2_app_key|bashrc password|bintray_apikey|bintray_gpg_password|bintray_key|bintraykey|bluemix_api_key|bluemix_pass|browserstack_access_key|bucket_password|bucketeer_aws_access_key_id|bucketeer_aws_secret_access_key|built_branch_deploy_key|bx_password|cache_driver|cache_s3_secret_key|cattle_access_key|cattle_secret_key|certificate_password|ci_deploy_password|client_secret|client_zpk_secret_key|clojars_password|cloud_api_key|cloud_watch_aws_access_key|cloudant_password|cloudflare_api_key|cloudflare_auth_key|cloudinary_api_secret|cloudinary_name|codecov_token|config|conn.login|connectionstring|consumer_key|consumer_secret|credentials|cypress_record_key|database_password|database_schema_test|datadog_api_key|datadog_app_key|db_password|db_server|db_username|dbpasswd|dbpassword|dbuser|deploy_password|digitalocean_ssh_key_body|digitalocean_ssh_key_ids|docker_hub_password|docker_key|docker_pass|docker_passwd|docker_password|dockerhub_password|dockerhubpassword|dot-files|dotfiles|droplet_travis_password|dynamoaccesskeyid|dynamosecretaccesskey|elastica_host|elastica_port|elasticsearch_password|encryption_key|encryption_password|env.heroku_api_key|env.sonatype_password|eureka.awssecretkey)[a-z0-9_ .\-,]{0,25})(=|>|:=|\|\|:|<=|=>|:).{0,5}['\"]([0-9a-zA-Z\-_=]{8,64})['\"]

但这是通过匹配 AccessKey 开头的内容，比如 access_token:AKID1AS893JF90AWK 中 access_token 这个开头来进行正则匹配的，但如果没有这样的开头呢？那我们要怎么办？

那这里我就将不同厂商的 Access Key 内容特征，分别整理出来，欢迎各位师傅补充和纠错哈哈 ~

同时也能够根据不同厂商 Key 的不同特征，直接能判断出这是哪家厂商的 Access Key ，从而针对性进行渗透测试。

不同厂商的key

感谢大佬曾哥，以下正则就来自博客T Wiki 面向云安全方向的知识文库

云业务 AccessKey 标识特征整理

Amazon Web Services

亚马逊云计算服务 (Amazon Web Services, AWS) 的 Access Key 开头标识一般是 “AKIA”。 

^AKIA[A-Za-z0-9]{16}$

• Access Key ID: 20个随机的大写字母和数字组成的字符，例如 AKHDNAPO86BSHKDIRYTE
• Secret Access Key ID: 40个随机的大小写字母组成的字符，例如 S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU（无法找回丢失的 Secret Access Key ID）。

Google Cloud Platform

Google Cloud Platform (GCP) 的 Access Key 开头标识一般是 “GOOG”。 

^GOOG[\w\W]{10,30}$

• 服务账号的JSON文件中包含了Access Key和密钥的信息，其中Access Key为client_email，其长度不固定，由字母、数字和特殊字符组成。
• 密钥（Key）的长度为256个字符，由字母、数字和特殊字符组成。

Microsoft Azure

Microsoft Azure 的 Access Key 开头标识一般是 “AZ”。 

^AZ[A-Za-z0-9]{34,40}$

• Azure AD Application的Client ID通常用作Access Key，长度为36个字符，由字母和数字组成。
• 对于Azure AD Application的密钥（Secret），长度为44个字符，由字母、数字和特殊字符组成。

IBM Cloud

IBM 云 (IBM Cloud) 的 Access Key 开头标识一般是 “IBM”。 

^IBM[A-Za-z0-9]{10,40}$

Oracle Cloud

Oracle云 (Oracle Cloud) 的 Access Key 开头标识一般是 “OCID”。 

^OCID[A-Za-z0-9]{10,40}$

阿里云

阿里云 (Alibaba Cloud) 的 Access Key 开头标识一般是 “LTAI”。 

^LTAI[A-Za-z0-9]{12,20}$

• Access Key ID长度为16-24个字符，由大写字母和数字组成。
• Access Key Secret长度为30个字符，由大写字母、小写字母和数字组成。

腾讯云

腾讯云 (Tencent Cloud) 的 Access Key 开头标识一般是 “AKID”。 

^AKID[A-Za-z0-9]{13,20}$

• SecretId长度为17个字符，由字母和数字组成。
• SecretKey长度为40个字符，由字母和数字组成。

华为云

华为云 (Huawei Cloud) 的 Access Key 开头标识一般是 “AK”。

 ^AK[\w\W]{10,62}$

• Access Key ID长度为64个字符，由字母、数字和特殊字符组成。
• Secret Access Key长度为44个字符，由字母、数字和特殊字符组成。

百度云

百度云 (Baidu Cloud) 的 Access Key 开头标识一般是 “AK”。

 ^AK[A-Za-z0-9]{10,40}$

京东云

京东云 (JD Cloud) 的 Access Key 开头标识一般是 “AK”。 

^AK[A-Za-z0-9]{10,40}$

UCloud

UCloud (UCloud) 的 Access Key 开头标识一般是 “UC” 

^UC[A-Za-z0-9]{10,40}$

青云

青云 (QingCloud) 的 Access Key 开头标识一般是 “QY”。 

^QY[A-Za-z0-9]{10,40}$

金山云

金山云 (Kingsoft Cloud) 的 Access Key 开头标识一般是 “KS3″。 

^KS3[A-Za-z0-9]{10,40}$

联通云

联通云 (China Unicom Cloud) 的 Access Key 开头标识一般是 “LTC”。 

^LTC[A-Za-z0-9]{10,60}$

移动云

移动云 (China Mobile Cloud) 的 Access Key 开头标识一般是 “YD”。 

^YD[A-Za-z0-9]{10,60}$

电信云

中国电信云 (China Telecom Cloud) 的 Access Key 开头标识一般是 “CTC”。 

^CTC[A-Za-z0-9]{10,60}$

一云通

一云通 (Yonyou Cloud) 的 Access Key 开头标识一般是 “YYT”。 

^YYT[A-Za-z0-9]{10,60}$

用友云

用友云 (Yonyou Cloud) 的 Access Key 开头标识一般是 “YY”。 

^YY[A-Za-z0-9]{10,40}$

南大通用云

南大通用云 (OUCDC) 的 Access Key 开头标识一般是 “CI”。 

^CI[A-Za-z0-9]{10,40}$

G-Core Labs

G-Core Labs 的 Access Key 开头标识一般是 “gcore” 

^gcore[A-Za-z0-9]{10,30}$

BurpSuite 插件配置

这里咱们使用的查看是HaE

下载

项目地址：http://github.com/gh0stkey/HaE

打开burp，点击Extensions，点击添加即可

配置HaE

安装好hae之后，点击到hae标签下面，选择add

点击启用规则就可以了

实战案例两则

案例一

这里以曾经测试过的小程序为例，进行介绍

配置好Burpsuite抓包，打开小程序，查看数据包，我们可以看见标红的数据

点击查看里面存在cosSecretKey

根据cosSecretKey、cosSecretId配合COSbrowser工具进行连接

案例二

某个档案平台后台管理系统，右键查看源代码并且查看安装的组件

可以发现这里存在webpack组件，一般情况下，咱们就需要跑跑js，翻翻存不存在未授权

通过遍历js，可以发现一个敏感路径

通过拼接域名，然后重新发包可以得到所有的存储桶

总结

本文关于工具的介绍以及案例的介绍都比较简单，大家主要看看思路就行，现在多数厂商都是直接调用大厂的云服务，学习云服务相关的知识也是必须的，如果有什么写的不合适的地方，希望大家见谅，谢谢