浅谈常见edu漏洞，逻辑漏洞➡越权➡接管➡getshell，小白如何快速找准漏洞
渗透测试
之前闲来无事承接了一个高校的渗透测试，测试过程中没有什么复杂的漏洞，是一些基础的edu常见漏洞，适合基础学习，于是整理一下和师傅们分享。
今年对某高校进行了渗透测试，发现了一些比较经典的漏洞，写一下和师傅们一起分享。 1.教务系统登录处短信轰炸 -------------  学校的教务系统登录处，发现有一个手机验证码认证  这里会发送一个验证码 正常来说，每发送一次短信验证码，这个校验码就会自动更新一次，然后会报错：“验证码错误”。 但是这里抓包之后，发现能抓到两个数据包  这是第一个数据包，可以发现是对验证码的验证，我们把第一个数据包通过之后，拿到第二个数据包：  可以看到我们的手机号出现在了第二个数据包中 我们点击放到repeater，然后点击send，可以发现一直发送：  **原理**：正常来说校验码的验证和发送短信应该是在同一个数据包中，这里不严谨的设置，将校验码的验证和发送短信的数据包分成了两个，我们输入正常的验证码，通过第一个验证的数据包，拦截第二个发送短信的验证码，即可实现短信轰炸。 这里分享一下短信轰炸的几种绕过方式： #### 1.手机号前面加空格进行绕过 这是挖某专属src时遇到的  account为手机号，正常情况下，一个手机号短时间内只能发送一条验证码。 在account中的手机号前面每加一个空格可以突破限制进行多发一次验证码，  burp设置两个载荷 第一个载荷用于填充空格，设置为50（这样设置，一个手机号就可以发送成功50条短信） 第二个载荷用于循环遍历手机号，可以设置遍历10万甚至更多的手机号 #### 2.加字母等垃圾字符绕过或者+86 #### 3.伪造XF头 2.校内某实训平台任意用户注册、任意用户登录、修改任意用户密码、验证码爆破 -------------------------------------  这是校内某实训平台，我们先点击注册功能点。  我们点击获取验证码，然后进行抓包：  可以看到手机号被编在了url里，我们这里使用“,”去拼接手机号，这样就可以把验证码同时发送给两个手机号，并且收到的验证码相同。好比我知道你的手机号，拿你手机号去注册，我根本不需要知道你的验证码，因为验证码也会发到我手机上。   修改密码功能点也是相同，我这里不进行过多赘述 #### 验证码爆破  正常发送验证码，然后在填写验证码的地方，随意输入四位数   可以看到在7710的时候，长度不一样，成功登录进去了。 **修复建议：**：对验证码输入次数进行限制 3.越权查看所有学生和教职工个人信息，数万条记录 ------------------------  教务系统个人中心处有一个查看最近登陆记录的功能点，发现右上角有个查询，我们抓包尝试：  可以看到这里可以看到我们的登陆情况，我们尝试去修改value的值，看看能不能直接越权查看别人的登录信息。但是发现无论修改成什么都会提示登录信息错误。 修改成0、1、-1都不可以，但经过我的尝试发现，只有一个值可以，那就是null！ 我们让value=null  但是登录的记录明显有点少，而且观察发现好像都是登录失败的记录，这时我发现有个name字段，我把userid改成\*：  拿下所有学生和教职工的个人信息，包括姓名、手机号、身份证号、学号、教职工编号、登录ip等 4.教务系统绕过手机验证码换绑手机号 ------------------  也是这个教务系统，安全中心有一个换绑手机号的功能点，我们点击发送验证码  这里可以看到是修改195开头的那个手机号，然后我们forward  之后弹出一个验证码，我们输入验证码点击确定  这里的验证码就做的很好，和发送短信的验证码数据包放在一起了，杜绝了短信轰炸。但是我们这里把195开头的手机号修改成我自己的手机号。  成功让自己的手机号收到验证码，以为皆大欢喜了，结果。  显示验证码错误，这是为什么呢？ 我们继续审一下错误的数据包，也就是我们抓输入完短信验证码，点“下一步”的那个数据包  可以看到居然在“下一步”的地方，对手机号又进行了一次验证，我们将这里的phone改成我自己的手机号，然后forward  成功到达绑定新手机的界面，成功绕过了验证码认证，可以换绑任意用户的手机号。 5.校内某平台druid未授权访问，导致泄露用户session，可以实现任意用户接管 ------------------------------------------  这是校内的一个实习平台，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  然后刷新页面：  可以发现直接接管了别人的账号，登录进了系统。 6.内部系统存在sql注入导致rce ------------------  学校新出的一个平台，还是挺重要第一个平台，负责校内事务和档案的，应该还是个通用，很多学校都购买了这个平台。 我在那个平台抓包的时候，这个数据包偶然出现在我的burp里，我一看，居然直接把sql语句写出来了，这不就可以直接利用了吗？  直接执行select user，可以看到右边直接进行回显了。那个user字段的内容就是回显的。 后来我写报告的时候，怎么找也找不到这个包在哪抓的，没办法，只能转化思路去找js接口。  可以看到这个data里有sql:t 成功找到了这个接口，然后还有意外收获！   找到了近400个接口，这400个接口基本上都和上面的一样，直接写出了sql的语句，都可能存在sql注入！ 那么多接口，第一想法就是爬出来测一下未授权和越权。 然后写了个爬虫python脚本去爬js ```php 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")) ``` 爬出来之后，使用正则去检索我们所需要的东西： ```php 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的语法差不多。 ```php select table_name from information_schema.tables where table_schema='' ```  成功注入。然后在征得校方同意后，可以使用postgresql数据库的集成利用工具直接进行rce。 至此，渗透告一段落。 注：严禁未拿到授权就进行渗透测试
发表于 2025-04-23 11:48:33
阅读 ( 1873 )
分类：
渗透测试
4 推荐
收藏
2 条评论
薛定谔不喜欢猫
1 篇文章
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
