`
19841026
  • 浏览: 59938 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

Java网站安全攻与守(惊魂24小时)

 
阅读更多
  人怕出名猪怕壮,在互联网领域也是一样的道理,在行业里一旦有所名气和成绩,里面是被各自攻击和破解的对象,如果是重C端的产品,基本是90%的可能性会被破掉,只是早晚的问题,代码都部署在C端了,无论再怎么加密,招式都是固定的了,一旦被看穿就基本宣判死刑了。重S端的产品则更多的是被攻击,不是要流量吗,那好各自CC,DOS肉鸡噎死你!至于破解,就是双方攻与守的持续站。我们目前的产品是款BS和CS相结合的产品,去年下半年开始在业内做出了一点小小的成绩和口碑,结果从去年12月份开始,一波黑客开始持续的上木马开始破解S端,整整3个月的时间,我们双方相互的攻与守,直到今天,我们分析出了对方每一次的进攻方式,暂时还保持着安全!这里主要讲讲对方是如何攻,我们又是如何守的。
  我们的S端是基于采用JSP开发的产品,对于这种JSP和ASP动态产品的破解,最有效的攻击方式就是上JSP或ASP木马,一个JSP实质上就是一个Servlet,只要能将JSP木马留存在运行目录里,就能为所欲为,一个JAVA.IO.RUNTIME命令基本就能通过CMD BAT命令将整个服务器的一切需要的信息拿下,包括创建临时RDP登陆用户,所以只要你的产品必须在后端做校验。
  在做BS或CS项目时,有一条看着很没有道理的开发原则:“永远不要相信前端”,这句话看着好像是在破会团队团结,实则是提醒后端在开发时需要更加注意安全和异常错误的校验。我们早期是做百度流量推广的,需要做很多网站的自动化实现,我们也是一个C端,但并不是官方的B端,通过抓包模拟请求就可以实现相同的功能,但如果后端想着有前端校验就行了,一些校验依赖前端不去做,有时候是会出很大的问题的,比如微信2个非常著名的bug, 一个是新菜鸟团队早期利用微信通讯录不做好友匹配和推送添加上限的bug,想着一部手机也就最多上千的联系人,结果利用这里漏洞通过通讯录刷新刷好友!还有一个就是果然叼的朋友圈@好友功能,微信前端限制的是一条朋友圈只允许@10个好友,结果绕开前端校验,模拟请求里将相关参数直接改成3000,一条朋友圈就能@3000好友!
回到我们自己的产品,这波黑客就是利用我们在上传服务时没有对参数做严格的校验机制,通过伪造参数直接量jsp目录上传到服务器应用目录里,上传后如果不及时发现,基本整个应用文件目录和相关的信息都会被慢慢被传走。下面是一段jsp木马的截图,可以看到各种遍历创建下载文件的方法,他只要通过域名访问到对应的jsp文件,传递相关的参数就能调用对应的方法,因为jsp实际上就是一个Servlet

防御这种木马的方法当然就是堵住上传的相关漏洞,在相应的上传方法里做严格的校验机制,于是这种木马解决了,后续陆续又在其他类似的地方出现过1-2次,都被我们发现后一一堵上!其实对于这种利用上传漏洞留存木马的攻击方式,最好的防御方式就是通过第第三方直传服务,比如阿里云的OSS服务,直接将所有的上传下载服务通过第三方服务实现,中间不会有任何中间素材留存在自己的服务器上,甚至直传对服务器的流量都不会产生。
于是消停了一端时间,到昨晚在执行例行检查时,突然发现工程跟目录多了几个jsp文件,一看就是木马,于是马上登陆阿里云去查杀木马,结果阿里云的云顿都被对方给干掉了,当时想着这不太可能啊,所有的上传漏洞都被堵上了,于是立马在web服务器里查看相关的木马访问日志,找到了如下的请求日志:


瞬间懵逼了,这不太可能,这样也行!反正当晚想了一晚上,晚上做梦都梦到了木马文件,
也没想明白这是如何实现的!既然找不到来源,那只能采取临时解决方案,如果不采取解决方案,光删几个木马文件是没有卵用的!简单分析下就能获取很明显的参数特征,于是马上和团队在请求过滤器里写参数判断,只要有类似的参数特征直接在过滤器里拦截过滤,跳转到登陆页面!第二天起来翻阅相关的攻击日志,果然又来了,前面几条就如我们设想的一样被拦截跳转到302了,估计对方也意识到了,马上来了条不太任何参数特征的测试请求,结果正常过去了,但不会产生任何效果。这波人估计也是意识到我们堵住了所有通道,没什么其他办法了,   他们将昨晚木马文件创建的临时用户直接用上了,于是阿里云报警了,5-10分钟后我们就kill掉了这个所谓的k8team用户,后来查了下,也就确认了昨晚对方的攻击方式:Struts最新漏洞!具体可以参看如下漏洞介绍:
http://www.chinaz.com/server/2017/0310/671333.shtml
其实和之前的2.3.15漏洞类似:具体可以看下这篇介绍:
http://www.cnblogs.com/Fluorescence-tjy/p/5861970.html
原理就是利于参数转义,然后被OGNL这货识别,然后通过java.lang.Runtime.getRuntime()执行各自CMD命令。于是昨晚的请求也就不难理解了,只是没想到Struts又出现了这种漏洞,我们昨晚临时做的防御工作,其实很里面介绍的方式原理大致都是类似的,过滤器拦截参数行为特征,当然也得赶紧更新Struts2到安全版本!
另外,手机一定要绑定到阿里云的账号上,这样一旦云顿识别到木马或报警时,能立马通知到你!
最后补充说明下,为什么这伙黑客前后3个多月的时间不断攻击,而且有几次也成功入侵了,但始终都没有破解成功!如果是早几年的架构模式,也就早就被破了!现在的java应用大多都采用松耦合的架构方式,将整个项目拆分成很多独立的模块,便于开发,其实也无形中增加了黑客破解的难度,以前只要破解1个模块的,现在可能要破解5个或者更多模块才能完整破解,虽然我们目前的产品没有很严格的按照这种方式去做,但也基本是这个思路,整个项目,在S端就分成了5个独立的模块,在C端也有2个模块,所以黑客这么长时间也没能完整破解掉现有的系统!
今天守了一整天,不断去分析访问日志,阿里云顿查杀,对方也在13:45最后一次尝试后,放弃了攻击!在守了2天1夜后也终于能放心的回去睡个好觉了!
  • 大小: 22.5 KB
  • 大小: 18.3 KB
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics