从hw打点到编写python版webshell提权

robots

 

摸到一个某信息管理平台

开局一个登录框,那么尝试sql注入和弱口令爆破,从返回包中可以看出存在用户名枚举

尝试注入测试发现后端存在检测,试了几十个常见的测试手机号还无法枚举到用户名后,遂放弃此路

通过报错页面的信息,和url格式,我当时判断的是这是一个 java mvc模型的站点,也给后面埋了个坑

于是开始翻看静态资源,熟悉的文件名格式,确认过眼神,这是vue的资源

根据以往的经验,VUE项目的关键代码存在于生成的以app开头的js文件中,所以通常遇到vue项目的目标,只需翻看其app开头的js文件,即可通过其内容大致了解到它的功能点。

于是打开那个app开头的js文件,我个人是非常喜欢将js代码粘贴到Pycharm里面,然后按 Ctrl + Alt + L 来格式化代码,再慢慢的审阅寻找线索。

经过仔细的查看js代码,发现一处疑似后台主页的跳转url

直接粘贴至浏览器打开,进到了一个后台页面

在熟悉它里面的功能点时,发现这只是一个框架页面,跟后端交互获取数据时仍需要验证用户身份

于是我灵机一动,猜测 url的company_id提交的可能就是用户凭证,所以直接在Pycharm使用字符串查找功能查找,没想到真的找到了一串md5值,看起来像是凭证,大喜之后将其补上到url后再访问

获得了一个用户身份的后台(看右边的成员和部门那里已经与前面不同)

但继续摸功能点后,发现只是个测试用户的身份

找到一处上传点,但是上传过去发现没有数据包响应

于是查看浏览器控制台信息,发现是被同源策略给限制了,那么这里通过功能点直接上传是行不通的,除非你通过他的域名访问,我这里反查了ip查不到对应的域名

这个时候可以手动构造文件上传表单, 然后浏览器打开上传

发包过去之后,是我天真了

报了一个404回来,开始怀疑人生当中,不过后面想了想,我刚才访问的是82端口,提交上传的接口是8082端口,难不成这里面有问题?本着死磕到底的精神,我颤抖的手敲了敲键盘,在burp的重放功能那将8082端口改为了82端口,再尝试发包

回包果真不一样了,貌似是被后端接受了,但是却没有返回上传成功的文件路径,我怀疑是没有上传成功

于是掏出了我的大*,不对,是我的祖传字典,用于测试上传文件对象的键名

我晕,原来上传的文件对象键名就是 file

将文件字典键名改为file, 文件名改为 .jsp后缀再上传,成功上传了

于是赶紧上传个冰蝎的webshell,发现被拦了,难不成存在waf ?

那么先上传个打印字符串的短小代码,发现上传成功了也顺利访问了可是却不解析???

我尼玛直接怀疑人生,这不是tomcat应用服务器吗,怎么可能不解析jsp

后面在测试其他文件名时,

发现解析php,这就离谱,tomcat + php还有这种搭配?麻烦搞懂的朋友告诉我

蚁剑链接之,发现是 apache权限,内核3.10

其实这个时候通常都是上代理打内网的了,不过后面遇到了更诡异的事,我上传了frp 客户端做代理时,发现连接到服务端后几十秒就断了,再查看文件时,权限已经变成了 000

看来是应该有某种防护软件?这是块硬骨头啊

然后开始打算提权,一般提权通用性比较高的就是内核提权,但是不太建议这种提权方式,因为溢出类的内核提权都有一定的偶然性,容易把服务器打宕机

查看了下进程,很惊喜的发现python 以root权限运行了一个程序,有着django开发经验的我一眼就看出了这就是django,

然后访问其8000端口,是一个 swagger 接口页面。

这时随便访问个不存在的路由

通过报错信息得知这真的是django,并且开起了debug功能,开启后修改源代码会自动重启应用

心中大喜直接奔去寻找这个django项目的目录,很巧的是项目目录里的所有文件都具有777的权限,所以能改写视图函数,我添加了红框中的代码,大致意思就是当访问 test/ 路由时,返回字符串 “Hello Django”

再去浏览器访问 test 路由,成功执行了我自定义的视图函数

于是这时候 python 版的webshell就出来了

去查看执行效果,ok提权成功

当我开始漫游时,问题又出现了,应该是流量特征太明显被 waf 拦了

然后我又把视图函数改了下,添加base64编码传输

完美

随便几行代码写了个方便点的利用工具

本次外网打点到此结束,如有打码不严请勿复现

(完)