整理一下过去之前发现的一些小趣事，本文并非批评腾讯云，相关研究和时效性有关，不代表读者当前阅读和未来腾讯云的安全状态，但我分享欲望实在强烈，就在博客简单分享给大家。
无缓解的metadata导致SSRF漏洞默认即可打临时ak sk
之前研究AWS的时候，我发现有metadata的v2版本缓解了ssrf打iam metadata的情况，迁移到腾讯云上就是CAM 角色关联实例打metadata，但是翻找文档期间并未找到相关缓解建议，结合实际实例配置情况，最终得出结论—目前腾讯云没有缓解metadata的问题。
配置过程如下，可以看到我们配置压根没得选：
第二部设置网络和主机就可以看到
此处压根没有版本选择，只能直接选上：
如果绑定了CAM，终端可以直接访问，类似于：
curl http://metadata.tencentyun.com/latest/meta-data/cam/security-credentials/
腾讯云SSRF会被拦截，但是目前来说，WAF并不会阻断腾讯云自己的域名 —– metadata.tencentyun.com ，web ssrf漏洞依然可以直接打出临时ak sk ，对比之下aws的设计已经缓解了这个问题，由于SSRF无法控制请求头变成PUT，因此AWS的设计更加安全，而腾讯云在这一点上就不安全
默认策略放通所有地址
默认情况腾讯云放通icmp\ssh\rdp和内网所有访问，稍微比AWS策略更宽松，虽然这些也算不了什么大影响，但是如果服务器默认不出网，意味着相关无直接回显的漏洞将没有直接手段能确认漏洞存在，不出网极大提高了攻击门槛，腾讯云云上的默认网络策略比较宽松，如果有漏洞比较方便黑客操作。
不安全的存储桶名称，导致潜在的横向攻击
我们过一下存储桶的创建就很容易意识到这个问题，在创建存储桶的时候，观察到腾讯云 —实际上有固定的后缀– 1309XXXX，这个是非常明显的强特征；腾讯云自己也意识到默认域名存在安全风险，建议自己配置自定义域名：
黑客可以利用这一点，可以横向发起攻击，由于限定了存储域名的后缀，只需要不断爆破即可发现同意账户下新的存储桶，从而进一步攻击和收集目标环境的信息，访问一个不存在的将会提示NoSuchBucket：
存在根据权限情况会回显不同，这次是AccessDenied：
利用这个区别，可以把NoSuchBucket的过滤掉，然后爆破出存储桶，有不少存储都是没有ACL限制，直接访问即可获取桶内文件，这一点和我们做目录扫描其实没有区别，看字典是否强大，是否有直接列出文件的漏洞。
ffuf是我常用的选项，直接插请求包来fuzz，插入host，插入路径都行，得师傅们自己构造路径了：
ffuf -request req.txt -w worldlist.txt
但是这一点真不能说是坏处，名称固定了后缀有效的防止了存储桶废弃之后导致潜在的供应链攻击，这一点腾讯算是加分，好坏中和了。
日志审计缺失，部分控制台事件默认不会被记录
观察到在控制台的策略中，使用鉴权模拟器进行的权限校验活动不会被腾讯云的日志审计收录，这对于黑客确定自己的权限有很大的帮助，在云内进行认证扫描的活动会被大大降低，目前社区没有广泛公开这项隐蔽扫描的技术，但可以遇见如果后续有人武器化这部分扫描原理会使得云内检测非常棘手
地址如下，目前没有现成的SDK可以直接调用，我已经没兴趣实现这部分认证和扫描的逻辑，感觉也是体力活没啥技术含量，也许可以用来规避蜜罐的AK SK？
托管实例风险
云服务器有一个非常有意思的功能，可以托管实例到腾讯云上，托管过后的服务器可以执行命令、上传文件，是不是非常像我们用的C2里面的玩意？（笑），实际上不少黑客都喜欢用这个托管来做免杀（本身是白签名的二进制）加上合法流量，使得这个功能定位非常尴尬。如果本身企业在用腾讯云，要区分出来恶意的流量是非常困难的。
后记
上述也谈不上有什么技术含量，就不写总结了，写写感悟吧。在研究过程中，尤其是全新的，尚未有人踏足的领域，研究员必须自己积累大量的基础知识（我的意思是构建整个系统的逻辑），然后从中推演出其中的术法、神通，模仿他人的、复现他人的技术虽然能完成项目上的目标亦或者是其他目的，但终究止步于他人之道。
踏上这研究之路，成败尚且不论，但其中艰辛和寂寞，旁人无从知晓，然而即便如此我们依然要坚定信念，耐住寂寞，继续前进。
