webshell被上传溯源事件的示例分析

这篇文章将为大家详细讲解有关webshell被上传溯源事件的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

创新互联建站是创新、创意、研发型一体的综合型网站建设公司，自成立以来公司不断探索创新，始终坚持为客户提供满意周到的服务，在本地打下了良好的口碑，在过去的十余年时间我们累计服务了上千家以及全国政企客户，如成都VR全景等企业单位，完善的项目管理流程，严格把控项目进度与质量监控加上过硬的技术实力获得客户的一致赞美。

巡检查杀

首先，我明白自己要做的不是找到这个上传的位置是哪里出现的，我应该登上服务器进行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原因。

关于“webshell被上传溯源事件的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。

文章标题：webshell被上传溯源事件的示例分析
路径分享：http://scjbc.cn/article/jscodg.html