对某自动售货机的测试记录之越权

 

前言

年级大越焦虑，时常想技术做不了之后自己能干嘛。。然后试水入了自动售货机的坑。

结果随手改一个ID就是一个越权。。。然后就有了下面的故事

 

简介

该自动售货机平台已A轮，基于java springCloud构建.

如果拿到管理后台可控制全国几十万台自动售货机，例如让售货机吐货,修改机身广告全国所有机器同时播放某广告，修改账号信息，资金信息等。

本文经过问询公司工作人员，移除公司信息名称及敏感信息后可自由发表.

越权利用条件:自己手中有普通售货机运营账号权限。

 

About 越权

先从越权说起，一年前随手改个order ID就发现越权之后，随便一测，发现全系统根本毫无权限控制。

为了自己的资金安全，随即向该公司报告了漏洞，修修补补大半年，越权差不多修好了。。。

修复方式是增加了token和jwt验证用户权限

最近又来看看，发现越权不止能绕过，还能直接getshell

 

绕过token和jwt鉴权

经过我的提醒之后，程序员增加了token和JWT作为用户鉴权.

抓包POST request报文是这样的(只保留了重点参数，并移除或者修改敏感信息):

POST /service/data/machine/base/v1/list/page/wx HTTP/1.1
Host: target.com
Accept: application/json, text/plain, */*
Authorization: 6410_b0RwaEV2N3lyWUZqdWVnem85RUlHWGJUREVKYw==_10f8de5763a04ad4a8fd3aa94051c570
User-Access-Token: eyJhbGciOiJIUzI1NiJ9.eyJleHBpcmVzSW4iOjE1OTA1ODU5MTcyOTIsImFwcElkIjoiV0VJWElOX1ZFTkRJTkciLCJhdXRoVHlwZSI6IldlYiIsInVzZXJOYW1lIjoiMTMzMzMzMzMzMzMiLCJyb290T3JnSWQiOiIxMDAwMDUwMjMiLCJ1c2VySWQiOjY0MTAsIm9yZ0lkIjoiMTAwMDA1MDIzIn0.6xnbyaYf630GPldrMrL7duXoe2Br8r3IcbAonItlNYA

{"page":1,"machineCode":"518","pageSize":10,"orgId":"100005023","orderByFlag":1}

首先字面理解POST参数是请求orgid为100005023的售货机基础数据。

如果我直接修改orgID请求别人的数据，会直接报错说无权限。

这个时候我们来看Authorization信息

名眼一看就是三个字段，通过下划线分割。第一段是一个四位数数字(6410)，中间的参数尾数有==，所以先试试base64解码,结果为:

oDphEv7yrYFjuegzo9EIGXbTDEJc,是一个长度为28位的字符串，到底是什么加密，暂时没试出来.

10f8de5763a04ad4a8fd3aa94051c570。是一个长度为32位的字符串，是什么也没解出来.

然后我们分析JWT信息。

JWT的明显特征就是由.分割。并且JWT全称为json web token,所以内容是json格式，并由base64编码.

json里{符号编码后就是ey开头，所以这是明显的JWT。

现在我们解码JWT看看里面保存了什么.(这里使用的是在线工具:https://jwt.io/)
解出来之后为:

{
  "expiresIn": 1590585917292,
  "appId": "WEIXIN_VENDING",
  "authType": "Web",
  "userName": "13333333333",
  "rootOrgId": "100005023",
  "userId": 6410,
  "orgId": "100005023"
}

结合JWT解码之后的信息，我们知道了Authorization头中第一个四位字符串是userID。

预计当userId和orgid匹配时就能越权，这个时候我们来试试。

根据自己的userID和orgid我先尝试一下自己ID附近的，测试返回会小很多。

越权成功，读到了userId为6409用户的售货机信息.

经过分析，后端程序的逻辑首先应该是匹配Authorization中的userid和JWT中的userID是否匹配，如果不匹配就会返回

{"isSuccess":false,"code":10005,"message":"身份验证失败，请重新登陆。错误码:10005","content":null}

如果匹配成功就会继续匹配请求的orgId信息是否与JWT中的orgId信息是否匹配。

如果匹配成功就直接返回正确的信息，所以我们只要构造相应的jwt信息和token信息，就能遍历所有用户信息，或者直接控制别人的售货机。

修复建议:

缝缝补补总有遗漏的地方，重新设计鉴权流程，或使用shiro统一鉴权

 

总结

之前发生过漏洞的地方，应该重点关注，并且如果不做全局性的修改，只是缝缝补补,总还会被绕过。

下一期讲我是如果拿到售货机管理后台的root权限的，期望关注。