CVE-2022-21445-for-12.2.1.3.0-Weblogic

# Oracle WebLogic ADF Faces 사전 인증 원격 코드 실행 익스플로잇 (CVE-2022-21445, CVSS 9.8) Oracle WebLogic ADF Faces용 사전 인증 원격 코드 실행 익스플로잇 (CVE-2022-21445, CVSS 9.8). 침투 테스트를 위한 상세한 환경 설정, 페이로드 생성, 원격 디버깅 지침을 포함합니다.

9/17 단계에서 Character를 Unicode(AL32UTF8)로 선택합니다.

5. 설치 프로세스가 완료되면 Window의 서비스에서 아래 그림과 같이 4개의 주요 서비스가 RUNNING 상태인지 주의 깊게 확인합니다.

6. 다음 단계에 따라 새로운 Oracle Database 계정을 생성합니다:

• Terminal Administrator -> sqlplus / as sysdba
• system 시스템 사용자 생성: alter user system identified by system_password account unlock;
• system 사용자 존재 확인: select username from dba_users;
• 환경 설정: alter session set “_oracle_script”=true;
• 일반 사용자 hr 생성: create user hr identified by user_password;
• 권한 부여: grant all privileges to hr;
• 계정 잠금 해제 – 비밀번호 변경: alter user hr identified by hr_pass account unlock;
• 새 시스템 계정 생성: alter user sys identified by sys_pass account unlock;

3단계: SQL Developer 설치, no-jre 버전. 다운로드 링크: SQLDev-NoJRE

• sqldeveloper.application 파일을 관리자 권한으로 실행합니다.

• 아래 그림과 같이 새 연결에 대한 매개변수를 설정합니다. Username과 Password(위 예시의 경우 hr), Hostname(기본값 localhost), Port(기본값 1521), SID(2단계에서 설치한 전역 데이터베이스 이름)를 변경해야 합니다.

• __Test__를 선택했을 때 Success 메시지가 표시되면 연결이 성공한 것이므로 __Connect__를 선택합니다.

4단계: Fusion Middleware Infrastructure(FMW) 12.2.1.3.0 버전 설치, 다운로드 링크 FMW_ver_12.2.1.3.0

• FMW 설치 디렉터리 경로를 C:\Oracle\Middleware\Oracle_Home 형식으로 생성합니다.
• FMW 설치 안내에 따라 순서대로 단계를 수행합니다.

5단계: Oracle Bussiness Intelligence(OBIEE) 12.2.1.4.0 버전 설치, 다운로드 링크: OBIEE_ver_12.2.1.4.0

• setup_bi_platform-12.2.1.4.0_win64.exe 파일을 관리자 권한으로 실행합니다.

• OBIEE 설치 안내에 따라 단계별로 설치합니다.

• 주의: BI 경로는 FWM을 설치한 경로와 동일해야 합니다. 여기서는 __Oracle/Middleware/Oracle_Home__입니다.

6단계: Repository Creation Utility(RCU)를 사용하여 BI 스키마 설정

• C:\Oracle\Middleware\Oracle_Home\oracle_common\bin 경로에서 rcu.bat 파일을 관리자 권한으로 실행합니다.

• 다음 단계를 순서대로 수행합니다.

• 마지막으로 __Create__를 눌러 시스템이 BI 스키마를 생성하게 합니다.

7단계: OBIEE용 환경 변수 설정

• 제어판 > 시스템 > 고급 시스템 설정 > 고급 > 환경 변수 > 새 시스템 변수로 이동합니다.

8단계: BI 도메인 생성

1. C:\Oracle\Middleware\Oracle_Home\bi\bin 경로에서 config.cmd 파일을 관리자 권한으로 실행합니다.

2. 1단계에서: 3가지 구성 요소를 모두 선택합니다. Essbase는 OLAP 서버, Business Intelligence Enterprise Edition은 BI Analytics, Business Intelligence Publisher는 BI Publisher입니다.

3. 3단계에서: 아래 그림과 같이 새 도메인을 설정합니다. !! 도메인 비밀번호를 반드시 기억하세요. 나중에 다시 찾기가 매우 어렵습니다. 그리고 도메인은 기본값이므로 __bi__로 둡니다.

4. 4단계에서: 데이터베이스에 대한 도메인 정보를 업데이트합니다.

5. 8단계에서: 프로세스가 순조롭게 진행되면 아래 그림과 같은 결과가 나타납니다.

6. 모든 것이 Done이면 다음 단계를 위해 OBIEE 정보 파일을 저장하고 다음 URL로 로그인합니다:

• http://localhost:9500/console*
• http://localhost:9500/em*
• http://localhost:9502/xmlpserver*
• http://localhost:9502/analytics*

7. 발생할 수 있는 몇 가지 오류

• 4단계에서 시스템이 로그온 실패를 보고하면 도메인 비밀번호가 정확한지 다시 확인합니다.

• 8단계에서 시스템이 아래 그림과 같은 오류를 보고하면 Window 라이선스를 활성화했는지, Window가 조건 부분에서 설명한 것과 같은지 확인합니다.

