免责声明
本公众号“猎洞时刻”旨在分享网络安全领域的相关知识，仅限于学习和研究之用。本公众号并不鼓励或支持任何非法活动。本公众号中提供的所有内容都是基于作者的经验和知识，并仅代表作者个人的观点和意见。这些观点和意见仅供参考，不构成任何形式的承诺或保证。本公众号不对任何人因使用或依赖本公众号提供的信息、工具或技术所造成的任何损失或伤害负责。本公众号提供的技术和工具仅限于学习和研究之用，不得用于非法活动。任何非法活动均与本公众号的立场和政策相违背，并将依法承担法律责任。本公众号不对使用本公众号提供的工具和技术所造成的任何直接或间接损失负责。使用者必须自行承担使用风险，同时对自己的行为负全部责任。本公众号保留随时修改或补充免责声明的权利，而不需事先通知。
一、任意用户登陆
某商城小程序存在任意用户登录漏洞，攻击者可以接管任意用户查看订单并执行操作，以及造成用户信息泄露。漏洞成因是小程序将用户验证的关键信息"session_key"返回给了前端，攻击者可以利用session_key构造任意用户的加密数据包，发送至服务器解析，从而导致任意用户登录。——
来到小程序：
点击快捷登陆的时候，发送了一个发送包，带有三个参数，encrypteddata（身份凭证）、iv（偏移量）、sessionkey（对称密钥）。
其实很明显能看出来这是一个aes对称加密，这里泄漏了密钥，那么这个加密流程我们可以随意篡改。
出现sessionkey 以及密文和iv ，编写脚本解密。而encrypteddata就是加密后的个人凭证。
进行解密，拿到信息，发现鉴权点，是手机号。
拿到明文信息json内容，把里面的手机号，改成受害者的手机号，然后再通过对称加密，加密回去，形成一个新的加密后的凭证信息。
接管其他用户，测试手机号：177******
执行加密，生成新的encrypteddata（身份凭证）
然后发包，成功登陆，伪造登陆了受害者的手机号账户。
完成接管：
当然，使用脚本进行加解密比较麻烦，这里也提供一个图形化的界面，实现sessionkey加解密。
二、存储桶的拓展列桶攻击
这里域名进行模糊化处理，比如这个登陆界面是。
https://admin.xxx.domain.com
然后发现本站点存在下面类型的存储桶
https://obs.xxx.domain.com
可以看到，全局存储区并不能无签名调用访问。
使用常见桶命名进行子域枚举：
dev, develop, development
test, testing, qa, qas
staging, stage, preprod, pre-prod
uat
sandbox
这里在原本的域名这里，添加test，发现了一个新的存储桶。并且存在列桶漏洞。
也就是
https://test.obs.xxx.domain.com
直接列桶，直接可访问：
https://test.obs.xxx.domain.com/ECS-nginx.vmdk
https://test.obs.xxx.domain.com.com/server.key
010工具打开，得到私钥：
key可以访问并得到的对象包括：虚拟磁盘文件、Nginx安装包、配套的– 公钥/私钥文件；攻击者可以对通往该服务器的加密流量进行中间人攻击（MITM），解密用户的敏感数据，冒充其服务器进行钓鱼。
三、垂直越权
某供应商合作征集平台存在管理员接口配置不当，普通用户可利用该api接口实现账号停用/删除等高危操作。
test_test1/admin123（测试账号，低权限）
admin_hs/admin888（管理员）
登录后来到后台，测试账号没有开放操作管理权限：
使用管理员账户登陆系统，发现存在账户维护功能，但是低权限账户并不会显示这个功能点。
使用高权限账户，进行burp抓包，发现一个高权限接口【修改账户API】
使用低权限账户权限，访问这个高权限修改账户信息的API，直接发包，发现接口报错500.
后面发现是缺少参数，发现需要userid和status参数，这个status参数好猜测，值写1、2、3、0 这种关键词即可。
但是userid是无顺的，需要在历史数据包、个人信息返回包、评论区、排行榜，去找到别人的userid才行。
{"userId":"028F7306CxxxxxxFBA17D","status":"0"}
重新构造数据包。
POST /index.php/api/Account/changeAccountStatusHost: xxxxxContent-Type: application/json{"userId":"028F7306C2A1B3747838B36F0CFBA17D","status":"0"}
这下状态码为200.
再次发送，请求成功，在EDGE中刷新用户ID，权限绕过成功。
后续发现"status":"-1"为删除用户ID的操作，且无法找回；该banner："status":"1"为启用户ID，但是一旦执行-1后，0/1不再有用。
四、SSRF
漏洞简单分析：后端php中的file_get_contents()函数过滤规则过于简单，只对dnslog关键词进行黑名单限制。
漏洞危害：可通过url参数进行dns外带以及内网主机存活和资产探测。
这里尝试远程请求京东站点，看看能否请求成功。
利用如下：
测试：
GET /xxx/interface/bridge.php?url=https://jd.com HTTP/1.1Host: www.xxxx.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:142.0) Gecko/20100101 Firefox/142.0Accept: application/json, text/plain, */*Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateConnection: closePriority: u=0
返回包，成功返回京东的页面信息，说明请求成功。
通过请求包向内网IP发起请求：10.182.0.100，确定了内网网段，下一步搜集内网主机
，由于file、dict、gopher协议无法利用，使用http/s构造如下：
GET /xxx/interface/memcache.php?url=http%3A%2F%2F10.182.0.§100§%2F HTTP/1.1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:142.0) Gecko/20100101 Firefox/142.0Accept: application/json, text/plain, */*Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateConnection: closePriority: u=0
创建字典，遍历结果：
搜集到的内网存活主机：
url=http%3A%2F%2F10.182.0.163%2Fhttp%3A%2F%2F10.182.0.200%2Fhttp%3A%2F%2F10.182.0.159%2Fhttp%3A%2F%2F10.182.0.149%2Fhttp%3A%2F%2F10.182.0.150%2Fhttp%3A%2F%2F10.182.0.151%2Fhttp%3A%2F%2F10.182.0.152%2Fhttp%3A%2F%2F10.182.0.153%2Fhttp%3A%2F%2F10.182.0.154%2Fhttp%3A%2F%2F10.182.0.156%2Fhttp%3A%2F%2F10.182.0.157%2F（识别出jeecms）http%3A%2F%2F10.182.0.208%2Fhttp%3A%2F%2F10.182.0.210%2Fhttp%3A%2F%2F10.182.0.171%2Fhttp%3A%2F%2F10.182.0.11%2Fhttp%3A%2F%2F10.182.0.12%2Fhttp%3A%2F%2F10.182.0.13%2Fhttp%3A%2F%2F10.182.0.20%2F
使用ssrf，然后http协议查看内网站点，发现请求成功，该ssrf可以回显访问内网任意站点信息。
)
