记一次webshell被上传溯源事件 – 作者:lidasimida

前言

早上,我突然被客户告知,他部署在云平台的服务器被检测到webshell,已经查杀了,而且云平台检测到这个ip是属于我公司的地址,以为是我们公司做了测试导致的,问我这个怎么上传的webshell,我当时也是一脸懵逼,我记得很清楚这是我的项目,是我亲自测试的,上传点不会有遗漏的,然后开始了我的排查隐患工作。

巡检查杀

首先,我明白自己要做的不是找到这个上传的位置是哪里出现的,我应该登上服务器进行webshel查杀,进行巡检,找找看是否被别人入侵了,是否存在后门等等情况。虽然报的是我们公司的ip地址,万一漏掉了几个webshell,被别人上传成功了没检测出来,那服务器被入侵了如何能行。所以我上去巡检了服务器,上传这个webshell查杀工具进行查杀,使用netstat -anpt和iptables -L判断是否存在后门建立,查看是否有挖矿程序占用CPU,等等,此处不详细展开了。万幸的是服务器没有被入侵,然后我开始着手思考这个上传点是怎么回事。

文件上传漏洞回顾

首先,我向这个和我对接的研发人员咨询这个服务器对外开放的地址,要了地址之后打开发现,眼熟的不就是前不久自己测试的吗?此时,我感觉有点懵逼,和开发人员对质起这个整改信息,上次测试完发现这个上传的地方是使用了白名单限制,只允许上传jpeg、png等图片格式了。当时我还发现,这个虽然上传是做了白名单限制,也对上传的文件名做了随机数,还匹配了时间规则,但是我还是在返回包发现了这个上传路径和文件名,这个和他提议要进行整改,不然这个会造成这个文件包含漏洞,他和我反馈这个确实进行整改了,没有返回这个路径了。

文件后缀编码绕过

讨论回顾完上次整改的问题之后,理清了思路。然后我登录了网站查看一下原因,因为网站只有一个上传图片的地方,我进行抓包尝试,使用了repeater重放包之后,发现返回包确实没有返回文件上传路径,然后我又尝试了各种绕过,结果都不行。最后苦思冥想得不到结果,然后去问一下这个云平台给他们提供的这个告警是什么原因。看了云平台反馈的结果里面查杀到有图片码,这个问题不大,上传文件没有执行权限,而且没有返回文件路径,还对文件名做了随机更改,但是为啥会有这个jsp上传成功了,这让我百思不得其解。

当我仔细云平台提供的发现webshel数据的时候,我细心的观察到了文件名使用了base64编码,这个我很疑惑,都做了随机函数了还做编码干嘛,上次测试的时候是没有做编码的。我突然想到了问题关键,然后使用burpsuite的decoder模块,将文件名“1.jsp”做了base64编码成“MS5Kc1A=”,然后发送成功反馈状态码200,再不是这个上传失败反馈500状态码报错了。

所以,这个问题所在是,在整改过程中研发人员对这个文件名使用了base64编码,导致文件名在存储过程中会使用base64解码,而我上传文件的时候将这个后缀名.jsp也做了这个base64编码,在存储过程中.jsp也被成功解码,研发没有对解码之后进行白名单限制。其实这种编码的更改是不必要的,毕竟原来已经做了随机数更改了文件名了,再做编码有点画蛇添足了,这就是为啥程序bug改一个引发更多的bug原因。

来源:freebuf.com 2020-09-29 11:26:02 by: lidasimida

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论