• BI_HOME_PRODUCT를 아직 추가하지 않은 오류, __7단계__를 다시 확인합니다.
• 업데이트 오류 ...

9단계: 설정이 완료되면 방금 생성한 BI 도메인의 경로 __$Oracle_Home\user_projects\domains\bi\servers\AdminServer\tmp_WL_user\adf.oracle.domain.webapp\i83uao__에 접근합니다.

• 여기의 모든 jar 파일을 별도의 디렉터리에 복사하여 공격 머신에 공유합니다(랩 환경에서는 이렇게 합니다. 실제 공격 시에도 공격 머신에 타깃 머신과 동일하게 설치하여 소스 코드를 확보해야 합니다).

• $Oracle_Home\coherence\lib 경로의 coherence.jar 라이브러리도 이 디렉터리에 추가합니다.

• 이 디렉터리는 페이로드의 성공 여부를 결정하는 중요한 디렉터리입니다. FMW나 BI의 버전, 각 머신의 설치 환경이 일반적으로 다르기 때문에 정확한 버전이 필요하며, 페이로드 전송 중 발생할 수 있는 위험이나 예외를 줄이기 위해서입니다.

10단계 (원격 디버그가 필요한 경우에만 수행합니다. 다시 말하지만 실제 환경이 아닌 테스트에서는 피해자 머신을 마음대로 설정할 수 없으므로, 공격자는 자신의 머신에 타깃 머신 설정도 수행하여 원격 디버그로 오류를 확인할 수 있어야 합니다.)

• Mozilla를 설치하고 포트 8181의 Burp Proxy를 추가합니다.

• BI 서버에서 원격 디버그 활성화

  localhost:9500/console에 접속합니다.

  Domain Structure -> bi 선택 -> Environment -> Servers

두 개의 서버가 표시됩니다. WebLogic의 AdminServer와 BI의 bi_server1입니다.

그림 10.2: 표시된 서버 목록

왼쪽 끝 모서리에서 Lock & Edit을 선택하고 bi_server1을 체크하여 구성을 편집합니다. 여기서 Configuration -> Server start -> 끝까지 스크롤 -> Advance(있을 경우) 선택 -> Arguments에 입력 선택 -> 디버그 매개변수를 입력합니다:

-Xdebug -Xnoagent – Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n

(나중에 bi_server1을 다시 시작할 수 없는 오류가 발생하면 0.0.0.0:5005로 시도할 수 있습니다. bi_server1)

WebLogic 비밀번호(앞서 Config BI Domain 부분에서 설정한 것)를 입력합니다 -> Apply change & Restart

관리자 터미널을 시작합니다 -> $Oracle_Home\user_projects\domains\bi\bitools\bin 경로로 이동하여 ./stop.cmd 및 ./start.cmd를 실행해 bi_server1을 다시 시작합니다. 재시작 과정에서 오류가 발생하지 않으면 디버그가 열려 위와 같이 포트 5005에서 수신 대기 중인 것입니다. 오류가 발생하면 위의 디버그 매개변수에 공백이 과하거나 address 부분이 잘못되었는지 다시 확인합니다.

공격 머신 측

1단계: IntelliJ IDEA Ultimate를 다운로드하고 GitHub에서 찾은 코드로 활성화합니다.

2단계 (공격 과정에서 500 Server Error, ... 같은 오류가 발생할 때만 이 단계를 수행합니다. 페이로드에 예외가 있기 때문입니다.)

1. 프로젝트의 jdk – sdk 버전을 타깃 머신과 동일한 버전으로 변경합니다(설치 방법은 __타깃 머신 부분 - 1단계__와 동일).

2. 소스 코드 분석 및 원격 디버그를 위한 빈 Project를 생성합니다. 3. 타깃 머신에서 받은 디렉터리의 모든 jar 파일을 이 프로젝트에 추가합니다.

   Project Structure -> Modules -> + 선택 -> 1 JARS or Directories -> jar 디렉터리 전체 추가.

4. 원격 디버그 설정

   Run -> Edit Configurations -> + -> Remote JVM Debug

3단계:

• 이 저장소의 코드를 머신에 클론하고 lib 디렉터리에 있는 기존 coherence.jar 파일을 삭제한 후, 이전 단계에서 타깃 머신으로부터 받은 파일로 교체합니다.

• 그런 다음 IntelliJ로 실행되는 프로젝트에 추가하고, __lib__의 jar 파일들을 Add as library 옵션으로 추가합니다.

• LambdaIdentity$.... 클래스 이름이 WebLogic 버전에 맞는지 다시 확인하고, 변경 사항이 있으면 파일을 리팩터링하고 해당 파일의 이름을 수정합니다.

  Weblogic 12.2.1.3: LambdaIdentity$E12ECA49F06D0401A9D406B2DCC7463A

  Weblogic 12.2.1.4: LambdaIdentity$423B02C050017B24DB10DFF759AA56BF

