随心所记 网络安全 常见面经&个人理解
随心所记 网络安全 常见面经&个人理解
前言
本篇笔记将会长期更新,用于我本人对目前行业内讨论的比较多的一些常见面试题进行的整理以及部分个人理解,希望通过总结整理提高我对目前比较火的经典漏洞的认识。随着笔记规模的增大,会增加目录,后期也会根据不同类型对题目进行必要的分类。本篇笔记大部分资源和数据都来源于互联网,经过本人的多角度检索最终得出,在这里真诚地感谢先驱师傅们!本篇笔记可能有的地方会出错,希望大家一起批评指正,感谢朋友们,希望我们共同进步。
Apache Shiro
Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API,您可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。
介绍
Shiro的反序列化漏洞非常经典,也非常火,一看到这个脑子里瞬间想到“550”和“721”两个数字,这两个数字其实没有特殊含义,也并不代表版本。
Shiro-550 rememberMe 反序列化漏洞
影响版本
Apache Shiro < 1.2.4
漏洞原理
Apache Shiro框架提供了记住密码的功能(RememberMe),用户登录成功后会生成经过加密并编码的cookie。在服务端对rememberMe的cookie值,先base64解码然后AES解密再反序列化,就导致了反序列化RCE漏洞。
那么,Payload产生的过程:
命令=>序列化=>AES加密=>base64编码=>RememberMe Cookie值
在整个漏洞利用过程中,比较重要的是AES加密的密钥,如果没有修改默认的密钥那么就很容易就知道密钥了,Payload构造起来也是十分的简单
Shiro-721 Padding Oracle Attack 反序列化漏洞
影响版本
Apache Shiro < 1.4.2
漏洞原理
由于Apache Shiro cookie中通过 AES-128-CBC 模式加密的rememberMe字段存在问题,用户可通过Padding Oracle 加密生成的攻击代码来构造恶意的rememberMe字段,并重新请求网站,进行反序列化攻击,最终导致任意代码执行。
Apache Struts2
Apache Struts2 是一个基于 MVC 设计模式的 JavaWeb 应用框架,它的本质就相当于一个 servlet,在 MVC 设计模式中,Struts2 作为控制器(Controller)来建立模型与视图的数据交互。Struts2 是在 Struts 和WebWork 的技术的基础上进行合并的全新的框架。Struts2 以 WebWork 为核心,采用拦截器的机制来处理的请求。这样的设计使得业务逻辑控制器能够与 ServletAPI 完全脱离开。
S2-001(OGNL 循环解析导致的 RCE 漏洞)
影响版本
Struts 2.0.0 - 2.0.8
漏洞原理
该漏洞因用户提交表单数据并且验证失败时,后端会将用户之前提交的参数值使用 OGNL 表达式 %{value} 进行解析,然后重新填充到对应的表单数据中。如注册或登录页面,提交失败后一般会默认返回之前提交的数据,由于后端使用 %{value} 对提交的数据执行了一次 OGNL 表达式解析,所以可以直接构造 Payload 进行命令执行。
S2-005(S2-003 的绕过)
影响版本
Struts 2.0.0 - Struts 2.1.8.1
漏洞原理
s2-005漏洞源于S2-003(受影响版本:低于Struts 2.0.12),struts2会将 http 的每个参数名解析为 OGNL 语句执行(可理解为java代码)。OGNL表达式通过#来访问 Struts 的对象,Struts框架通过过滤#字符防止安全问题,然而通过 unicode 编码(\u0023)或8进制(\43)就可以绕过安全限制。
对于S2-003漏洞,官方通过增加安全配置即沙盒机制(禁止静态方法allowStaticMethodAcces、MethodAccessor.denyMethodExecution调用和类方法执行等)来修补,但是攻击者可以利用OGNL表达式将 allowStaticMethodAccess设置为true,MethodAccessor.denyMethodExecution设置为false,就可以绕过这个沙盒机制导致S2-005漏洞。
S2-005漏洞是对S2-003漏洞补丁的绕过。
S2-007(验证类型转换错误时,会导致二次表达式解析)
影响版本
漏洞原理
S2-007漏洞一般出现在表单处,当配置了验证规则 <ActionName>-validation.xml
时,若类型验证转换出错,后端默认会将用户提交的表单值通过字符串拼接,然后执行一次 OGNL 表达式解析并返回。
例如下面这个 UserAction-validation.xml 验证表单
1 |
|
当用户提交 age 为字符串而非整形数值时,后端用代码拼接 "'" + value + "'"
然后对其进行 OGNL 表达式解析。要成功利用,只需要找到一个配置了类似验证规则的表单字段使之转换出错,借助类似 SQLi 注入单引号拼接的方式即可注入任意 OGNL 表达式。
S2-009 远程代码执行漏洞 (CVE-2011-3923)
影响版本
Struts 2.1.0-2.3.1.1
漏洞原理
Struts2 对 s2-003 的修复方法是禁止#号,于是 s2-005 通过使用编码\u0023或\43来绕过;后来 Struts2 对 s2-005 的修复方法是禁止\等特殊符号,使用户不能提交反斜线。
但是,如果当前 action 中接受了某个参数 example,这个参数将进入 OGNL 的上下文。所以,我们可以将 OGNL 表达式放在 example 参数中,然后使用 /helloword.acton?example=
S2-012 远程代码执行漏洞 (CVE-2013-1965)
影响版本
Struts 2.1.0 - 2.3.13
漏洞原理
重定向的路径中使用了 %{} 导致了的 RCE 漏洞
漏洞触发原理与 S2-001 类似,对 %{} 表达式进行了循环解析。
如果在配置 Action 中 Result 时使用了重定向类型,并且还使用 ${param_name} 作为重定向变量,例如:
1 |
|
这里 UserAction 中定义有一个 name 变量,当触发 redirect 类型返回时,Struts2 获取使用 ${name} 获取其值,在这个过程中会对 name 参数的值执行 OGNL 表达式解析,从而可以插入任意 OGNL 表达式导致命令执行。
S2-013/S2-014 远程代码执行漏洞 (CVE-2013-1966)
影响版本
Struts 2.0.0 - 2.3.14
漏洞原理
链接标签带入参数时导致的 OGNL 解析漏洞
Struts2 中使用链接标签 <s:a> 和 <s:url> 来渲染链接,使用 url 标签可以引入一个静态路径或 action ,使用 a 标签可以直接渲染一个 a 链接。
- none: URL中不包含任何参数(默认)
- get:仅包含URL中的GET参数
- all:在URL中包含GET和POST参数
当 includeParams=all 的时候,会将本次请求的GET和POST参数都放在URL的GET参数上。
拿本漏洞环境举例,index.jsp中有:
1 |
|
在放置参数的过程中会将参数进行OGNL渲染,造成任意命令执行漏洞。
注:includeParams=get也可以触发该漏洞。
S2-015 远程代码执行漏洞 (CVE-2013-2134, CVE-2013-2135)
影响版本
Struts 2.0.0 - 2.3.14.2
漏洞原理
S2-015 官方公告公布了两种漏洞利用方式,一种是通配符匹配 action ,一种是在 struts.xml 中使用 ${} 引用 Action 变量导致的二次解析。
第一种:在使用 struts2 时,每一个action 都需要配置, action 里面的方法以及其返回到的界面都需要配置,如果一个一个配置,就太麻烦了,因此可以约定一些命名规范,然后在 struts.xml 里面使用通配符进行配置。
在 Struts2 中可以使用通配符 * 来匹配 action,并使用 {1} 来获取 * 的值,这有点像正则的匹配模式,如下配置:
1 |
|
上述配置能让我们访问 name.action 时使用 name.jsp 来渲染页面,但是在提取 name 并解析时,对其执行了 OGNL 表达式解析,所以导致命令执行。漏洞原理跟S2-012类似,S2-012利用的重定向类型,S2-015利用的 Action 的名称。复现的时候发现,由于 name 值的位置比较特殊,一些特殊的字符如 / “ \ 都无法使用(转义也不行),所以在利用该点进行远程命令执行时一些带有路径的命令可能无法执行成功。
需要注意,在 Struts 2.3.14.2 中,官方将 SecurityMemberAccess 类中成员变量 allowStaticMethodAccess 添加了 final 修饰符,并且将其 set 方法进行了删除。这就导致了我们不能通过 #_memberAccess[“allowStaticMethodAccess”]=true 来改变其值,因为没有 set 方法了。但是至少有两种思路进行绕过:
使用反射修改其值:
1
#f=#_memberAccess.getClass().getDeclaredField('allowStaticMethodAccess'),#f.setAccessible(true),#f.set(#_memberAccess,true),
使用非静态方法调用 POC:
1
new java.lang.ProcessBuilder(new java.lang.String[]{"open", "-a","Calculator.app"}).start()
因此最终 payload 为:
1 |
|
第二种:
1 |
|
这里配置了 ${message},其中 message 为 ParamAction 中的一个私有变量,这样配置会导致触发该 Result 时,Struts2 会从请求参数中获取 message 的值,并在解析过程中,触发了 OGNL 表达式执行。这里需要注意的是这里的二次解析是因为在 struts.xml 中使用 ${param} 引用了 Action 中的变量所导致的,并不针对于 type=“httpheader” 这种返回方式。
直接提交 %{1+1} 或 ${1+1} 作为其变量值提交就会得到执行。
Apache Log4j
Log4j是Apache的一个开源项目,通过使用Log4j,我们可以控制日志信息输送的目的地是控制台、文件、GUI组件,甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等;我们也可以控制每一条日志的输出格式;通过定义每一条日志信息的级别,我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是,这些可以通过一个配置文件来灵活地进行配置,而不需要修改应用的代码。
影响版本
pache Log4j 2.0-alpha1 到 2.14.1(包括这些版本) Apache Log4j 1.2.19 到 1.2.20(包括这些版本)
漏洞原理
在Log4j2中提供了Lookups机制,Lookups提供了一种在Log4j配置文件任意位置添加值的方法;而Lookups机制中,存在JNDI,在Log4j日志输出时,未对字符合法性进行严格的限制,造成JNDI协议加载的远程恶意脚本被执行,从而造成RCE。
Java Fastjson
Fastjson是由阿里巴巴工程师基于JAVA开发的一款JSON解析器和生成器,可用于将Java对象转换为其JSON表示形式。它还可以用于将JSON字符串转换为等效的Java对象。它可以处理任意Java对象,包括没有源代码的预先存在的对象。
Fastjson 反序列化漏洞
影响版本
1.2.24及以下 主要是因为,没有对序列化的类做校验,导致漏洞产生
1.2.25-1.2.41增加了黑名单限制,更改autoType默认为关闭选项。
1.2.42版本是对1.2.41及以下版本的黑名单绕过,代码内更新字符串黑名单为hash方式
1.2.43版本是对1.2.42及以下版本的黑名单绕过
1.2.44-1.2.45版本1.2.43版本黑名单无法绕过,寻找新的利用链进行利用
1.2.47版本 利用fastjson处理Class类时的操作,将恶意类加载到缓存中,实现攻击
1.2.62-1.2.67版本 Class不会再往缓存中加载恶意类,寻找新的利用链进行突破
1.2.68版本,使用期望类AutoCloseable来绕过fastjson校验
1.2.72-1.2.80使用期望类Throwable的子类,进行饶过
漏洞原理
由于引进了AutoType功能,fastjson在对json字符串反序列化的时候,会读取到@type的内容,将json内容反序列化为java对象并调用这个类的setter方法,因此如果序列化插入恶意内容,使其利用exec类,就可能达到了命令执行的效果。
解析漏洞
解析漏洞主要是一些特殊文件被Apache、IIS、Nginx等Web容器(中间件)在某种情况下解释成脚本文件格式并得以执行而产生的漏洞。
IIS
目录解析:
以*.asp命名的文件夹里面的文件都会被当成ASP执行。
文件解析:
畸形文件名:例如”hello.asp;.jpg”,分号”;”后面的内容会被直接忽略,解析为”hello.asp”。
IIS6.0版本:默认可执行文件除了asp还包含”*.asa、*.cer、*.cdx”。
IIS7.0/7.5版本:在Fast-CGI开启状况下,在一个文件路径(/xx.jpg)后面加上/xx.PHP会将/xx.jpg/xx.php解析为php文件。(需要开启两个开关,php.ini里cgi.fix_pathinfo=1和IIS中的处理程序映射->请求限制里的第一个选项。)
Apache
在Apache 1.x,2.x 版本中解析文件的规则是从右到左判断解析,如果后缀为不可识别文件,那么解析就继续往左判断,如1.php.tats,最终会被判断成1.php解析。
配置问题导致的漏洞:
(1). 如果在Apache的conf里有这样一行配置 “AddHandler php5-script.php” 这时只要文件名里包含.php即使文件名是test2.php.jpg也会以php来执行。
(2). 如果在Apache的conf里有这样一行配置 “AddType application/x-http-php.jpg” 即使扩展名是jpg,也一样能以php方式执行。
(3). htaccess文件如果可以上传且能覆盖原有配置。 文件写入配置”<FIlesMatch”hello”>SetHandler application/x-httpd-php“配置意思是:无论文件后缀是什么,主要包含hello就会php解析器解析此文件
Nginx
PHP-CGI解析漏洞: 同IIS7.0/7.5版本开启PHP-CGI配置的情况,如果路径是”hello.jpg/hello.php”,那么最终就会解析hello.jpg为PHP文件
“%00截断”:
Nginx<0.8.37时,在文件后缀名后方加入%00.php会使文件最终解析为php文件,例如/xx.jpg%00.php,最终就会将xx.jpg解析为php运行。