起因

因为疫情的原因,公司已经采用网上订餐配送的方式接近一年了,并且为此购买了一套订餐系统,每天员工自己从平台上下单,然后餐饮公司负责配送,平台长这样。

想针对这个平台做测试已经想很久了,正好最近业务不多,于是趁划水时间对该平台做了一下渗透测试,因为该平台用户量比较多,fofa上搜了一下指纹有400多条,所以便想着去搞一下然后提交到CNVD上混个证书。

过程

前期对该平台先进行了一波目录扫描,看是否能够扫描到备份文件,结果我400w+的目录字典硬是一个都没扫出来。

看到一个目录都没扫出来,心态有点崩,于是先对平台进行了一个信息收集,发现该平台为ASP+Windows架构,服务器IIS版本为8.5,虽然这些信息没多少用处。

然后接下来就是AWVS工程师+XRAY工程师上线,疯狂扫描了一波,看到结果,瞬间感觉有搞头,打开漏洞详情一看,我QNMD。

okok,心态放稳,现在只是对外部页面进行了一波测试,下面我们登陆到后台去进行测试,后台他长这样。

因为是线上系统,不敢用扫描器去暴力扫描,于是开始手工对每个接口进行测试,看了一下各个接口,大多是GET请求,并且参数都是经过编码,对接口进行了SQL注入和越权测试和一些常见的漏洞,均无果,但是直觉告诉我,这个系统肯定有漏洞,只是还没找到,于是我对页面的接口再次仔细的审查了一遍,终于在修改默认食堂处看到了曙光。

该系统提供了一个修改默认食堂功能,可以修改成自己想吃的那个饭堂为你送餐,它长这样。

当我们点击确定的时候,开启抓包,可以看到该请求包提供了一个Group参数作为食堂ID去替换。

正常情况下发包,会提示设置成功并刷新页面。

但是在group参数后面加上 ' ,返回包成功报错,并爆出SQL语句。

哦吼,有搞头,直接将该请求包发送到sqlmap进行一波测试。

ok,中午可以加餐了,今天我要吃两个螃蟹。

看了一下还是DBA权限。

进行到这里,已经不打算再进行深入了,只要证明漏洞存在,CNVD承认这个漏洞就行,接下来的问题就是我们要去找相同案例3个并成功复现,然后再找10个现网相同的业务。

因为前面已经通过fofa知道现网存在很多相同业务,这边直接通过我写的一款fofa搜索导出工具将目标IP全部导出来。

搜索结果会直接导出到当前目录下的ok.txt文档里。

下面就是针对这些系统进行复现,只要凑够3个就行了,因为刚才找到的SQL注入是需要登录后才能访问到的,所以现在也要登陆到这些系统后台去进行复现截图。

但是有一个问题,我上哪里去弄这些系统的账号？因为我们公司的订餐系统是通过名字全拼与自定义的密码登陆的,比如zhangsan,lisi这些,天真的我以为别人的系统也会是这样的命名规范,于是直接拿出我的10w+名字全拼字典进行爆破。

这套系统登陆页面存在一个用户名枚举漏洞,当输入不存在的用户名,页面会直接返回你输入的用户名不存在。

反之,当输入存在的用户名+错误的密码,就会提示你输入的密码不正确,请注意大小写。

然而,残酷的现实又一次发生在我身上,10w+字典愣是一个也没爆出来,我也陷入了对人生的大思考中,刚点的两个螃蟹已经打算退掉。

但是抱着最后一次尝试的心态,我更换了另外一套常用用户名字典,打算在爆破最后一次就结束,系统不负我,爆破到4000+的时候,终于出来一个返回包不一样的请求,可以看到payload为001。

在系统上测试一下。

确实存在该用户名,但是密码我们不知道啊,接下来采用了密码爆破的方式,但是这次好运不再眷顾我,我的各种密码字典均无果,我又陷入了对人生的大思考中,正当没思路的时候,突然想起当初该系统厂家来我司进行部署的时候,送了一份电子版的使用手册,于是打算通过手册看一下是否存在默认密码之类的,通过手册找了好久,终于在最后一页修改密码处发现以下内容:默认系统密码为000000,请在登录后立即修改默认密码。如有问题请及时联系。

赶紧在目标系统上试了一下,bingo,登陆成功。

接下来就是对其他400多个目标挨个进行爆破,但是手动爆破太慢,于是通过python写了一个脚本,对ok.txt进行遍历,逐个爆破。

吃完我的两个螃蟹,爆破结果也出来了,共有60+网站采用了001,002,003用户名与默认密码,随机挑了3个IP做了漏洞复现。

结果

整理了一下结果,并形成文档上传到CNVD漏洞平台。

CNVD也是很给力,一周就通过了审核。

因为是通过公司的CNVD账号提交的,不方便漏出漏洞编号,望各位师傅谅解。