浅谈常见edu漏洞，逻辑漏洞、越权、接管、getshell，小白如何快速找准漏洞

学校的教务系统登录处，发现有一个手机验证码认证

这里会发送一个验证码
正常来说，每发送一次短信验证码，这个校验码就会自动更新一次，然后会报错：“验证码错误”。
但是这里抓包之后，发现能抓到两个数据包

这是第一个数据包，可以发现是对验证码的验证，我们把第一个数据包通过之后，拿到第二个数据包：

可以看到我们的手机号出现在了第二个数据包中
我们点击放到repeater，然后点击send，可以发现一直发送：

原理：正常来说校验码的验证和发送短信应该是在同一个数据包中，这里不严谨的设置，将校验码的验证和发送短信的数据包分成了两个，我们输入正常的验证码，通过第一个验证的数据包，拦截第二个发送短信的验证码，即可实现短信轰炸。

这里分享一下短信轰炸的几种绕过方式：

1.手机号前面加空格进行绕过

这是挖某专属src时遇到的

account为手机号，正常情况下，一个手机号短时间内只能发送一条验证码。

在account中的手机号前面每加一个空格可以突破限制进行多发一次验证码，

burp设置两个载荷

第一个载荷用于填充空格，设置为50（这样设置，一个手机号就可以发送成功50条短信）

第二个载荷用于循环遍历手机号，可以设置遍历10万甚至更多的手机号

2.加字母等垃圾字符绕过或者+86

3.伪造XF头

这是校内某实训平台，我们先点击注册功能点。

我们点击获取验证码，然后进行抓包：

可以看到手机号被编在了url里，我们这里使用“,”去拼接手机号，这样就可以把验证码同时发送给两个手机号，并且收到的验证码相同。好比我知道你的手机号，拿你手机号去注册，我根本不需要知道你的验证码，因为验证码也会发到我手机上。

修改密码功能点也是相同，我这里不进行过多赘述

验证码爆破

正常发送验证码，然后在填写验证码的地方，随意输入四位数

可以看到在7710的时候，长度不一样，成功登录进去了。

修复建议：：对验证码输入次数进行限制

教务系统个人中心处有一个查看最近登陆记录的功能点，发现右上角有个查询，我们抓包尝试：

可以看到这里可以看到我们的登陆情况，我们尝试去修改value的值，看看能不能直接越权查看别人的登录信息。但是发现无论修改成什么都会提示登录信息错误。

修改成0、1、-1都不可以，但经过我的尝试发现，只有一个值可以，那就是null！

我们让value=null

但是登录的记录明显有点少，而且观察发现好像都是登录失败的记录，这时我发现有个name字段，我把userid改成*：

拿下所有学生和教职工的个人信息，包括姓名、手机号、身份证号、学号、教职工编号、登录ip等

也是这个教务系统，安全中心有一个换绑手机号的功能点，我们点击发送验证码

这里可以看到是修改195开头的那个手机号，然后我们forward

之后弹出一个验证码，我们输入验证码点击确定

这里的验证码就做的很好，和发送短信的验证码数据包放在一起了，杜绝了短信轰炸。但是我们这里把195开头的手机号修改成我自己的手机号。

成功让自己的手机号收到验证码，以为皆大欢喜了，结果。

显示验证码错误，这是为什么呢？

我们继续审一下错误的数据包，也就是我们抓输入完短信验证码，点“下一步”的那个数据包

可以看到居然在“下一步”的地方，对手机号又进行了一次验证，我们将这里的phone改成我自己的手机号，然后forward

成功到达绑定新手机的界面，成功绕过了验证码认证，可以换绑任意用户的手机号。

这是校内的一个实习平台，url为“https://xxx.edu.cn/shixi/”

然后之前读文章读到了一个druid的未授权拼接，// druid //

于是尝试拼接 ：“https://xxx.edu.cn/shixi/druid/index.html”

可以看到是有druid的未授权访问，这里会泄露很多东西，比如数据库信息，数据库查询语句、访问记录等等。我们这里搞一下session。

