0x01 描述

实战中遇到了2次这种绕过场景，第一次并没在意，以为可能是对面的waf或者部署方面有一定的问题
，然后第二次也是同样方法，遂记录一下

0x02 第一次

1】是一次攻防演练中，一些扫描无果后，手工去排查一些网站，在排查到weblogic资产的时候，发现目标会在识别到一些敏感路径时回包reset，感觉有戏，因为(个人看法)存在这种waf，部分甲方本地自己人或者请乙方安全公司去进行安全测试时，如果在发现waf后，因为一些部门可能并不相通不好找人加白或者奇怪的心理(还要加白？是不是你们能力不行？)，很少会获得waf白名单的权利，而对waf开启状态的目标网站进行测试时，测试人员其实并不会去深究waf的绕过这些，最后获得结果就是: 漏洞存在，但测试结果是没有这个漏洞，获得网站安全的表面现象。

2】废话一箩筐凑字数别介意，然后就各种想办法，无果后，理了一下这个waf的拦截逻辑是：访问的url路径中存在历史漏洞中出现的漏洞利用路径就会重置链接，不针对weblogic，随便的利用链接像.svn这种也会拦，也就是说他是所有漏洞的利用url的黑名单，访问路径在黑名单内即重置链接。

3】求助了没什么好办法，想到sql注入有的场景是垃圾填充这些办法嘛，然后试着构造了超大的cookie包，大概是服务器本身就会拒绝链接的那种长度再短一点，发包后，哈哈，还是拒绝链接，不过他拒绝的比较慢，又想了一会，我想着再暴力一点，写了个多进程python脚本，附上weblogic漏洞利用的请求包带超大cookie的，然后100进程开启，过了10分钟收到了状态码200的回显，至此waf就过了

4】不过后面也很麻烦，负载均衡什么的，哈哈，设备多还是强的，后来演练结束后我去了解了一下目标的waf产品，是某明的天清xxx，当时觉得2种原因:可能是目标部署位置有问题导致有漏包，也可能是waf本身的一些设计问题或者版本不是最新，并没认为以后还会碰到这种绕过案例。

0x03 第二次

  • 第一天
    然后过了xx时间后，是帮朋友的一次不知道啥行动中，发现目标存在nc，bsh.servlet.BshServlet那个页面，那不直接就shell了，结果发现waf，逻辑是post包中存在 bsh.script= ，就无法访问，虽然bp上不是直接显示reset，但是差不多，也是个白页面那种，绕了会也没绕过去，也是构造了个大包去跑，大包啥格式忘了，然后跑了10来分钟也没结果就关了
  • 第二天
    第一天收集了了一些资产，因为目标不少，就想着慢慢来，然后还是对那个nc不死心，去查了一下IBM的httpserver怎么解析http包，得知是提交多个相同还是不相同无法解析的参数时，最后一个参数是结果，具体并没理解，我只确认一件事是最后一个参数是漏洞参数就行了，然后弄个cookie大包，漏洞参数前放了其他的超大参数后120进程开跑，然后就去看其他资产了

    过了不知道多长时间，只记得按小时计算，期间隔一段时间就看看发包结果，一直跑，最后下午6点左右吧，发现了有200回包，心中甚是欢喜，然后改成执行命令的post包，继续跑，然后几分钟很快就跑出来了，root权限，然后给朋友要了服务器ip，弹了shell。

0x04 1111

    废话一堆，描述了一下心理活动，就是贫，有的时候吧，用一些时间做成了什么事情的时候很开心，很希望有个人可以分享，然后能一起开心，57uI56m25LiN6L+H5aWi5pyb572i5LqG77yM5pyJ55qE5Lq65oeS5b6X55CG5L2g77yM5pyJ55qE5Lq65oiW6K645Lya6auY5YW05LiA5LiL77yM5pyJ55qE5Lq65YW25a6e5LiN55+l6YGT5L2g5Zyo6K+05Liq5ZWl77yM5Zia5Zia6L+H5aS05LqG77yM5omA5Lul5ZGi77yMKioq55qE5a2m5bCx5a6M5LqL5LqG77yM5oGi5aSN5a2m5Lmg6YCf5bqm77yM5omp5bGV55+l6K+G5L2T57O75ZKM5rex5bqm77yB

    1.cookie和提交参数垃圾填充+多线程疑似通用办法
    2.个别服务器配置或者waf产品配置过高，需要一些时间才能生效
    3.构造的包别影响最终解析