CVE-2017-10271 (WebLogic XMLDecoder 역직렬화 RCE) 취약점을 수동 페이로드 구성, 블라인드 RCE 우회, 권한 확인 및 데이터 유출을 포함한 사후 익스플로잇 기술을 이용하여 익스플로잇하는 단계별 실습 가이드입니다.
AdminServer가 base_domain에 속하며 Development Mode로 실행 중)7001http, t3, iiop, ldap, snmp7001에서 t3 프로토콜을 노출합니다. 이 기본 구성은 WebLogic 버전이 RMI(원격 메서드 호출)를 통한 자바 객체 역직렬화 관련 취약점에 대해 패치되지 않은 경우 높은 위험을 수반합니다.7001에서 http 프로토콜로 실행되므로 /console/login/LoginForm.jsp와 같은 민감한 엔드포인트에 대한 디렉터리 스캐닝에 취약해집니다.대상의 열린 포트가 식별되면 nmap을 사용하여 포트를 스캔하여 실행 중인 서비스를 확인합니다.
따라서 대상은 Oracle WebLogic Server 10.3.6.0 버전의 HTTP 서비스를 실행 중입니다. 이는 중요한 CVE(예: 역직렬화, 인증 우회) 시리즈로 유명한 잘 알려진 엔터프라이즈 Java 애플리케이션 서버입니다. 그러나 이 정보만으로는 시스템이 어떤 특정 취약점에 취약한지 결론짓기에 충분하지 않습니다. 연결된 웹 서비스 구성 요소를 더 깊이 스캔해야 합니다.
dirsearch 도구를 사용하여 민감한 엔드포인트를 식별하겠습니다. WebLogic은 Java 플랫폼에서 실행되므로 .jsp 및 .xml 파일이 가장 민감한 대상입니다. 200 상태 코드를 반환하는 엔드포인트에 초점을 맞추겠습니다.
dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html
/console/login/LoginForm.jsp: WebLogic Admin Console 웹 인터페이스의 로그인 포털입니다. 기본 자격 증명 무차별 대입 시나리오 또는 인증 우회 취약점(예: CVE-2020-14882)에 대한 중요한 대상입니다./bea_wls_internal/: WebLogic Server의 기본 내부 웹 애플리케이션 디렉터리입니다. 이 구성 요소는 정적 시스템 파일에 대한 액세스 및 상호 작용을 허용합니다./wls-wsat/CoordinatorPortType: 이것이 가장 중요한 발견입니다. 200 OK 상태 코드로 이 경로가 존재한다는 것은 Web Services Atomic Transactions (wls-wsat) 구성 요소가 활성화되어 데이터를 수신할 준비가 되었음을 확인합니다./uddiexplorer 및 /uddi/uddilistener: 이는 WebLogic Server에 기본적으로 통합되어 웹 서비스를 관리 및 등록하는 UDDI Explorer(Universal Description, Discovery, and Integration) 구성 요소입니다. 이 구성 요소는 SSRF(Server-Side Request Forgery) - CVE-2014-4210 취약점으로 매우 유명합니다. 공격자는 /uddiexplorer/SearchPublicRegistries.jsp 엔드포인트에서 UDDI의 공개 레지스트리 검색 인터페이스를 활용하여 WebLogic 서버가 백엔드 내부 네트워크로 임의의 HTTP 요청을 보내도록 강제할 수 있습니다.⇒ 생각: /wls-wsat (XMLDecoder를 통한 RCE 위험)과 /uddiexplorer (SSRF 위험)의 공존은 이 WebLogic 서버의 공격 표면이 매우 광범위함을 나타냅니다.
WebLogic 10.3.6.0 서버에 공존하는 두 개의 독립적인 공격 표면을 식별한 후, 우리는 두 방향을 분석합니다.
/uddiexplorer의 SSRF 취약점 (CVE-2014-4210):
/wls-wsat의 XMLDecoder 역직렬화 취약점 (CVE-2017-10271):
⇒ 결정: Cyber Attack Chain 모델에서 RCE는 항상 최종 목표입니다. 이는 시스템에 대한 직접적이고 완전한 제어(Full System Compromise)를 제공하기 때문입니다. RCE 기능이 달성되면 UDDI 애플리케이션을 통한 SSRF 악용은 중복됩니다. RCE 셸에서는 UDDI 인터페이스의 매개변수에 제한받지 않고 직접적이고 유연하며 더 강력한 방식(시스템 명령어 curl, wget 사용)으로 내부 네트워크 쿼리를 적극적으로 수행할 수 있기 때문입니다.
따라서 익스플로잇 우선순위 논리 측면에서 우리는 보조 경로(/uddiexplorer의 SSRF)를 제외하고 전적으로 연구에 집중하기로 결정했습니다: /wls-wsat/CoordinatorPortType의 XMLDecoder 역직렬화 취약점을 통한 원격 코드 실행 (RCE).
CVE-2017-10271의 근본 취약점은 WebLogic의 WorkContextXmlInputAdapter 클래스가 <work:WorkContext> 태그의 데이터를 구문 분석하기 위해 java.beans.XMLDecoder 객체를 사용하기 때문에 발생합니다. 기본적으로 이 XMLDecoder 클래스는 XML 태그 형식으로 정의된 모든 Java 클래스를 자동으로 인스턴스화합니다. 여기에서 단계별 시스템 행동 상호 작용을 기반으로 검증을 수행합니다.
이 서블릿의 실제 활성 상태를 빠르게 확인하려면 일반 HTTP GET 프로브 요청을 보냅니다.
curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType
응답은 HTTP/1.1 200 OK 와 함께 구현 클래스 CoordinatorPortTypePortImpl을 반환하여 서블릿이 JVM 메모리에 성공적으로 로드되었음을 확인합니다.
Web Services 서블릿은 POST 메서드를 통해 SOAP XML 데이터를 처리하도록 설계되었으므로, 시스템의 데이터 처리 파이프라인을 입증하기 위해 두 개의 POST 요청으로 비교 테스트를 진행합니다.
1. 표준 SOAP POST 요청
완전한 네임스페이스를 포함하지만 실행 내용이 없는 표준 SOAP XML Envelope를 전송하여 파서의 정상적인 구문 분석 능력을 테스트합니다.
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"
Cannot find dispatch method).분석:
서버는 POST 포트에서 잘 작동하는 XML 리더를 가지고 있어 사용자가 보낸 전체 XML 트리 구조를 수신하고 디코딩할 준비가 되었습니다. 이는 클라이언트에서 WebLogic 메모리 깊숙이 이어지는 데이터 파이프라인이 완전히 작동함을 확인합니다.
2. 비정상 XML POST 요청
다음으로, 파서의 예외 처리 메커니즘을 관찰하기 위해 의도적으로 XML 구조를 깨뜨립니다(예: 네임스페이스 누락).
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"
com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv"를 반환합니다.분석:
com.ctc.wstx)로 직접 전달되어 구문 분석됩니다.실제 실험 결과와 시스템 아키텍처 분석(서블릿이 POST 포트를 통해 원시 패킷을 수신하고, Parser 계층에 WAF/무결성 필터가 없으며, 원시 Java XML Reader 오류를 직접 던지는 것)의 조합은 서버가 CVE-2017-10271 (XMLDecoder 역직렬화)의 범위에 직접 속하는 매우 민감한 서비스 구조를 실행 중임을 확인합니다.
XMLDecoder의 기본 구문 분석 메커니즘에는 클래스 제어 필터가 없기 때문에, 삭제 없이 원시 POST 데이터를 수신하는 서버는 다음 단계에서 Java 시스템 실행 객체를 직접 호출하는 페이로드를 설계할 수 있는 완벽한 통로입니다.
WebLogic 10.3.6.0 서버는 오래된 Java 환경에서 실행되고 XMLDecoder에 대해 엄격한 클래스 제어 필터를 적용하지 않기 때문에 공격자는 실행 가능한 Java 객체를 직접 주입할 수 있습니다.
Java에서 명령을 실행하는 표준 클래스는 java.lang.ProcessBuilder 입니다. 이 Java 객체 초기화 로직을 XMLDecoder와 호환되는 XML 형식으로 매핑합니다.
<void class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void method="start"/>ProcessBuilder를 통해 시스템 명령이 실행되면 WebLogic 서버는 OS에서 명령을 백그라운드로 실행하고 HTTP 500 오류 코드만 반환합니다(명령 출력을 HTTP 응답 화면에 직접 출력하지 않음). 이 메커니즘을 웹 애플리케이션 매핑이라고 합니다. 모든 웹 서버는 이렇게 작동합니다. war/ 디렉터리는 해당 애플리케이션의 Document Root입니다. war/에 있는 모든 파일은 짧은 URL을 통해 액세스할 수 있습니다.
⇒ 블라인드 RCE를 우회하려면 물리적 경로를 찾아야 합니다. id > ... 명령은 운영 체제에서 실행되므로 실제 경로가 필요합니다.
/war 디렉터리를 찾기 위한 화이트박스 분석
컨테이너 내부에서 로드 중인 bea_wls_internal 애플리케이션의 실제 물리적 경로를 찾기 위해 호스트 시스템에서 직접 시스템 검색 쿼리를 실행합니다.
결과
/root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war (원본 아카이브 라이브러리 파일)./root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal (AdminServer의 임시 파티션 _WL_internal에 있는 압축 해제된 활성 애플리케이션 디렉터리). 이 활성 디렉터리 깊숙이 들어가면 정적 파일이 포함된 하위 디렉터리인 /9j4dqk/war/를 찾을 수 있습니다. 이는 애플리케이션의 절대 Web Root 디렉터리이며, 공격자는 RCE 실행 결과를 표시하기 위해 정적 파일을 작성할 수 있는 쓰기 권한을 가지고 있습니다.생각: 위 디렉터리의 정적 파일 rce.txt로 id의 출력을 리디렉션하는 명령 설계: id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt
위 분석에서 Java의 XMLDecoder 클래스는 XML 태그 형태로 정의된 모든 객체를 자동으로 인스턴스화하고 실행한다는 것을 알 수 있습니다. Java에서 운영 체제 명령을 호출하는 표준 클래스는 java.lang.ProcessBuilder입니다.
동등한 Java 코드를 XMLDecoder XML 구조로 매핑하는 과정:
동등한 Java 코드: