Oracle WebLogic ADF Faces用の事前認証リモートコード実行エクスプロイト（CVE-2022-21445、CVSS 9.8）。ペネトレーションテスト用の詳細な環境設定、ペイロード生成、リモートデバッグ手順を含む。

ステップ9/17で、文字セットとしてUnicode (AL32UTF8) を選択します。

5. インストールプロセスが完了したら、WindowsのServicesで、以下の図のように主要な4つのサービスがRUNNING状態であることを注意深く確認します。

6. 以下の手順に従って、新しいOracle Databaseアカウントを作成します：

• 管理者ターミナル -> 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 Business 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 Schemaを設定します。

• パス C:\Oracle\Middleware\Oracle_Home\oracle_common\bin で、___rcu.bat___ファイルを管理者権限で実行します。

• 以下の手順を順番に実行します。

• 最後に、システムがBI Schemaを作成するように__Create__を押します。

手順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でシステムがfail to logonと表示した場合は、ドメインのパスワードが正しいか再確認してください。

• ステップ8でシステムが下図のようなエラーを表示した場合は、Windowsのライセンスがアクティブ化されているかどうか、またお使いのWindowsが「条件」セクションに記載されている内容と一致しているかを確認してください。

• 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 の順に選択します。

2つのサーバーが表示されます。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

(後で再起動できないエラーが発生した場合は、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フォルダ全体をAddします。

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ファイルへのパスを修正します。正確なパスを取得するには2つの方法があります: __javac__を実行してjarファイルから.classファイルを生成する方法。もう1つの方法は、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にパターンと対応するローダーを追加します。したがって、doGet()関数でローダーが初期化され、入力リクエストパラメータを受け取ると、送信された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()でデシリアライズされます。これが悪用に使われるシンクです。シンクが判明したので、次はソースを見つければ完了です。

3. ソースの特定: 上記の分析のとおり、ソースを見つけるには入力リクエストのURLを特定する必要があります。findResource()関数を呼び出すには、RemoteApplicationResourceLoaderクラスにアクセスできる必要があります。RenderKitResourceLoaderクラスには明確に定義されています:```bash this._register("/./remote/(.)", new RemoteApplicationResourceLoader());