• Main.java 파일에서 LambdaIdentity$....class 파일의 경로를 수정합니다. 정확한 경로를 얻는 방법은 두 가지가 있습니다. __javac__를 실행해 jar 파일에서 .class 파일을 생성하거나, main 함수의 코드를 주석 처리한 후 이 프로젝트를 정상적으로 실행하면 클래스 파일 경로를 target 디렉터리에서 찾을 수 있습니다.

• 프로젝트의 jdk와 sdk가 타깃 머신 쪽과 동일한지 다시 확인합니다.

BI 코드 및 페이로드 생성 코드 분석

BI 코드 분석

1. $Oracle\Middleware\Oracle_Home\user_projects\domains\bi\servers\AdminServer\tmp_WL_user\em\fw8wi5\war\WEB-INF 경로에서

web.xml 파일을 볼 수 있습니다. 이 파일은 servlet-mapping과 관련된 매핑 관계를 설명합니다. "resources"는 시스템 리소스와 관련된 서블릿으로, 중요한 데이터와 정보를 포함하고 있기 때문에 공격자들이 주로 노리는 위치입니다.

2. ResourceServlet 클래스, 구체적으로 org.apache.myfaces.trinidad.webapp.ResourceServlet을 살펴보면 서버로 전송된 GET 요청을 처리하는 doGet 함수를 확인할 수 있습니다.

• 여기서 _getResourceLoader() 메서드를 통해 입력 요청으로부터 새로운 로더가 생성됩니다. 동시에 resourcePath도 초기화되며, request를 매개변수로 전달받는 getResourcePath 메서드를 통해 servletPath와 servletInfo 값을 받습니다. 해당 로더는 getResource(resourcePath) 함수를 호출하여 입력 요청에서 리소스를 로드하려고 시도하고, org.apache.myfaces.trinidad.resource.ResourceLoader.getResource.findResource() 함수를 통해 이를 찾습니다. 마지막으로 찾은 값은 URL.class의 url 인스턴스에 전달됩니다.

• _getResourceLoader는 servletPath와 로더 간의 매핑 관계를 저장하기 위해 ConcurrentMap을 유지합니다. 이 관계는 oracle.adfinternal.view.resource.rich.RenderKitResourceLoader에 명확하게 정의되어 있습니다.

• RenderKitResourceLoader() 함수의 _register 메서드가 호출되어 해당 regex + 로더를 전달한 후, 상위 함수인 super.register를 반환합니다. 이 함수는 concurrentmap_loaders에 partern 값과 해당 로더를 추가합니다. 따라서 doGet() 함수에서 로더가 초기화되고 입력 request 매개변수를 받으면, 전송된 요청 URL의 servletPath 값을 가져와 _loader.get()에 전달하여 해당 서블릿을 얻습니다.

• 취약점의 발견자는 findResource() 메서드를 오버라이드하는 클래스 중 oracle.adfinternal.view.resource.rich.RemoteApplicationResourceLoader가 역직렬화로 이어질 위험이 있는 클래스라고 판단했습니다. 그 이유를 찾기 위해 이를 분석해 보겠습니다.

RemoteApplicationResourceLoader.class의 findResource() 함수 분석

이 함수는 사용자 지정 프로토콜 RAStreamHandler()를 포함하는 메서드를 반환합니다. RAStreamHandler는 값이 new RAURLConnection인 URLConnection 객체를 생성합니다.

RAURLConnection 함수는 _getPathBean 함수를 호출합니다.

_getPathBean 함수는 getInstanceFromString() 함수를 호출하여 생성된 bean 객체를 포함합니다. 이 함수는 입력받은 문자열을 처리하여 해당 키(필터)를 추출합니다.

입력된 bean 문자열은 SerializationUtils 클래스를 통해 URL 인코딩 형식에서 URLEncoderPathBean 객체로 변환됩니다. 모든 것이 정상이면 이후 입력은 계속해서 fromURLEncodeString() 함수에 전달됩니다.

입력 문자열에 오류가 있으면 예외가 발생합니다. 예외는 주로 페이로드에 사용된 라이브러리에서 발생하며, 버전 불일치 또는 Lambda 파일 경로 오류로 인해 발생합니다.

fromURLEncodedString() 함수에서 url 매개변수를 사용하는 fromString 함수가 반환되며, 그 코드는 다음과 같습니다:

fromString 함수에서 데이터는 readObject()로 읽혀 반환됩니다. 입력값이 전혀 필터링되지 않는 것을 볼 수 있습니다. 여러 함수를 거쳐 최종적으로 fromString()에서 역직렬화됩니다. 이것이 바로 공격에 사용되는 싱크(sink)입니다. 싱크가 있으니 이제 소스(source)만 찾으면 됩니다.

3. 소스 찾기: 위에서 분석한 것처럼 소스를 찾으려면 입력 요청 URL을 식별해야 합니다. findResource() 함수를 호출하려면 RemoteApplicationResourceLoader 클래스로 접근할 수 있어야 합니다. RenderKitResourceLoader 클래스에 매우 명확하게 정의되어 있습니다:```bash this._register("/./remote/(.)", new RemoteApplicationResourceLoader());