可以看到有一个session监控：

可以看到这里有登录过系统的用户的session，我们要做的就是把session收集起来。这里我有个比较好用的方法，可以ctrl+a复制全页，然后粘贴到excel里，然后选中session列，就可以快速的把session复制到txt里了。

可以看到我们把session这样收集到了txt里，然后打开yakit

把txt导入到yakit的pyload里，然后去抓一下登录窗口的数据包：

可以看到cookie有个jessionid，我们把他的值设置成标签，然后去拼接刚才的session的payload去批量访问：

可以看到有很多200成功访问的，也有一些无法访问的，无法访问的原因主要是因为session是具有时效性的，长时间后这个session可能就会失效，但是只要源源不断的访问这个系统，我们就可以源源不断的盗取新的session。

我们找一个200正常访问的数据包，把里面的session复制下来。

然后回到网页，打开f12里的存储，替换里面的jsessionid

然后刷新页面：

可以发现直接接管了别人的账号，登录进了系统。

学校新出的一个平台，还是挺重要第一个平台，负责校内事务和档案的，应该还是个通用，很多学校都购买了这个平台。
我在那个平台抓包的时候，这个数据包偶然出现在我的burp里，我一看，居然直接把sql语句写出来了，这不就可以直接利用了吗？

直接执行select user，可以看到右边直接进行回显了。那个user字段的内容就是回显的。

后来我写报告的时候，怎么找也找不到这个包在哪抓的，没办法，只能转化思路去找js接口。

可以看到这个data里有sql:t

成功找到了这个接口，然后还有意外收获！

找到了近400个接口，这400个接口基本上都和上面的一样，直接写出了sql的语句，都可能存在sql注入！

那么多接口，第一想法就是爬出来测一下未授权和越权。
然后写了个爬虫python脚本去爬js

import requests  
import re  
# #proxy={'https':'127.0.0.1:8080'}  
# url=""  
# headers = {  
#     'cookie':'',  
#     'User-Agent':'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0',  
#     'Username':'',  
#     'Accept':'*/*',  
#     'Te':'',  
#     'Priority':'u=',  
#     'Sec-Fetch-User':'',  
#     'Sec-Fetch-Site':'',  
#     'Sec-Fetch-Mode':'',  
#     'Sec-Fetch-Dest':'',  
#     'Upgrade-Insecure-Requests':'',  
#     'Referer':'',  
#     'From':'dzj-pc'  
# }  
# def get_html(url):  
#     res = requests.get(url = url,verify=False,headers=headers,allow_redirects=False)  
#     # return res.content  
# #  
# html = get_html(url = url)  
# print(html.decode("utf-8"))

爬出来之后，使用正则去检索我们所需要的东西：

file = open('C:/Users/xxx/Desktop/111.txt','r')  
lines = file.read()  

apis=re.findall("url:\"(.*?)\"",lines)  
for api in apis:  
    if '?' in api:  
        print(api.split("?")[0])  
    else:  
        print(api)

. 表示除n r 之外的任意单个字符
* 匹配零次或者多次
? 指定为非贪婪模式

然后我们将收集到的api，放到burp里去批量访问

但是没有跑出来，应该是没有未授权漏洞，做了全局验证，逐个删除cookie字段，但还是不行，没有cookie就被深信服的设备拦住了。

那我们回到最开始的sql注入，该如何扩大危害呢？
首先我们要判断数据库类型，于是我继续看js

一开始看到了from dual，我以为是oracle数据库，然后尝试了oracle数据的sql语法，发现总是报错。
后来再翻js数据包的时候，发现了这个包：

这个数据包不仅直接暴露了usr_bsp，重要的是告诉了我们这个是postgresql数据库，这个数据库不太了解，我去百度了一下sql语法。发现他和mysql的语法差不多。

select table_name from information_schema.tables where table_schema=''

成功注入。然后在征得校方同意后，可以使用postgresql数据库的集成利用工具直接进行rce。

至此，渗透告一段落。

注：严禁未拿到授权就进行渗透测试