记一次曲折的渗透测试

本次渗透测试为授权测试,信息皆做脱敏处理

拿到网站,其中一个资产为该单位办公系统,看到界面比较老,感觉有戏,

所用系统为九思oa,先去搜一下已公开的poc看看能不能去打

image-20220601201826085

image-20220601201838486

搜到了两个,尝试无果,就把所有资产都丢进awvs里扫一下,抱着试一试的心态去看看能不能扫出东西来

image-20220601202119547

发现此处存在sql注入,可执行sleep语句,就去抓个包,尝试用sqlmap一把梭

1
python sqlmap.py -r 1.txt --dbs

发现跑不出来,想找原因,就去手工测试了一下

image-20220601202838143

在输入admin的时候提示是该用户没有维护邮箱,但是应该存在该用户

image-20220601202936200

加’发现报错提示没有该用户信息

image-20220601203220876

加了#号之后和单独输入admin一样,那就证明其存在sql注入,通过fuzzy,发现其过滤了空格。

尝试用sqlmap的temper脚本去绕过

1
python sqlmap.py -r 1.txt --tamper=space2comment -dbs

果然成功了

image-20220601204755423

想要通过sql注入注出账号密码

image-20220601205449309

jsdb的md5解密后为12345678

root的md5解密后为jiusiimage-20220601205558917

用御剑扫描其端口发现其数据库端口并未开放,只能作罢,去寻找其他思路image-20220601205837781

尝试去写一个webshell进去,发现也失败了,权限不够,而且不知道绝对路径

那就尝试去注出网站的账号密码,登入试试看看能不能getshell。

此时问题又来了,我们不知道账号密码在那个表里,而且由于是盲注,速度比较慢,一个oa里有几百张表,一个表里有几十个字段,也来不及一个一个试,此时又陷入了僵局。

我们继续去扫描该单位站点,发现该单位还有一测试的九思oa站点,且端口开放为3306,猜想之前注出的数据库密码jiusi为该数据库的密码,直接用Navicat去连接,

发现其表的结构如下image-20220604204710499

有几百张表(幸亏没跑盲注),通过该表的结构,去构造相应的sql语句(利用sqlmap的sql-shell来执行),成功把管理员以及其他用户的账号密码注了出来,数据库的密码并非用明文储存,

image-20220604205152908

注出一串39位的字符,并非md5,通过对前端代码进行分析,发现其先进行了md5加密,然后交给后端处理,一定是后端又进行了加密,在网上搜到了该oa的部分源码,对其加密算法进行逆向,得出如下结果,需要舍弃固定位数,再对字符串进行重拼,即可得到相应的md5值,然后尝试去md5解密,可惜的是没把管理员的md5给破解出来,破解出来了一些普通用户的密码,然后登入。

image-20220604205334611

进入oa,看看有没有上传点,尝试上传,发现其过滤了.jsp文件后缀,且为白名单上传,尝试了几个姿势,无法绕过。

通过指纹识别发现其利用了eweditor组件,尝试用默认密码登入,发现可以进去,把图片类型给加一个jsp,尝试上传

image-20220604205741782

上传成功

image-20220604210209773

image-20220604210430090

成功rce,接下来就传个好用点的马去内网漫游


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!